# Agent-Ready Commerce, Part 7: Delegated Payment Needs More Than a Token > Source: > Published: 2026-06-29 10:15:49+00:00 Delegated payment is not a question of whether a token exists. It 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. That distinction matters. A 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: ``` May this actor request this payment action for this buyer, merchant, checkout snapshot, amount, currency, and time window? ``` That question cannot be answered by token presence alone. It 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. Agent-ready commerce needs delegated payment to be modeled as bounded authority, not as a credential that turns checkout into payment. This is the seventh article in the Agent-Ready Commerce series. Part 1 introduced the broader architecture model: ``` Facts → Eligibility → Authority → State transition → Evidence → Audit ``` Part 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. Part 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. Part 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. Part 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. Part 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. This article focuses on payment authority. The 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. A safe platform follows this chain: ``` Payment artifact ↓ Mandate scope ↓ Checkout snapshot match ↓ Authority decision ↓ Payment execution ↓ Order commitment ↓ Evidence and audit ``` Each step answers a different question. Collapsing them into “token valid, proceed” creates unsafe payment behavior. Delegated payment should begin with a precise decision question. Not: ``` Is the token valid? ``` Not: ``` Does the agent have a payment artifact? ``` Not: ``` Is there a saved payment method? ``` The question is: ``` May this actor request this payment action for this buyer, merchant, checkout snapshot, amount, currency, and time window? ``` Each part of the question carries meaning. `This actor` matters because not every caller may act on behalf of the buyer. `This buyer` matters because authority is tied to the party whose funds, account, or payment instrument will be used. `This merchant` matters because permission to buy from one merchant does not automatically apply to another merchant or marketplace seller. `This checkout snapshot` matters because carts can change. `This amount` matters because a mandate may have a limit. `This currency` matters because €150 is not the same authority as $150 or an automatically converted amount. `This time window` matters because authority can expire or be revoked. A delegated payment system should make these dimensions explicit instead of hiding them behind a generic authorization field. Several concepts are easy to confuse. A 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. A mandate is the platform’s structured representation of delegated authority. It defines who may do what, for whom, under which constraints. An authority decision is the platform’s current evaluation of whether a requested payment action is inside the mandate. Payment execution is the state transition that attempts, authorizes, captures, or records payment. Order commitment is the state transition that creates the order after the platform’s payment and checkout rules are satisfied. These are related, but they are not interchangeable. ``` Artifact: Something was presented. Mandate: The platform understands the scope. Authority decision: The current request is allowed, blocked, or requires confirmation. Payment execution: The platform attempts the payment action. Order commitment: The platform creates the order. ``` A valid artifact can produce a blocked authority decision. A valid authority decision can still lead to a failed payment attempt. A successful payment authorization may still require a separate order commitment transition. This separation is not academic. It prevents the platform from treating one kind of proof as proof of everything. Continue with the running example from Parts 2–6: ``` Product: Travel Backpack SKU: BAG-TRAVEL-42 Price: €129 Catalog status: active Inventory status: in_stock Category: Travel Bags ``` The commercial truth layer currently says: ``` Price: fresh Inventory: stale Return policy: missing for Travel Bags Warranty policy: known Shipping policy: known for EU, unknown for US Generated description: pending review Feed publication: last published yesterday ``` From Part 3, the action matrix was: | Action | Result | |---|---| `discover` | allowed | `compare` | allowed | `quote_policy` | blocked | `add_to_cart` | requires_revalidation | `prepare_checkout` | blocked | `delegate_payment` | blocked | From Part 6, checkout preparation is blocked because inventory is stale and return-policy coverage is missing. Now suppose a buyer tells an agent: ``` Buy the Travel Backpack if the final total is under €150. ``` The agent may also carry a payment-related artifact that appears to authorize a purchase up to €150 in EUR. Delegated payment should still be blocked. The reason is not that the amount is too high. The product price is €129. The reason is that checkout itself is not valid. The 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. The platform should answer: ``` Delegated payment is blocked because checkout is not valid. ``` A safe causal chain is: ``` delegate_payment blocked ↓ checkout is not valid ↓ prepare_checkout is blocked ↓ inventory is stale return-policy coverage is missing ``` That chain should remain visible in the decision, evidence, and audit trail. Delegated payment involves several kinds of authority, not one. ``` Buyer authority: Did the buyer permit this actor to act? Platform authority: Does the platform allow this actor and action under its own rules? Payment-provider authorization: Did the payment provider authorize or accept the payment attempt? ``` These are different. A buyer may authorize an agent to purchase an item, but the platform may still block the action because checkout is invalid. The platform may allow the agent to request payment, but the payment provider may decline the payment attempt. The payment provider may authorize a payment, but the platform may still fail to commit the order because final order checks fail. The boundaries are: ``` Buyer authority is not checkout validity. Checkout validity is not provider authorization. Provider authorization is not order commitment. ``` A safe delegated payment design does not collapse these states. A token may be part of a mandate, but it is not the mandate by itself. A delegated payment mandate should answer: ``` Who is the buyer? Which actor is allowed to act? Which merchant is in scope? Which checkout or cart snapshot is in scope? What is the maximum amount? Which currency is allowed? Which payment actions are allowed? When does the authority expire? Can it be revoked? Is human confirmation required? Which evidence supports the authority? ``` A simplified TypeScript model might look like this: ``` type PaymentMandateStatus = | "pending_confirmation" | "active" | "expired" | "revoked" | "used" | "rejected"; type PaymentAction = | "prepare_payment" | "authorize_payment" | "capture_payment" | "commit_order"; type PaymentMandate = { mandateId: string; status: PaymentMandateStatus; buyerId: string; actor: { actorId: string; actorType: "human" | "agent" | "system"; }; scope: { merchantId: string; cartSnapshotId: string; maxAmount: number; currency: string; allowedActions: PaymentAction[]; }; confirmation: { required: boolean; satisfied: boolean; confirmationRef?: string; }; lifecycle: { createdAt: string; expiresAt: string; revokedAt?: string; revokedReason?: string; usedAt?: string; }; evidenceRefs: string[]; }; ``` This 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. The important property is scope. Without scope, the platform cannot prove that a payment request is still inside the buyer’s delegated authority. A delegated payment decision should be current. It 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. The platform should evaluate authority at the point of payment execution. A simplified decision type: ``` type PaymentAuthorityDecision = { decisionId: string; actorId: string; buyerId: string; merchantId: string; checkoutId: string; cartSnapshotId: string; mandateId: string; requestedAction: PaymentAction; requestedAmount: number; currency: string; result: | "allowed" | "blocked" | "requires_confirmation" | "requires_revalidation"; blockers: Array<{ code: string; message: string; nextAction?: string; }>; evidenceRefs: string[]; evaluatedAt: string; }; ``` For the Travel Backpack: ``` js const decision: PaymentAuthorityDecision = { decisionId: "decision_001", actorId: "agent_123", buyerId: "buyer_456", merchantId: "merchant_001", checkoutId: "checkout_789", cartSnapshotId: "snapshot_abc", mandateId: "mandate_001", requestedAction: "authorize_payment", requestedAmount: 129, currency: "EUR", result: "blocked", blockers: [ { code: "CHECKOUT_NOT_VALID", message: "Delegated payment cannot proceed because checkout preparation is blocked.", nextAction: "Resolve checkout blockers before requesting delegated payment." } ], evidenceRefs: [ "checkout:checkout_789:state", "eligibility:BAG-TRAVEL-42:prepare_checkout" ], evaluatedAt: "2026-06-28T09:00:00Z" }; ``` This decision does not need to reimplement checkout. It references the checkout decision. That is the point of the chain. Payment authority depends on checkout validity. It does not replace it. A delegated payment system should not evaluate payment authority in isolation from checkout state. The safer order is: ``` Commercial truth ↓ Eligibility ↓ Checkout state ↓ Payment authority ↓ Payment execution ↓ Order commitment ``` Payment authority should not bypass earlier checks. A buyer may authorize an agent to buy the Travel Backpack up to €150. That does not mean: ``` Ignore stale inventory. Ignore missing return policy. Ignore unsupported shipping region. Ignore generated-claim review. Ignore checkout expiry. ``` It means: ``` If checkout is valid and the payment request matches the mandate scope, the actor may request payment within the mandate’s limits. ``` That is a narrower and safer statement. The buyer can authorize an agent to act. The platform must still decide whether the action is commercially valid. A mandate should bind to a checkout snapshot, not only to a cart ID. A 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. A cart snapshot records the commercial state that was evaluated. ``` type CartSnapshot = { snapshotId: string; cartId: string; items: Array<{ sku: string; quantity: number; priceAmount: number; currency: string; }>; totals: { subtotal: number; shipping?: number; tax?: number; total: number; currency: string; }; merchantId: string; context: { region?: string; buyerType?: "consumer" | "business"; channel: "storefront" | "agent" | "marketplace"; }; factRefs: string[]; policyFactRefs: string[]; createdAt: string; }; ``` Before payment, the platform should verify: ``` Does the checkout use the same snapshot? Do the items match? Does the total remain within the mandate? Does the currency match? Does the merchant match? Has the snapshot expired? ``` This prevents a critical failure mode: ``` Buyer authorizes one cart. Cart changes. Agent requests payment for the changed cart. Platform treats the old authority as valid. ``` That should not be possible. If the cart changes after authority is granted, the platform should require revalidation or a new mandate. A buyer instruction such as “under €150” is not enough unless the platform defines what the amount includes. Does the limit include shipping? Does it include tax? Does it include discounts? Does it allow partial capture? Does it allow a lower amount? Does it allow multiple attempts? Does it allow currency conversion? A useful amount scope is explicit: ``` type AmountScope = { maxAmount: number; currency: string; includesShipping: boolean; includesTax: boolean; allowLowerAmount: boolean; allowPartialCapture: boolean; maxPaymentAttempts: number; }; ``` For the Travel Backpack: ``` Product price: €129 Buyer limit: €150 Currency: EUR ``` The product price alone is not enough. If 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. A safe decision: ``` Delegated payment blocked. Reason: final checkout total exceeds the mandate amount limit. ``` That is not a product-truth issue. It is an authority-scope issue. Currency should not be treated as display metadata. A mandate for €150 is not the same as a mandate for $150, £150, or an automatically converted amount. If currency conversion is allowed, that should be explicit. If it is not explicit, currency mismatch should block delegated payment. ``` type CurrencyScope = { currency: string; conversionAllowed: boolean; conversionSource?: string; maxConvertedAmount?: number; }; ``` A conservative delegated payment decision: ``` Mandate currency: EUR Checkout currency: USD Result: blocked Reason: currency mismatch ``` A platform may support approved conversion flows, but those flows need their own rules and evidence. Implicit conversion is not a safe default for delegated payment. A payment mandate should bind to a merchant, marketplace, seller, or defined merchant group. Permission to buy from one merchant does not automatically apply to another merchant. ``` type MerchantScope = { merchantId: string; marketplaceId?: string; allowedSellerIds?: string[]; }; ``` In a direct commerce platform, merchant scope may be simple. In 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. The important rule is that merchant scope is checked before payment. ``` Mandate merchant: merchant_001 Checkout merchant: merchant_002 Result: blocked Reason: merchant mismatch ``` A protocol artifact that is valid in general is not valid for every merchant. Delegated payment involves at least two identities: ``` The buyer whose funds, account, or payment instrument is used. The actor requesting the payment action. ``` The actor may be a human, an agent, a system process, or another delegated entity. The platform should not confuse the buyer’s ability to purchase with the actor’s authority to act. The buyer may be eligible to buy, but the agent may not be authorized to request payment. The agent may have authority to prepare checkout but not to authorize payment. The agent may have authority for one cart snapshot but not another. A platform should evaluate: ``` Buyer eligibility: Can this buyer make this purchase? Actor authority: Can this actor request this payment action for this buyer? Mandate scope: Does the request match cart, amount, currency, merchant, time, and confirmation rules? ``` A simplified actor authority model: ``` type ActorAuthority = { actorId: string; buyerId: string; allowedActions: PaymentAction[]; constraints: { merchantId?: string; cartSnapshotId?: string; maxAmount?: number; currency?: string; }; status: "active" | "expired" | "revoked"; }; ``` The existence of a protocol request does not prove actor authority. The platform must evaluate it. Some delegated payment flows require human confirmation. The 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. Confirmation should be modeled explicitly. ``` type ConfirmationRule = { required: boolean; requiredWhen?: Array< | "amount_changed" | "cart_changed" | "shipping_changed" | "policy_changed" | "risk_review_required" >; satisfiedAt?: string; confirmationRef?: string; }; ``` Examples: ``` No confirmation required: Agent may request payment if the final total is within mandate scope. Confirmation required: Agent may prepare checkout, but buyer must approve before payment. Conditional confirmation: Buyer approval is required if the total increases or shipping changes. ``` A 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. Presentation is not authority. Confirmation becomes authority evidence only when the platform captures it as such. A mandate should expire. It should also be revocable. Expiry handles time-based risk. Revocation handles buyer decisions, fraud signals, support actions, account restrictions, or business rules that invalidate authority before the expiry time. ``` type MandateLifecycle = { status: | "pending_confirmation" | "active" | "expired" | "revoked" | "used" | "rejected"; createdAt: string; expiresAt: string; revokedAt?: string; revokedReason?: string; usedAt?: string; }; ``` Before payment execution, the platform should check current mandate status. ``` Mandate was active when checkout was prepared. Mandate was revoked before payment was requested. Result: blocked. ``` This should not depend on the agent’s memory, an adapter cache, or a stale protocol response. The authority service should own mandate lifecycle. Requesting payment is not only an API call to a payment provider. It is a state transition in the commerce platform. A simplified payment path might look like this: ``` checkout_prepared ↓ payment_authority_required ↓ payment_authority_validated ↓ payment_pending ↓ payment_authorized ↓ order_committed ``` Some 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. The design rule is stable: ``` Payment execution should have explicit preconditions, outcomes, evidence, and audit. ``` A payment request should record: ``` Which checkout snapshot was used Which mandate was evaluated Which authority decision was produced Which amount and currency were requested Which provider request was made Which response was received Whether the result is final or ambiguous Which audit event was recorded ``` This prevents the payment provider call from becoming an opaque side effect. A payment provider may authorize or accept a payment attempt. That still does not mean the order has been committed. The platform may need to create the order, reserve or allocate inventory, write invoices, emit events, trigger fulfillment, update customer records, and produce audit evidence. Order commitment should be its own transition. ``` Payment authorized ↓ Commit order command ↓ Final validation ↓ Order committed ``` Final validation may include: ``` Cart snapshot still matches Payment result satisfies order rules Inventory reservation is valid Merchant and buyer are still eligible No revocation occurred before commitment No duplicate order exists for the same idempotency key ``` This separation matters because payment and order can fail independently. Payment can be authorized but order creation can fail. Order creation can succeed while fulfillment later fails. Payment may need to be reversed if order commitment cannot complete. These states should be explicit enough for recovery, support, and audit. Delegated payment operations must be idempotent. Agent-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. A payment command should include an idempotency key: ``` type PaymentCommand = { commandId: string; idempotencyKey: string; checkoutId: string; cartSnapshotId: string; mandateId: string; requestedAction: PaymentAction; requestedAmount: number; currency: string; requestedAt: string; }; ``` The platform should enforce idempotency at the payment-transition boundary, not only in the adapter. Example: ``` First request: authorize_payment is submitted to the provider. Network response: lost. Retry with same idempotency key: platform returns the existing payment attempt state instead of creating a second authorization. ``` Idempotency should be tied to the commercial command. If cart snapshot, amount, currency, merchant, or mandate changes, the platform should not treat the new request as the same command. Idempotency prevents duplicate execution. It should not hide meaningful changes. Payment systems can return ambiguous outcomes. Examples: ``` Provider request timed out. Provider accepted request but response was lost. Payment is pending buyer action. Payment is under review. Authorization succeeded but capture failed. Capture status is unknown. Webhook has not arrived. ``` A delegated payment model needs states for these conditions. ``` type PaymentAttemptState = | "not_started" | "authority_validated" | "pending_provider_response" | "requires_buyer_action" | "authorized" | "captured" | "failed" | "ambiguous" | "cancelled"; ``` The platform should not commit an order unless the payment state satisfies the platform’s order rules. For example: ``` Payment attempt is ambiguous. Order commitment is blocked until payment result is resolved. ``` or: ``` Payment authorized. Order may be committed if the platform allows authorization-before-capture. ``` The 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. Part 5 argued that adapters should translate domain decisions rather than own them. Delegated payment is where that boundary matters most. An 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. It should not decide that payment is allowed. Bad boundary: ``` async function paymentAdapter(req: ProtocolPaymentRequest) { if (req.paymentToken && req.amount <= req.paymentToken.maxAmount) { return payments.charge(req.paymentToken, req.amount); } return { error: "not_authorized" }; } ``` This ignores checkout state, cart snapshot, merchant binding, currency, expiry, revocation, confirmation, idempotency, and audit. Better boundary: ``` js async function paymentAdapter(req: ProtocolPaymentRequest) { const command = mapToPaymentCommand(req); const result = await paymentAuthority.evaluateAndExecute(command); return projectPaymentResult(result); } ``` The adapter translates. The authority and payment domains decide. This keeps payment semantics inside the platform instead of scattering them across protocol integrations. Agent-facing systems may generate buyer-facing messages such as: ``` I found the Travel Backpack for €129 and can buy it for you. ``` or: ``` The total is under your €150 limit. Proceeding with payment. ``` These messages are not authority. A 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. A safe model is: ``` Generated message: Presentation or explanation. Buyer confirmation: Recorded authority event. Payment mandate: Structured scope created or updated from confirmation. Payment decision: Evaluation of mandate against checkout state. Payment execution: State transition using the decision. ``` If 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. Free-text conversation is not enough unless the platform has a defined way to turn it into evidence. A payment authority decision should be evidence-backed. For an allowed decision, evidence may include: ``` Mandate record Cart snapshot Checkout state Amount calculation Currency Merchant binding Actor authority record Confirmation record Expiry check Revocation check ``` For a blocked decision, evidence may include: ``` Expired mandate Revoked authority Cart snapshot mismatch Amount exceeds limit Currency mismatch Merchant mismatch Checkout not valid Confirmation missing ``` A simplified evidence reference model: ``` type PaymentEvidenceRef = { type: | "payment_mandate" | "cart_snapshot" | "checkout_state" | "authority_record" | "confirmation_record" | "payment_attempt" | "provider_response" | "audit_event"; id: string; }; ``` The platform should be able to explain: ``` Why was delegated payment allowed? Why was it blocked? Which mandate was used? Which cart snapshot was bound? Which confirmation was satisfied? Which provider response was received? ``` This is necessary for debugging, support, reconciliation, agent behavior, and audit. Payment audit needs more detail than “payment attempted.” A useful audit record includes: ``` Actor Buyer Merchant Protocol or channel Checkout ID Cart snapshot ID Mandate ID Requested amount Currency Authority decision Payment command Idempotency key Provider request reference Provider response reference Payment attempt state Order commitment result Evidence references Timestamps ``` This allows the platform to answer: ``` Did the buyer authorize this payment? Did the agent stay within the mandate? Was the cart changed after authorization? Did the total exceed the limit? Was confirmation required? Was confirmation satisfied? Did the mandate expire before payment? Was the payment retried? Was the order committed once or twice? Which adapter initiated the request? ``` Without this audit path, the platform may know that payment happened but not why it was allowed. For delegated payment, that is not enough. Not every delegated payment failure is a buyer or payment-provider problem. Some blockers are operational: ``` Policy coverage missing Inventory stale Shipping terms unknown Payment provider configuration missing Merchant binding missing Mandate cannot be evaluated Confirmation workflow not configured Webhook reconciliation failed ``` The platform should route actionable blockers to operator tasks. For the Travel Backpack: ``` Delegated payment blocked: checkout is not valid Checkout blockers: inventory stale return-policy coverage missing ``` Operator task: ``` Resolve return-policy coverage for Travel Bags. Impact: Agents cannot prepare checkout or proceed to delegated payment for affected products. ``` Payment authority should not hide upstream blockers. It should preserve the causal chain so the right team fixes the right domain. Delegated payment modeling improves safety, but it introduces its own failure modes. A valid token is not enough. The platform must evaluate mandate scope, checkout state, cart snapshot, amount, currency, merchant, expiry, revocation, and confirmation. A valid checkout does not mean an actor may request payment. Authority is a separate domain. A provider authorization may satisfy one payment condition. It does not mean the order has been committed or that final order checks can be skipped. If 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. A limit such as €150 must define whether shipping, tax, discounts, currency conversion, partial capture, and retries are allowed. Currency mismatch should block payment unless conversion is explicitly modeled and authorized. A mandate for one merchant should not be usable for another merchant or seller unless the scope explicitly allows it. Confirmation 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. Payment idempotency must be enforced at the payment-transition boundary. Adapter-local deduplication is not enough. Timeouts and pending responses need explicit payment-attempt states. Order commitment should wait for a payment state that satisfies platform rules. If 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. Delegated payment should be tested with scenario matrices. A useful test includes: ``` Checkout state Cart snapshot Mandate scope Actor Buyer Merchant Amount Currency Expiry Revocation Confirmation Payment attempt state Expected authority decision Expected payment transition Expected audit record ``` For the Travel Backpack: | Scenario | Expected result | |---|---| | Payment artifact present but checkout blocked | Delegated payment blocked with `CHECKOUT_NOT_VALID` | | Checkout valid but no mandate exists | Payment blocked with `AUTHORITY_MISSING` | | Mandate exists but cart snapshot changed | Payment blocked with `CART_SNAPSHOT_MISMATCH` | | Mandate limit €150, final total €153 | Payment blocked with `AMOUNT_EXCEEDS_MANDATE` | | Mandate currency EUR, checkout currency USD | Payment blocked with `CURRENCY_MISMATCH` | | Mandate merchant differs from checkout merchant | Payment blocked with `MERCHANT_MISMATCH` | | Mandate expired before payment request | Payment blocked with `MANDATE_EXPIRED` | | Mandate revoked before payment request | Payment blocked with `MANDATE_REVOKED` | | Confirmation required but not satisfied | Payment returns `requires_confirmation` | | Confirmation satisfied and all scope checks pass | Payment may proceed to provider request | | Provider response times out | Payment attempt enters ambiguous or pending state | | Retry with same idempotency key | Existing payment attempt result is returned | | Retry with different cart snapshot | New request is rejected or requires new mandate | | Payment authorized but order commit fails | Order is not duplicated; recovery or reversal path is recorded | A simplified expectation type: ``` type DelegatedPaymentScenarioExpectation = { checkoutState: "checkout_prepared" | "cart_blocked" | "expired"; mandateStatus: PaymentMandateStatus; expectedDecision: | "allowed" | "blocked" | "requires_confirmation" | "requires_revalidation"; expectedBlockerCodes: string[]; expectedPaymentAttemptState?: PaymentAttemptState; expectedAuditEvent: boolean; }; ``` These tests should emphasize negative cases. The safety of delegated payment depends more on correct refusal than on the happy path. A platform can implement delegated payment authority incrementally. Separate artifact parsing from authority decisions. Adapters may parse protocol artifacts. The authority service decides what they mean. Define a mandate model. Include buyer, actor, merchant, cart snapshot, amount, currency, allowed actions, expiry, revocation, confirmation, and evidence. Bind mandates to checkout snapshots. Do not rely only on mutable cart IDs. Evaluate checkout before payment. Payment authority should not bypass checkout validity. Enforce amount, currency, and merchant scope. These should be explicit checks, not assumptions. Model confirmation as authority evidence. If confirmation is required, record it as a structured event tied to a specific scope. Add mandate lifecycle. Support pending confirmation, active, expired, revoked, used, and rejected states. Make payment execution idempotent. Retries should not create duplicate authorizations, captures, or orders. Model ambiguous payment outcomes. Do not treat timeouts or missing provider responses as simple success or failure. Audit the full decision path. Record mandate, checkout snapshot, authority decision, payment attempt, provider response, order commitment, evidence, and idempotency keys. This path makes delegated payment safer without requiring the platform to solve every payment architecture problem at once. Delegated payment authority adds structure. It requires mandate modeling, scope checks, snapshot binding, expiry, revocation, confirmation events, idempotency, payment-attempt states, evidence, and audit. For a human-only storefront, some of this may be unnecessary. A user can review the checkout form, enter payment details, and submit payment directly. Agent-ready commerce changes the threshold. Once 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. The tradeoff is between convenience and bounded authority. A token is easy to pass around. A mandate is easier to reason about, test, revoke, audit, and defend. The 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. Delegated payment needs more than a token. A 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: ``` May this actor request this payment action for this buyer, merchant, checkout snapshot, amount, currency, and time window? ``` For 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. A safe delegated payment model keeps the chain explicit: ``` Commercial truth ↓ Eligibility ↓ Checkout state ↓ Payment authority ↓ Payment execution ↓ Order commitment ↓ Evidence and audit ``` That structure prevents protocol artifacts, generated messages, or adapter shortcuts from becoming accidental payment authority. Part 8 will move from payment authority to generated commercial claims: **Agent-Ready Commerce, Part 8: Generated Claims Need Review, Evidence, and Expiry** That 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. Written by [Dimitrios S. Sfyris](https://gr.linkedin.com/in/dimitrios-s-sfyris), Founder & Software Architect at [AspectSoft](https://aspectsoft.gr/en/). AspectSoft designs and develops custom software platforms, e-commerce systems, SaaS infrastructure, integrations, analytics tools, and practical digital products. You 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.