{"slug": "agent-ready-commerce-part-7-delegated-payment-needs-more-than-a-token", "title": "Agent-Ready Commerce, Part 7: Delegated Payment Needs More Than a Token", "summary": "A developer argues that delegated payment in agent-ready commerce requires more than a valid token or payment artifact. The platform must verify that a specific payment request falls within the buyer's delegated authority at the exact moment of execution, considering checkout state, cart integrity, amount limits, and other factors. The post models delegated payment as bounded authority rather than a simple credential.", "body_md": "Delegated payment is not a question of whether a token exists.\n\nIt is a question of whether a specific payment request is still inside the buyer’s delegated authority at the exact moment the platform executes it.\n\nThat distinction matters.\n\nA token, signed message, mandate reference, payment artifact, or protocol payload may be valid as data. It may have a valid signature. It may not be expired. It may have been issued by a trusted party. But the commerce platform still has to answer a narrower question:\n\n```\nMay this actor request this payment action for this buyer, merchant, checkout snapshot, amount, currency, and time window?\n```\n\nThat question cannot be answered by token presence alone.\n\nIt depends on checkout state, cart snapshot integrity, amount limits, currency, merchant binding, actor authority, buyer authority, confirmation rules, expiry, revocation, payment-attempt state, evidence, and audit.\n\nAgent-ready commerce needs delegated payment to be modeled as bounded authority, not as a credential that turns checkout into payment.\n\nThis is the seventh article in the Agent-Ready Commerce series.\n\nPart 1 introduced the broader architecture model:\n\n```\nFacts → Eligibility → Authority → State transition → Evidence → Audit\n```\n\nPart 2 focused on commercial truth. It argued that catalog data is not enough. A platform needs source-backed, freshness-aware product facts before agents or other systems can safely rely on product information.\n\nPart 3 focused on action eligibility. It argued that “available” is too broad. A product may be discoverable but not checkout-ready, comparable but not policy-quotable, or checkout-ready for a human flow but not eligible for delegated payment.\n\nPart 4 focused on policy structure. It argued that agents should not interpret free-text policy pages as executable rules. Policies need structured facts with applicability, evidence, lifecycle, conflicts, and quoteability.\n\nPart 5 focused on protocol adapters. It argued that ACP, MCP, AP2, feeds, tools, and future interfaces should translate domain decisions rather than becoming separate sources of commercial meaning.\n\nPart 6 focused on checkout state. It argued that checkout is where agent-ready commerce crosses from answering into mutating commercial state. Checkout should therefore be modeled as a state machine, not a form endpoint.\n\nThis article focuses on payment authority.\n\nThe central argument is that delegated payment is a scoped authority decision over a specific checkout snapshot. A payment artifact may be evidence for that decision, but it is not the decision itself.\n\nA safe platform follows this chain:\n\n```\nPayment artifact\n      ↓\nMandate scope\n      ↓\nCheckout snapshot match\n      ↓\nAuthority decision\n      ↓\nPayment execution\n      ↓\nOrder commitment\n      ↓\nEvidence and audit\n```\n\nEach step answers a different question. Collapsing them into “token valid, proceed” creates unsafe payment behavior.\n\nDelegated payment should begin with a precise decision question.\n\nNot:\n\n```\nIs the token valid?\n```\n\nNot:\n\n```\nDoes the agent have a payment artifact?\n```\n\nNot:\n\n```\nIs there a saved payment method?\n```\n\nThe question is:\n\n```\nMay this actor request this payment action for this buyer, merchant, checkout snapshot, amount, currency, and time window?\n```\n\nEach part of the question carries meaning.\n\n`This actor`\n\nmatters because not every caller may act on behalf of the buyer.\n\n`This buyer`\n\nmatters because authority is tied to the party whose funds, account, or payment instrument will be used.\n\n`This merchant`\n\nmatters because permission to buy from one merchant does not automatically apply to another merchant or marketplace seller.\n\n`This checkout snapshot`\n\nmatters because carts can change.\n\n`This amount`\n\nmatters because a mandate may have a limit.\n\n`This currency`\n\nmatters because €150 is not the same authority as $150 or an automatically converted amount.\n\n`This time window`\n\nmatters because authority can expire or be revoked.\n\nA delegated payment system should make these dimensions explicit instead of hiding them behind a generic authorization field.\n\nSeveral concepts are easy to confuse.\n\nA payment artifact is data received from a protocol, wallet, payment provider, identity system, authorization flow, or internal authority service. It may contain claims, references, signatures, identifiers, or constraints.\n\nA mandate is the platform’s structured representation of delegated authority. It defines who may do what, for whom, under which constraints.\n\nAn authority decision is the platform’s current evaluation of whether a requested payment action is inside the mandate.\n\nPayment execution is the state transition that attempts, authorizes, captures, or records payment.\n\nOrder commitment is the state transition that creates the order after the platform’s payment and checkout rules are satisfied.\n\nThese are related, but they are not interchangeable.\n\n```\nArtifact:\nSomething was presented.\n\nMandate:\nThe platform understands the scope.\n\nAuthority decision:\nThe current request is allowed, blocked, or requires confirmation.\n\nPayment execution:\nThe platform attempts the payment action.\n\nOrder commitment:\nThe platform creates the order.\n```\n\nA valid artifact can produce a blocked authority decision.\n\nA valid authority decision can still lead to a failed payment attempt.\n\nA successful payment authorization may still require a separate order commitment transition.\n\nThis separation is not academic. It prevents the platform from treating one kind of proof as proof of everything.\n\nContinue with the running example from Parts 2–6:\n\n```\nProduct: Travel Backpack\nSKU: BAG-TRAVEL-42\nPrice: €129\nCatalog status: active\nInventory status: in_stock\nCategory: Travel Bags\n```\n\nThe commercial truth layer currently says:\n\n```\nPrice: fresh\nInventory: stale\nReturn policy: missing for Travel Bags\nWarranty policy: known\nShipping policy: known for EU, unknown for US\nGenerated description: pending review\nFeed publication: last published yesterday\n```\n\nFrom Part 3, the action matrix was:\n\n| Action | Result |\n|---|---|\n`discover` |\nallowed |\n`compare` |\nallowed |\n`quote_policy` |\nblocked |\n`add_to_cart` |\nrequires_revalidation |\n`prepare_checkout` |\nblocked |\n`delegate_payment` |\nblocked |\n\nFrom Part 6, checkout preparation is blocked because inventory is stale and return-policy coverage is missing.\n\nNow suppose a buyer tells an agent:\n\n```\nBuy the Travel Backpack if the final total is under €150.\n```\n\nThe agent may also carry a payment-related artifact that appears to authorize a purchase up to €150 in EUR.\n\nDelegated payment should still be blocked.\n\nThe reason is not that the amount is too high. The product price is €129. The reason is that checkout itself is not valid.\n\nThe payment artifact cannot make stale inventory fresh. It cannot create return-policy coverage for Travel Bags. It cannot make unknown US shipping terms known. It cannot approve generated product text. It cannot turn a blocked checkout transition into a valid one.\n\nThe platform should answer:\n\n```\nDelegated payment is blocked because checkout is not valid.\n```\n\nA safe causal chain is:\n\n```\ndelegate_payment blocked\n      ↓\ncheckout is not valid\n      ↓\nprepare_checkout is blocked\n      ↓\ninventory is stale\nreturn-policy coverage is missing\n```\n\nThat chain should remain visible in the decision, evidence, and audit trail.\n\nDelegated payment involves several kinds of authority, not one.\n\n```\nBuyer authority:\nDid the buyer permit this actor to act?\n\nPlatform authority:\nDoes the platform allow this actor and action under its own rules?\n\nPayment-provider authorization:\nDid the payment provider authorize or accept the payment attempt?\n```\n\nThese are different.\n\nA buyer may authorize an agent to purchase an item, but the platform may still block the action because checkout is invalid.\n\nThe platform may allow the agent to request payment, but the payment provider may decline the payment attempt.\n\nThe payment provider may authorize a payment, but the platform may still fail to commit the order because final order checks fail.\n\nThe boundaries are:\n\n```\nBuyer authority is not checkout validity.\nCheckout validity is not provider authorization.\nProvider authorization is not order commitment.\n```\n\nA safe delegated payment design does not collapse these states.\n\nA token may be part of a mandate, but it is not the mandate by itself.\n\nA delegated payment mandate should answer:\n\n```\nWho is the buyer?\nWhich actor is allowed to act?\nWhich merchant is in scope?\nWhich checkout or cart snapshot is in scope?\nWhat is the maximum amount?\nWhich currency is allowed?\nWhich payment actions are allowed?\nWhen does the authority expire?\nCan it be revoked?\nIs human confirmation required?\nWhich evidence supports the authority?\n```\n\nA simplified TypeScript model might look like this:\n\n```\ntype PaymentMandateStatus =\n  | \"pending_confirmation\"\n  | \"active\"\n  | \"expired\"\n  | \"revoked\"\n  | \"used\"\n  | \"rejected\";\n\ntype PaymentAction =\n  | \"prepare_payment\"\n  | \"authorize_payment\"\n  | \"capture_payment\"\n  | \"commit_order\";\n\ntype PaymentMandate = {\n  mandateId: string;\n  status: PaymentMandateStatus;\n\n  buyerId: string;\n\n  actor: {\n    actorId: string;\n    actorType: \"human\" | \"agent\" | \"system\";\n  };\n\n  scope: {\n    merchantId: string;\n    cartSnapshotId: string;\n    maxAmount: number;\n    currency: string;\n    allowedActions: PaymentAction[];\n  };\n\n  confirmation: {\n    required: boolean;\n    satisfied: boolean;\n    confirmationRef?: string;\n  };\n\n  lifecycle: {\n    createdAt: string;\n    expiresAt: string;\n    revokedAt?: string;\n    revokedReason?: string;\n    usedAt?: string;\n  };\n\n  evidenceRefs: string[];\n};\n```\n\nThis is intentionally simplified. Real systems may need account-level rules, payer identities, payment instruments, billing addresses, risk checks, marketplace seller relationships, provider references, regional compliance rules, or contract terms.\n\nThe important property is scope.\n\nWithout scope, the platform cannot prove that a payment request is still inside the buyer’s delegated authority.\n\nA delegated payment decision should be current.\n\nIt is not enough to evaluate authority when the agent starts the flow and assume it remains valid until payment. The cart may change. The checkout may expire. The mandate may be revoked. The amount may change. Currency may change. A required confirmation may no longer apply because the commercial state changed.\n\nThe platform should evaluate authority at the point of payment execution.\n\nA simplified decision type:\n\n```\ntype PaymentAuthorityDecision = {\n  decisionId: string;\n\n  actorId: string;\n  buyerId: string;\n  merchantId: string;\n\n  checkoutId: string;\n  cartSnapshotId: string;\n  mandateId: string;\n\n  requestedAction: PaymentAction;\n  requestedAmount: number;\n  currency: string;\n\n  result:\n    | \"allowed\"\n    | \"blocked\"\n    | \"requires_confirmation\"\n    | \"requires_revalidation\";\n\n  blockers: Array<{\n    code: string;\n    message: string;\n    nextAction?: string;\n  }>;\n\n  evidenceRefs: string[];\n  evaluatedAt: string;\n};\n```\n\nFor the Travel Backpack:\n\n``` js\nconst decision: PaymentAuthorityDecision = {\n  decisionId: \"decision_001\",\n  actorId: \"agent_123\",\n  buyerId: \"buyer_456\",\n  merchantId: \"merchant_001\",\n  checkoutId: \"checkout_789\",\n  cartSnapshotId: \"snapshot_abc\",\n  mandateId: \"mandate_001\",\n  requestedAction: \"authorize_payment\",\n  requestedAmount: 129,\n  currency: \"EUR\",\n  result: \"blocked\",\n  blockers: [\n    {\n      code: \"CHECKOUT_NOT_VALID\",\n      message:\n        \"Delegated payment cannot proceed because checkout preparation is blocked.\",\n      nextAction:\n        \"Resolve checkout blockers before requesting delegated payment.\"\n    }\n  ],\n  evidenceRefs: [\n    \"checkout:checkout_789:state\",\n    \"eligibility:BAG-TRAVEL-42:prepare_checkout\"\n  ],\n  evaluatedAt: \"2026-06-28T09:00:00Z\"\n};\n```\n\nThis decision does not need to reimplement checkout. It references the checkout decision.\n\nThat is the point of the chain.\n\nPayment authority depends on checkout validity. It does not replace it.\n\nA delegated payment system should not evaluate payment authority in isolation from checkout state.\n\nThe safer order is:\n\n```\nCommercial truth\n      ↓\nEligibility\n      ↓\nCheckout state\n      ↓\nPayment authority\n      ↓\nPayment execution\n      ↓\nOrder commitment\n```\n\nPayment authority should not bypass earlier checks.\n\nA buyer may authorize an agent to buy the Travel Backpack up to €150. That does not mean:\n\n```\nIgnore stale inventory.\nIgnore missing return policy.\nIgnore unsupported shipping region.\nIgnore generated-claim review.\nIgnore checkout expiry.\n```\n\nIt means:\n\n```\nIf checkout is valid and the payment request matches the mandate scope, the actor may request payment within the mandate’s limits.\n```\n\nThat is a narrower and safer statement.\n\nThe buyer can authorize an agent to act. The platform must still decide whether the action is commercially valid.\n\nA mandate should bind to a checkout snapshot, not only to a cart ID.\n\nA cart ID identifies a mutable container. It does not prove that the cart contents, price, currency, shipping region, tax, policy coverage, or total are unchanged.\n\nA cart snapshot records the commercial state that was evaluated.\n\n```\ntype CartSnapshot = {\n  snapshotId: string;\n  cartId: string;\n\n  items: Array<{\n    sku: string;\n    quantity: number;\n    priceAmount: number;\n    currency: string;\n  }>;\n\n  totals: {\n    subtotal: number;\n    shipping?: number;\n    tax?: number;\n    total: number;\n    currency: string;\n  };\n\n  merchantId: string;\n\n  context: {\n    region?: string;\n    buyerType?: \"consumer\" | \"business\";\n    channel: \"storefront\" | \"agent\" | \"marketplace\";\n  };\n\n  factRefs: string[];\n  policyFactRefs: string[];\n  createdAt: string;\n};\n```\n\nBefore payment, the platform should verify:\n\n```\nDoes the checkout use the same snapshot?\nDo the items match?\nDoes the total remain within the mandate?\nDoes the currency match?\nDoes the merchant match?\nHas the snapshot expired?\n```\n\nThis prevents a critical failure mode:\n\n```\nBuyer authorizes one cart.\nCart changes.\nAgent requests payment for the changed cart.\nPlatform treats the old authority as valid.\n```\n\nThat should not be possible.\n\nIf the cart changes after authority is granted, the platform should require revalidation or a new mandate.\n\nA buyer instruction such as “under €150” is not enough unless the platform defines what the amount includes.\n\nDoes the limit include shipping?\n\nDoes it include tax?\n\nDoes it include discounts?\n\nDoes it allow partial capture?\n\nDoes it allow a lower amount?\n\nDoes it allow multiple attempts?\n\nDoes it allow currency conversion?\n\nA useful amount scope is explicit:\n\n```\ntype AmountScope = {\n  maxAmount: number;\n  currency: string;\n\n  includesShipping: boolean;\n  includesTax: boolean;\n\n  allowLowerAmount: boolean;\n  allowPartialCapture: boolean;\n\n  maxPaymentAttempts: number;\n};\n```\n\nFor the Travel Backpack:\n\n```\nProduct price: €129\nBuyer limit: €150\nCurrency: EUR\n```\n\nThe product price alone is not enough.\n\nIf shipping and tax bring the final total to €153, the payment request is outside the mandate even though the product price is below the limit.\n\nA safe decision:\n\n```\nDelegated payment blocked.\nReason: final checkout total exceeds the mandate amount limit.\n```\n\nThat is not a product-truth issue. It is an authority-scope issue.\n\nCurrency should not be treated as display metadata.\n\nA mandate for €150 is not the same as a mandate for $150, £150, or an automatically converted amount.\n\nIf currency conversion is allowed, that should be explicit. If it is not explicit, currency mismatch should block delegated payment.\n\n```\ntype CurrencyScope = {\n  currency: string;\n  conversionAllowed: boolean;\n  conversionSource?: string;\n  maxConvertedAmount?: number;\n};\n```\n\nA conservative delegated payment decision:\n\n```\nMandate currency: EUR\nCheckout currency: USD\nResult: blocked\nReason: currency mismatch\n```\n\nA platform may support approved conversion flows, but those flows need their own rules and evidence.\n\nImplicit conversion is not a safe default for delegated payment.\n\nA payment mandate should bind to a merchant, marketplace, seller, or defined merchant group.\n\nPermission to buy from one merchant does not automatically apply to another merchant.\n\n```\ntype MerchantScope = {\n  merchantId: string;\n  marketplaceId?: string;\n  allowedSellerIds?: string[];\n};\n```\n\nIn a direct commerce platform, merchant scope may be simple.\n\nIn a marketplace, it may be more complex. The mandate may apply to the marketplace operator, a specific seller, or a set of sellers. It may also interact with payment routing, invoicing, returns, fulfillment responsibility, and support.\n\nThe important rule is that merchant scope is checked before payment.\n\n```\nMandate merchant: merchant_001\nCheckout merchant: merchant_002\nResult: blocked\nReason: merchant mismatch\n```\n\nA protocol artifact that is valid in general is not valid for every merchant.\n\nDelegated payment involves at least two identities:\n\n```\nThe buyer whose funds, account, or payment instrument is used.\nThe actor requesting the payment action.\n```\n\nThe actor may be a human, an agent, a system process, or another delegated entity.\n\nThe platform should not confuse the buyer’s ability to purchase with the actor’s authority to act.\n\nThe buyer may be eligible to buy, but the agent may not be authorized to request payment.\n\nThe agent may have authority to prepare checkout but not to authorize payment.\n\nThe agent may have authority for one cart snapshot but not another.\n\nA platform should evaluate:\n\n```\nBuyer eligibility:\nCan this buyer make this purchase?\n\nActor authority:\nCan this actor request this payment action for this buyer?\n\nMandate scope:\nDoes the request match cart, amount, currency, merchant, time, and confirmation rules?\n```\n\nA simplified actor authority model:\n\n```\ntype ActorAuthority = {\n  actorId: string;\n  buyerId: string;\n\n  allowedActions: PaymentAction[];\n\n  constraints: {\n    merchantId?: string;\n    cartSnapshotId?: string;\n    maxAmount?: number;\n    currency?: string;\n  };\n\n  status: \"active\" | \"expired\" | \"revoked\";\n};\n```\n\nThe existence of a protocol request does not prove actor authority.\n\nThe platform must evaluate it.\n\nSome delegated payment flows require human confirmation.\n\nThe buyer may allow an agent to prepare checkout but require confirmation before payment. Or the buyer may pre-authorize payment up to a limit without additional confirmation. Or confirmation may be required only when the cart, shipping, total, or policy terms change.\n\nConfirmation should be modeled explicitly.\n\n```\ntype ConfirmationRule = {\n  required: boolean;\n\n  requiredWhen?: Array<\n    | \"amount_changed\"\n    | \"cart_changed\"\n    | \"shipping_changed\"\n    | \"policy_changed\"\n    | \"risk_review_required\"\n  >;\n\n  satisfiedAt?: string;\n  confirmationRef?: string;\n};\n```\n\nExamples:\n\n```\nNo confirmation required:\nAgent may request payment if the final total is within mandate scope.\n\nConfirmation required:\nAgent may prepare checkout, but buyer must approve before payment.\n\nConditional confirmation:\nBuyer approval is required if the total increases or shipping changes.\n```\n\nA chat message such as “yes, buy it” should not automatically become payment authority unless the platform records it as a structured confirmation event tied to a specific snapshot and scope.\n\nPresentation is not authority.\n\nConfirmation becomes authority evidence only when the platform captures it as such.\n\nA mandate should expire.\n\nIt should also be revocable.\n\nExpiry handles time-based risk. Revocation handles buyer decisions, fraud signals, support actions, account restrictions, or business rules that invalidate authority before the expiry time.\n\n```\ntype MandateLifecycle = {\n  status:\n    | \"pending_confirmation\"\n    | \"active\"\n    | \"expired\"\n    | \"revoked\"\n    | \"used\"\n    | \"rejected\";\n\n  createdAt: string;\n  expiresAt: string;\n\n  revokedAt?: string;\n  revokedReason?: string;\n\n  usedAt?: string;\n};\n```\n\nBefore payment execution, the platform should check current mandate status.\n\n```\nMandate was active when checkout was prepared.\nMandate was revoked before payment was requested.\nResult: blocked.\n```\n\nThis should not depend on the agent’s memory, an adapter cache, or a stale protocol response.\n\nThe authority service should own mandate lifecycle.\n\nRequesting payment is not only an API call to a payment provider.\n\nIt is a state transition in the commerce platform.\n\nA simplified payment path might look like this:\n\n```\ncheckout_prepared\n      ↓\npayment_authority_required\n      ↓\npayment_authority_validated\n      ↓\npayment_pending\n      ↓\npayment_authorized\n      ↓\norder_committed\n```\n\nSome platforms authorize and capture separately. Some capture immediately. Some support invoice flows, wallet flows, marketplace settlement, stored instruments, or manual review. The exact states vary.\n\nThe design rule is stable:\n\n```\nPayment execution should have explicit preconditions, outcomes, evidence, and audit.\n```\n\nA payment request should record:\n\n```\nWhich checkout snapshot was used\nWhich mandate was evaluated\nWhich authority decision was produced\nWhich amount and currency were requested\nWhich provider request was made\nWhich response was received\nWhether the result is final or ambiguous\nWhich audit event was recorded\n```\n\nThis prevents the payment provider call from becoming an opaque side effect.\n\nA payment provider may authorize or accept a payment attempt. That still does not mean the order has been committed.\n\nThe platform may need to create the order, reserve or allocate inventory, write invoices, emit events, trigger fulfillment, update customer records, and produce audit evidence.\n\nOrder commitment should be its own transition.\n\n```\nPayment authorized\n      ↓\nCommit order command\n      ↓\nFinal validation\n      ↓\nOrder committed\n```\n\nFinal validation may include:\n\n```\nCart snapshot still matches\nPayment result satisfies order rules\nInventory reservation is valid\nMerchant and buyer are still eligible\nNo revocation occurred before commitment\nNo duplicate order exists for the same idempotency key\n```\n\nThis separation matters because payment and order can fail independently.\n\nPayment can be authorized but order creation can fail.\n\nOrder creation can succeed while fulfillment later fails.\n\nPayment may need to be reversed if order commitment cannot complete.\n\nThese states should be explicit enough for recovery, support, and audit.\n\nDelegated payment operations must be idempotent.\n\nAgent-facing systems retry. Protocol calls can time out. Payment providers may return ambiguous responses. Users may confirm twice. Agents may repeat a command after not receiving a result.\n\nA payment command should include an idempotency key:\n\n```\ntype PaymentCommand = {\n  commandId: string;\n  idempotencyKey: string;\n\n  checkoutId: string;\n  cartSnapshotId: string;\n  mandateId: string;\n\n  requestedAction: PaymentAction;\n  requestedAmount: number;\n  currency: string;\n\n  requestedAt: string;\n};\n```\n\nThe platform should enforce idempotency at the payment-transition boundary, not only in the adapter.\n\nExample:\n\n```\nFirst request:\nauthorize_payment is submitted to the provider.\n\nNetwork response:\nlost.\n\nRetry with same idempotency key:\nplatform returns the existing payment attempt state instead of creating a second authorization.\n```\n\nIdempotency should be tied to the commercial command.\n\nIf cart snapshot, amount, currency, merchant, or mandate changes, the platform should not treat the new request as the same command.\n\nIdempotency prevents duplicate execution. It should not hide meaningful changes.\n\nPayment systems can return ambiguous outcomes.\n\nExamples:\n\n```\nProvider request timed out.\nProvider accepted request but response was lost.\nPayment is pending buyer action.\nPayment is under review.\nAuthorization succeeded but capture failed.\nCapture status is unknown.\nWebhook has not arrived.\n```\n\nA delegated payment model needs states for these conditions.\n\n```\ntype PaymentAttemptState =\n  | \"not_started\"\n  | \"authority_validated\"\n  | \"pending_provider_response\"\n  | \"requires_buyer_action\"\n  | \"authorized\"\n  | \"captured\"\n  | \"failed\"\n  | \"ambiguous\"\n  | \"cancelled\";\n```\n\nThe platform should not commit an order unless the payment state satisfies the platform’s order rules.\n\nFor example:\n\n```\nPayment attempt is ambiguous.\nOrder commitment is blocked until payment result is resolved.\n```\n\nor:\n\n```\nPayment authorized.\nOrder may be committed if the platform allows authorization-before-capture.\n```\n\nThe correct rule depends on the business and payment model. The important point is that ambiguous payment is not treated as success or failure without evidence.\n\nPart 5 argued that adapters should translate domain decisions rather than own them. Delegated payment is where that boundary matters most.\n\nAn AP2-related adapter or any payment-oriented protocol adapter may receive a structured payment artifact. It may validate protocol shape. It may verify envelope requirements if that belongs at the protocol boundary. It may extract references and pass them into the platform.\n\nIt should not decide that payment is allowed.\n\nBad boundary:\n\n```\nasync function paymentAdapter(req: ProtocolPaymentRequest) {\n  if (req.paymentToken && req.amount <= req.paymentToken.maxAmount) {\n    return payments.charge(req.paymentToken, req.amount);\n  }\n\n  return { error: \"not_authorized\" };\n}\n```\n\nThis ignores checkout state, cart snapshot, merchant binding, currency, expiry, revocation, confirmation, idempotency, and audit.\n\nBetter boundary:\n\n``` js\nasync function paymentAdapter(req: ProtocolPaymentRequest) {\n  const command = mapToPaymentCommand(req);\n\n  const result = await paymentAuthority.evaluateAndExecute(command);\n\n  return projectPaymentResult(result);\n}\n```\n\nThe adapter translates. The authority and payment domains decide.\n\nThis keeps payment semantics inside the platform instead of scattering them across protocol integrations.\n\nAgent-facing systems may generate buyer-facing messages such as:\n\n```\nI found the Travel Backpack for €129 and can buy it for you.\n```\n\nor:\n\n```\nThe total is under your €150 limit. Proceeding with payment.\n```\n\nThese messages are not authority.\n\nA generated statement does not prove buyer consent. It does not bind the cart snapshot. It does not verify currency. It does not satisfy confirmation unless the platform records confirmation as a domain event.\n\nA safe model is:\n\n```\nGenerated message:\nPresentation or explanation.\n\nBuyer confirmation:\nRecorded authority event.\n\nPayment mandate:\nStructured scope created or updated from confirmation.\n\nPayment decision:\nEvaluation of mandate against checkout state.\n\nPayment execution:\nState transition using the decision.\n```\n\nIf the buyer says “yes” in a conversation, the platform may treat that as input to a confirmation flow only if it captures the confirmation as structured evidence for a specific payment scope.\n\nFree-text conversation is not enough unless the platform has a defined way to turn it into evidence.\n\nA payment authority decision should be evidence-backed.\n\nFor an allowed decision, evidence may include:\n\n```\nMandate record\nCart snapshot\nCheckout state\nAmount calculation\nCurrency\nMerchant binding\nActor authority record\nConfirmation record\nExpiry check\nRevocation check\n```\n\nFor a blocked decision, evidence may include:\n\n```\nExpired mandate\nRevoked authority\nCart snapshot mismatch\nAmount exceeds limit\nCurrency mismatch\nMerchant mismatch\nCheckout not valid\nConfirmation missing\n```\n\nA simplified evidence reference model:\n\n```\ntype PaymentEvidenceRef = {\n  type:\n    | \"payment_mandate\"\n    | \"cart_snapshot\"\n    | \"checkout_state\"\n    | \"authority_record\"\n    | \"confirmation_record\"\n    | \"payment_attempt\"\n    | \"provider_response\"\n    | \"audit_event\";\n  id: string;\n};\n```\n\nThe platform should be able to explain:\n\n```\nWhy was delegated payment allowed?\nWhy was it blocked?\nWhich mandate was used?\nWhich cart snapshot was bound?\nWhich confirmation was satisfied?\nWhich provider response was received?\n```\n\nThis is necessary for debugging, support, reconciliation, agent behavior, and audit.\n\nPayment audit needs more detail than “payment attempted.”\n\nA useful audit record includes:\n\n```\nActor\nBuyer\nMerchant\nProtocol or channel\nCheckout ID\nCart snapshot ID\nMandate ID\nRequested amount\nCurrency\nAuthority decision\nPayment command\nIdempotency key\nProvider request reference\nProvider response reference\nPayment attempt state\nOrder commitment result\nEvidence references\nTimestamps\n```\n\nThis allows the platform to answer:\n\n```\nDid the buyer authorize this payment?\nDid the agent stay within the mandate?\nWas the cart changed after authorization?\nDid the total exceed the limit?\nWas confirmation required?\nWas confirmation satisfied?\nDid the mandate expire before payment?\nWas the payment retried?\nWas the order committed once or twice?\nWhich adapter initiated the request?\n```\n\nWithout this audit path, the platform may know that payment happened but not why it was allowed.\n\nFor delegated payment, that is not enough.\n\nNot every delegated payment failure is a buyer or payment-provider problem.\n\nSome blockers are operational:\n\n```\nPolicy coverage missing\nInventory stale\nShipping terms unknown\nPayment provider configuration missing\nMerchant binding missing\nMandate cannot be evaluated\nConfirmation workflow not configured\nWebhook reconciliation failed\n```\n\nThe platform should route actionable blockers to operator tasks.\n\nFor the Travel Backpack:\n\n```\nDelegated payment blocked:\ncheckout is not valid\n\nCheckout blockers:\ninventory stale\nreturn-policy coverage missing\n```\n\nOperator task:\n\n```\nResolve return-policy coverage for Travel Bags.\n\nImpact:\nAgents cannot prepare checkout or proceed to delegated payment for affected products.\n```\n\nPayment authority should not hide upstream blockers. It should preserve the causal chain so the right team fixes the right domain.\n\nDelegated payment modeling improves safety, but it introduces its own failure modes.\n\nA valid token is not enough. The platform must evaluate mandate scope, checkout state, cart snapshot, amount, currency, merchant, expiry, revocation, and confirmation.\n\nA valid checkout does not mean an actor may request payment. Authority is a separate domain.\n\nA provider authorization may satisfy one payment condition. It does not mean the order has been committed or that final order checks can be skipped.\n\nIf the mandate references only a cart ID, the cart may change after authorization. Authority should bind to a stable snapshot or require revalidation when the cart changes.\n\nA limit such as €150 must define whether shipping, tax, discounts, currency conversion, partial capture, and retries are allowed.\n\nCurrency mismatch should block payment unless conversion is explicitly modeled and authorized.\n\nA mandate for one merchant should not be usable for another merchant or seller unless the scope explicitly allows it.\n\nConfirmation should be recorded as a domain event when it affects authority. A button click, chat response, or external approval should become structured evidence if it authorizes payment.\n\nPayment idempotency must be enforced at the payment-transition boundary. Adapter-local deduplication is not enough.\n\nTimeouts and pending responses need explicit payment-attempt states. Order commitment should wait for a payment state that satisfies platform rules.\n\nIf delegated payment fails because checkout is invalid, the platform should preserve the checkout blocker. Otherwise agents and operators may retry payment when the real issue is policy, inventory, or checkout state.\n\nDelegated payment should be tested with scenario matrices.\n\nA useful test includes:\n\n```\nCheckout state\nCart snapshot\nMandate scope\nActor\nBuyer\nMerchant\nAmount\nCurrency\nExpiry\nRevocation\nConfirmation\nPayment attempt state\nExpected authority decision\nExpected payment transition\nExpected audit record\n```\n\nFor the Travel Backpack:\n\n| Scenario | Expected result |\n|---|---|\n| Payment artifact present but checkout blocked | Delegated payment blocked with `CHECKOUT_NOT_VALID`\n|\n| Checkout valid but no mandate exists | Payment blocked with `AUTHORITY_MISSING`\n|\n| Mandate exists but cart snapshot changed | Payment blocked with `CART_SNAPSHOT_MISMATCH`\n|\n| Mandate limit €150, final total €153 | Payment blocked with `AMOUNT_EXCEEDS_MANDATE`\n|\n| Mandate currency EUR, checkout currency USD | Payment blocked with `CURRENCY_MISMATCH`\n|\n| Mandate merchant differs from checkout merchant | Payment blocked with `MERCHANT_MISMATCH`\n|\n| Mandate expired before payment request | Payment blocked with `MANDATE_EXPIRED`\n|\n| Mandate revoked before payment request | Payment blocked with `MANDATE_REVOKED`\n|\n| Confirmation required but not satisfied | Payment returns `requires_confirmation`\n|\n| Confirmation satisfied and all scope checks pass | Payment may proceed to provider request |\n| Provider response times out | Payment attempt enters ambiguous or pending state |\n| Retry with same idempotency key | Existing payment attempt result is returned |\n| Retry with different cart snapshot | New request is rejected or requires new mandate |\n| Payment authorized but order commit fails | Order is not duplicated; recovery or reversal path is recorded |\n\nA simplified expectation type:\n\n```\ntype DelegatedPaymentScenarioExpectation = {\n  checkoutState: \"checkout_prepared\" | \"cart_blocked\" | \"expired\";\n\n  mandateStatus: PaymentMandateStatus;\n\n  expectedDecision:\n    | \"allowed\"\n    | \"blocked\"\n    | \"requires_confirmation\"\n    | \"requires_revalidation\";\n\n  expectedBlockerCodes: string[];\n\n  expectedPaymentAttemptState?: PaymentAttemptState;\n\n  expectedAuditEvent: boolean;\n};\n```\n\nThese tests should emphasize negative cases.\n\nThe safety of delegated payment depends more on correct refusal than on the happy path.\n\nA platform can implement delegated payment authority incrementally.\n\nSeparate artifact parsing from authority decisions.\n\nAdapters may parse protocol artifacts. The authority service decides what they mean.\n\nDefine a mandate model.\n\nInclude buyer, actor, merchant, cart snapshot, amount, currency, allowed actions, expiry, revocation, confirmation, and evidence.\n\nBind mandates to checkout snapshots.\n\nDo not rely only on mutable cart IDs.\n\nEvaluate checkout before payment.\n\nPayment authority should not bypass checkout validity.\n\nEnforce amount, currency, and merchant scope.\n\nThese should be explicit checks, not assumptions.\n\nModel confirmation as authority evidence.\n\nIf confirmation is required, record it as a structured event tied to a specific scope.\n\nAdd mandate lifecycle.\n\nSupport pending confirmation, active, expired, revoked, used, and rejected states.\n\nMake payment execution idempotent.\n\nRetries should not create duplicate authorizations, captures, or orders.\n\nModel ambiguous payment outcomes.\n\nDo not treat timeouts or missing provider responses as simple success or failure.\n\nAudit the full decision path.\n\nRecord mandate, checkout snapshot, authority decision, payment attempt, provider response, order commitment, evidence, and idempotency keys.\n\nThis path makes delegated payment safer without requiring the platform to solve every payment architecture problem at once.\n\nDelegated payment authority adds structure.\n\nIt requires mandate modeling, scope checks, snapshot binding, expiry, revocation, confirmation events, idempotency, payment-attempt states, evidence, and audit.\n\nFor a human-only storefront, some of this may be unnecessary. A user can review the checkout form, enter payment details, and submit payment directly.\n\nAgent-ready commerce changes the threshold.\n\nOnce an agent can act on behalf of a buyer, the platform must prove that the requested payment is still inside the buyer’s delegated authority at execution time.\n\nThe tradeoff is between convenience and bounded authority.\n\nA token is easy to pass around.\n\nA mandate is easier to reason about, test, revoke, audit, and defend.\n\nThe goal is not to make payment unnecessarily complex. The goal is to prevent a payment artifact from being treated as broader permission than it represents.\n\nDelegated payment needs more than a token.\n\nA token may be evidence. It may be part of a protocol. It may be part of payment execution. But agent-ready commerce needs a bounded authority model that answers a precise question:\n\n```\nMay this actor request this payment action for this buyer, merchant, checkout snapshot, amount, currency, and time window?\n```\n\nFor the Travel Backpack, delegated payment remains blocked even if a payment artifact exists, because checkout is not valid. Inventory is stale. Return-policy coverage is missing for Travel Bags. US shipping is unknown. A payment token cannot resolve those upstream blockers.\n\nA safe delegated payment model keeps the chain explicit:\n\n```\nCommercial truth\n      ↓\nEligibility\n      ↓\nCheckout state\n      ↓\nPayment authority\n      ↓\nPayment execution\n      ↓\nOrder commitment\n      ↓\nEvidence and audit\n```\n\nThat structure prevents protocol artifacts, generated messages, or adapter shortcuts from becoming accidental payment authority.\n\nPart 8 will move from payment authority to generated commercial claims:\n\n**Agent-Ready Commerce, Part 8: Generated Claims Need Review, Evidence, and Expiry**\n\nThat article will examine why AI-generated product descriptions, policy summaries, comparison text, recommendations, and checkout explanations should be treated as derived claims with review status, source references, freshness, invalidation rules, and audit rather than as automatic commercial truth.\n\nWritten by [Dimitrios S. Sfyris](https://gr.linkedin.com/in/dimitrios-s-sfyris), Founder & Software Architect at [AspectSoft](https://aspectsoft.gr/en/).\n\nAspectSoft designs and develops custom software platforms, e-commerce systems, SaaS infrastructure, integrations, analytics tools, and practical digital products.\n\nYou can also follow the [AspectSoft LinkedIn page](https://gr.linkedin.com/company/aspectsoft) for updates on software platforms, commerce systems, AI tooling, and developer-focused products.", "url": "https://wpnews.pro/news/agent-ready-commerce-part-7-delegated-payment-needs-more-than-a-token", "canonical_source": "https://dev.to/dmsfiris/agent-ready-commerce-part-7-delegated-payment-needs-more-than-a-token-k5c", "published_at": "2026-06-29 10:15:49+00:00", "updated_at": "2026-06-29 10:27:30.210309+00:00", "lang": "en", "topics": ["ai-agents", "ai-products", "developer-tools"], "entities": [], "alternates": {"html": "https://wpnews.pro/news/agent-ready-commerce-part-7-delegated-payment-needs-more-than-a-token", "markdown": "https://wpnews.pro/news/agent-ready-commerce-part-7-delegated-payment-needs-more-than-a-token.md", "text": "https://wpnews.pro/news/agent-ready-commerce-part-7-delegated-payment-needs-more-than-a-token.txt", "jsonld": "https://wpnews.pro/news/agent-ready-commerce-part-7-delegated-payment-needs-more-than-a-token.jsonld"}}