DEV Community

Cover image for Agent-Ready Commerce, Part 7: Delegated Payment Needs More Than a Token
Dimitrios S. Sfyris
Dimitrios S. Sfyris

Posted on • Edited on

Agent-Ready Commerce, Part 7: Delegated Payment Needs More Than a Token

#ai #architecture #ecommerce #systemdesign

Delegated payment is not a question of whether a token exists.

The real question is whether this exact payment request is still inside the buyer's delegated authority at the moment of execution.

That distinction matters.

A token, signed message, mandate reference, payment artifact, or protocol payload may be technically valid: the signature verifies, the artifact has not expired, and the issuer is trusted. That still does not prove that the current cart, amount, currency, merchant, actor, and checkout state are authorized.

May this actor request this payment action for this buyer, merchant, checkout snapshot, amount, currency, and time window?
Enter fullscreen mode Exit fullscreen mode

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.

Series context

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
Enter fullscreen mode Exit fullscreen mode

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 quotability.

Part 5 focused on protocol adapters. It argued that ACP, UCP, MCP, AP2-related flows, 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 use explicit checkout state with controlled transitions, 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
Enter fullscreen mode Exit fullscreen mode

Each step answers a different question. Collapsing them into “token valid, proceed” creates unsafe payment behavior.

The exact question matters

Delegated payment should begin with a precise decision question.

Not:

Is the token valid?
Enter fullscreen mode Exit fullscreen mode

Not:

Does the agent have a payment artifact?
Enter fullscreen mode Exit fullscreen mode

Not:

Is there a saved payment method?
Enter fullscreen mode Exit fullscreen mode

The question is:

May this actor request this payment action for this buyer, merchant, checkout snapshot, amount, currency, and time window?
Enter fullscreen mode Exit fullscreen mode

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.

Payment artifact, mandate, authority decision, and execution answer four different questions

Several payment-related concepts are often collapsed into one word. Separating them makes the payment boundary easier to reason about.

Concept Meaning
Payment artifact A token, signed payload, reference, or protocol object presented to the platform
Mandate The bounded delegation the buyer or authority source granted
Authority decision The platform’s payment-specific evaluation of whether the request is inside the mandate once actor authority and checkout validity permit evaluation
Execution The provider-facing payment attempt

The artifact is evidence.

The mandate is scope.

The authority decision is the platform answer.

Execution is a state-changing action.

A valid artifact can support authority evaluation, but it cannot create product eligibility, repair incomplete checkout state, override stale inventory, or invent missing policy coverage.

That is why delegated payment belongs in the shared decision envelope as a payment section, not as an adapter-local flag:

payment.authorityResult
payment.blockerCodes
payment.paymentDispatchAttempted
Enter fullscreen mode Exit fullscreen mode

The Travel Backpack example

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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.
Enter fullscreen mode Exit fullscreen mode

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 state is not valid for payment.

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 state is not valid for payment.
Payment authority is not evaluated.
Payment dispatch is not attempted.
Enter fullscreen mode Exit fullscreen mode

A safe causal chain is:

delegate_payment blocked
      ↓
checkout state is not valid for payment
      ↓
prepare_checkout is blocked
      ↓
inventory is stale
return-policy coverage is missing
Enter fullscreen mode Exit fullscreen mode

That chain should remain visible in the decision, evidence, and audit trail.

Three kinds of authority

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?
Enter fullscreen mode Exit fullscreen mode

These are different.

A buyer may authorize an agent to purchase an item, but the platform may still block the action because checkout state is not valid for payment.

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 validation.
A valid checkout state is not provider authorization.
Provider authorization is not order commitment.
Enter fullscreen mode Exit fullscreen mode

A safe delegated payment design does not collapse these states.

A token is not a mandate

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?
Enter fullscreen mode Exit fullscreen mode

A simplified TypeScript model might look like this:

type AgentCommerceMandateStatus =
  | "ACTIVE"
  | "ACCEPTED"
  | "CONSUMED"
  | "REVOKED"
  | "EXPIRED";

type AgentCommerceMandateAction =
  | "delegate_payment"
  | "complete_checkout";

type EvidenceRef = {
  type: string;
  id: string;
  hash: string;
  hashAlgorithm: "sha256";
};

type AgentCommerceMandateRecord = {
  mandateId: string;
  status: AgentCommerceMandateStatus;

  buyerId: string;

  actor: {
    actorId: string;
    actorType: "buyer" | "agent" | "operator" | "system";
  };

  scope: {
    merchantId: string;
    cartSnapshotId: string;
    maxAmount: number;
    currency: string;
    allowedActions: AgentCommerceMandateAction[];
  };

  confirmation: {
    required: boolean;
    satisfied: boolean;
    confirmationRef?: string;
  };

  lifecycle: {
    createdAt: string;
    expiresAt: string;
    revokedAt?: string;
    revokedReason?: string;
    usedAt?: string;
  };

  evidenceRefs: EvidenceRef[];
};
Enter fullscreen mode Exit fullscreen mode

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 show that a payment request is still inside the buyer’s delegated authority.

The current mandate record should keep the scope that is valid now, while one meaningful mandate event history records creation, confirmation, consumption, revocation, expiry, and rejected use. Confirmation, checkout snapshot, amount, currency, merchant, and boundary hash are part of what the platform compares at execution time. A mandate valid for one snapshot should not silently authorize payment against a changed one.

Evaluate authority again at execution time

A delegated payment decision should reflect the current checkout, mandate, and payment request—not an earlier version of them.

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 EvidenceRef = {
  type: string;
  id: string;
  hash: string;
  hashAlgorithm: "sha256";
};

type AgentCommercePaymentAuthorityVerdict = {
  decisionId: string;

  actorId: string;
  buyerId: string;
  merchantId: string;

  checkoutId: string;
  cartSnapshotId: string;
  mandateId: string;

  requestedAction: AgentCommerceMandateAction;
  requestedAmount: number;
  currency: string;

  result:
    | "allowed"
    | "blocked"
    | "requires_confirmation"
    | "requires_revalidation";

  blockers: Array<{
    code: string;
    message: string;
    nextAction?: string;
  }>;

  evidenceRefs: EvidenceRef[];
  evaluatedAt: string;
};
Enter fullscreen mode Exit fullscreen mode

For the Travel Backpack:

const decision: AgentCommercePaymentAuthorityVerdict = {
  decisionId: "decision_001",
  actorId: "agent_123",
  buyerId: "buyer_456",
  merchantId: "merchant_001",
  checkoutId: "checkout_789",
  cartSnapshotId: "snapshot_abc",
  mandateId: "mandate_001",
  requestedAction: "delegate_payment",
  requestedAmount: 129,
  currency: "EUR",
  result: "blocked",
  blockers: [
    {
      code: "invalid_checkout_state",
      message:
        "Delegated payment cannot proceed because checkout preparation is blocked.",
      nextAction:
        "Resolve checkout blockers before requesting delegated payment."
    }
  ],
  evidenceRefs: [
    {
      type: "checkout_state",
      id: "checkout:checkout_789:state",
      hash: "<sha256-of-canonical-checkout-snapshot>",
      hashAlgorithm: "sha256"
    },
    {
      type: "eligibility_decision",
      id: "eligibility:BAG-TRAVEL-42:prepare_checkout",
      hash: "<sha256-of-canonical-eligibility-decision>",
      hashAlgorithm: "sha256"
    }
  ],
  evaluatedAt: "2026-06-28T09:00:00Z"
};
Enter fullscreen mode Exit fullscreen mode

This decision does not need to reimplement checkout. It references the checkout state.

That is the point of the chain.

Payment authority depends on valid checkout state. It does not replace checkout validation.

Valid checkout state comes first

A delegated payment system should not evaluate payment authority in isolation from checkout state. If actor authority or checkout validity prevents that evaluation, payment authority should remain not_evaluated with no payment-specific blockers. The checkout or authority section retains the actual reason the operation cannot proceed.

The safer order is:

Commercial truth
      ↓
Eligibility
      ↓
Checkout state
      ↓
Payment authority
      ↓
Payment execution
      ↓
Order commitment
Enter fullscreen mode Exit fullscreen mode

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.
Enter fullscreen mode Exit fullscreen mode

It means:

If checkout state is valid for payment and the payment request matches the mandate scope, the actor may request payment within the mandate’s limits.
Enter fullscreen mode Exit fullscreen mode

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.

Cart snapshots are the evidence boundary

A mandate should bind to a checkout snapshot, not only to a cart ID.

A cart ID identifies a mutable container. It does not show 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;
};
Enter fullscreen mode Exit fullscreen mode

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?
Enter fullscreen mode Exit fullscreen mode

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.
Enter fullscreen mode Exit fullscreen mode

That should not be possible.

If the cart changes after authority is granted, the platform should require revalidation or a new mandate.

Amount limits need exact semantics

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;
};
Enter fullscreen mode Exit fullscreen mode

For the Travel Backpack:

Product price: €129
Buyer limit: €150
Currency: EUR
Enter fullscreen mode Exit fullscreen mode

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.
Enter fullscreen mode Exit fullscreen mode

That is not a product-truth issue. It is an authority-scope issue.

Currency is part of authority

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;
};
Enter fullscreen mode Exit fullscreen mode

A conservative delegated payment decision:

Mandate currency: EUR
Checkout currency: USD
Result: blocked
Reason: currency mismatch
Enter fullscreen mode Exit fullscreen mode

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.

Merchant binding matters

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[];
};
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

A protocol artifact that is valid in general is not valid for every merchant.

Actor authority and buyer authority are separate

Delegated payment involves at least two identities:

The buyer whose funds, account, or payment instrument is used.
The actor requesting the payment action.
Enter fullscreen mode Exit fullscreen mode

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?
Enter fullscreen mode Exit fullscreen mode

A simplified actor authority model:

type ActorAuthority = {
  actorId: string;
  buyerId: string;

  allowedActions: AgentCommerceMandateAction[];

  constraints: {
    merchantId?: string;
    cartSnapshotId?: string;
    maxAmount?: number;
    currency?: string;
  };

  status: "ACTIVE" | "ACCEPTED" | "EXPIRED" | "REVOKED";
};
Enter fullscreen mode Exit fullscreen mode

The existence of a protocol request does not establish actor authority.

The platform must evaluate it.

Confirmation is authority evidence

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;
};
Enter fullscreen mode Exit fullscreen mode

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.
Enter fullscreen mode Exit fullscreen mode

A chat message such as “yes, buy it” should not become payment authority unless the platform records it as a structured confirmation tied to a specific snapshot, scope, and evidence reference.

Presentation is not authority.

Confirmation becomes authority evidence only when the platform captures it as such.

Expiry and revocation are first-class

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: AgentCommerceMandateStatus;

  createdAt: string;
  expiresAt: string;

  revokedAt?: string;
  revokedReason?: string;

  usedAt?: string;
};
Enter fullscreen mode Exit fullscreen mode

Before payment execution, the platform should check the current mandate status and compare the payment request with the mandate scope and evidence.

Mandate was active when checkout was prepared.
Mandate was revoked before payment was requested.
Result: blocked.
Enter fullscreen mode Exit fullscreen mode

This should not depend on the agent’s memory, an adapter cache, or a stale protocol response.

One delegated-authority owner should own mandate state, scope, confirmation, consumption, revocation, and mandate events.

Payment execution is also a state transition

Requesting payment is not only an API call to a payment provider.

It is a state transition in the commerce platform.

A simplified checkout and payment path might look like this:

requires_payment
      ↓
payment_authorized
      ↓
order_submitted
      ↓
completed
Enter fullscreen mode Exit fullscreen mode

A provider timeout or delayed webhook does not justify inventing a successful transition. The payment attempt can remain pending or ambiguous in the payment domain while the checkout stays at the last state supported by evidence.

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.
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

This prevents the payment provider call from becoming an opaque side effect.

Provider authorization is not order commitment

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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.

Idempotency is mandatory

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: AgentCommerceMandateAction;
  requestedAmount: number;
  currency: string;

  requestedAt: string;
};
Enter fullscreen mode Exit fullscreen mode

The platform should enforce idempotency at the payment-transition boundary, not only in the adapter.

Example:

First request:
complete_delegated_payment is submitted to the provider after checkout state, mandate scope, and payment authority pass.

Network response:
lost.

Retry with same idempotency key:
platform returns the existing payment attempt state instead of creating a second authorization.
Enter fullscreen mode Exit fullscreen mode

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.

Before calling the provider, the platform should persist a dispatch intent tied to the payment execution, provider idempotency key, current lease or fence, and canonical provider-command hash.

If the process loses the provider response, the outcome is unknown. Lease expiry does not make a retry safe. The execution should enter reconciliation and be resolved through provider lookup or a verified webhook before another dispatch can occur.

Ambiguous payment outcomes need explicit state

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.
Enter fullscreen mode Exit fullscreen mode

A delegated payment model needs states for these conditions.

type AgentCommercePaymentExecutionStateKey =
  | "CREATED"
  | "PAYMENT_AUTHORIZED"
  | "ORDER_SUBMITTED"
  | "COMPLETED"
  | "FAILED"
  | "BLOCKED"
  | "REQUIRES_RECONCILIATION";
Enter fullscreen mode Exit fullscreen mode

The platform should not commit an order unless the payment state satisfies the platform’s order rules.

For example:

Payment execution requires reconciliation.
Order commitment is blocked until the payment result is resolved.
Enter fullscreen mode Exit fullscreen mode

or:

Payment authorized.
Order may be committed if the platform allows authorization-before-capture.
Enter fullscreen mode Exit fullscreen mode

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.

If capture is confirmed but order finalization fails, recovery should resume from the existing payment execution and stable commercial idempotency identity. It should reuse an existing order result or complete order creation without dispatching payment again.

Protocol adapters should not interpret payment authority

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" };
}
Enter fullscreen mode Exit fullscreen mode

This ignores checkout state, cart snapshot, merchant binding, currency, expiry, revocation, confirmation, idempotency, and audit.

Better boundary:

async function paymentAdapter(req: ProtocolPaymentRequest) {
  const command = mapToPaymentCommand(req);

  const result = await paymentAuthority.evaluateAndExecute(command);

  return projectPaymentResult(result);
}
Enter fullscreen mode Exit fullscreen mode

The adapter translates. The authority and payment domains decide.

This keeps payment semantics inside the platform instead of scattering them across protocol integrations.

Generated messages cannot become payment authority

Agent-facing systems may generate buyer-facing messages such as:

I found the Travel Backpack for €129 and can buy it for you.
Enter fullscreen mode Exit fullscreen mode

or:

The total is under your €150 limit. Proceeding with payment.
Enter fullscreen mode Exit fullscreen mode

These messages are not authority.

A generated statement does not establish 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.
Enter fullscreen mode Exit fullscreen mode

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.

Evidence should attach to authority decisions

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
Enter fullscreen mode Exit fullscreen mode

For a blocked decision, evidence may include:

Expired mandate
Revoked authority
Cart snapshot mismatch
Amount exceeds limit
Currency mismatch
Merchant mismatch
Checkout state not valid for payment
Confirmation missing
Enter fullscreen mode Exit fullscreen mode

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;
  hash: string;
  hashAlgorithm: "sha256";
};
Enter fullscreen mode Exit fullscreen mode

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?
Enter fullscreen mode Exit fullscreen mode

This is necessary for debugging, support, reconciliation, agent behavior, and audit.

For state-mutating and payment-blocking decisions, those evidence references should be hash-pinned rather than merely named.

A decision that blocks or permits payment is exactly where an unverifiable evidence reference is most expensive.

Audit should record the mandate path

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
Enter fullscreen mode Exit fullscreen mode

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?
Enter fullscreen mode Exit fullscreen mode

Without this audit path, the platform may know that payment happened but not why it was allowed.

For delegated payment, that is not enough.

Operator remediation still matters

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
Enter fullscreen mode Exit fullscreen mode

The platform should route actionable blockers to operator tasks.

For the Travel Backpack:

Delegated payment blocked:
checkout state is not valid for payment

Checkout blockers:
inventory stale
return-policy coverage missing
Enter fullscreen mode Exit fullscreen mode

Operator task:

Resolve return-policy coverage for Travel Bags.

Impact:
Agents cannot prepare checkout or proceed to delegated payment for affected products.
Enter fullscreen mode Exit fullscreen mode

Payment authority should not hide upstream blockers. It should preserve the causal chain so the right team fixes the right domain.

Where this model can go wrong

Delegated payment modeling improves safety, but it introduces its own failure modes.

Treating token validity as authority

A valid token is not enough. The platform must evaluate mandate scope, checkout state, cart snapshot, amount, currency, merchant, expiry, revocation, and confirmation.

Treating checkout validation as payment authority

A valid checkout state does not mean an actor may request payment. Payment authority is a separate domain.

Treating provider authorization as order commitment

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.

Binding authority to a mutable cart

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.

Ignoring amount semantics

A limit such as €150 must define whether shipping, tax, discounts, currency conversion, partial capture, and retries are allowed.

Ignoring currency

Currency mismatch should block payment unless conversion is explicitly modeled and authorized.

Ignoring merchant scope

A mandate for one merchant should not be usable for another merchant or seller unless the scope explicitly allows it.

Making confirmation a UI-only concept

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.

Handling idempotency only in the adapter

Payment idempotency must be enforced at the payment-transition boundary. Adapter-local deduplication is not enough.

Treating ambiguous provider responses as failure or success too early

Timeouts and pending responses need explicit payment-attempt states. Order commitment should wait for a payment state that satisfies platform rules.

Hiding upstream blockers

If delegated payment fails because checkout state is not valid for payment, the platform should preserve the checkout blocker. Otherwise agents and operators may retry payment when the real issue is policy, inventory, or checkout state.

Practical tests for delegated payment

Delegated payment should be tested with scenario flows, with provider calls used only after checkout and authority boundaries are clear.

A useful delegated-payment test includes:

Checkout state
Cart snapshot
Mandate scope
Actor
Buyer
Merchant
Amount
Currency
Expiry
Revocation
Confirmation
Payment attempt state
Expected authority decision
Expected paymentDispatchAttempted value
Expected payment attempt transition
Expected decision envelope
Enter fullscreen mode Exit fullscreen mode

The Travel Backpack scenario is enough to catch the dangerous shortcut:

Price: €129, fresh
Inventory: stale
Return policy: missing
Payment artifact: present
Mandate limit: €150
Enter fullscreen mode Exit fullscreen mode

The expected result is not:

price < mandate limit, so pay
Enter fullscreen mode Exit fullscreen mode

The expected result is:

Delegated payment is blocked.
The checkout and decision basis preserve invalid_checkout_state, stale_inventory, and missing_return_policy.
The payment section reports `authorityResult: not_evaluated` with no payment blockers.
Payment dispatch is not attempted.
Enter fullscreen mode Exit fullscreen mode

That test should use the same decision meaning as feed, tool, checkout, and admin projections. It does not need to simulate an entire payment provider. In this blocked scenario, the provider should never be reached.

A broader scenario set should emphasize negative cases because delegated payment safety depends more on correct refusal than on the happy path.

For the Travel Backpack:

Scenario Expected result
Payment artifact present but checkout blocked Delegated payment blocked; payment authority not_evaluated; checkout and basis preserve invalid_checkout_state and the upstream commercial blockers
Checkout state is valid but no mandate exists Payment blocked with mandate_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_scope_violation
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 human_confirmation_required
Confirmation satisfied and all scope checks pass Payment may proceed to provider request
Provider response times out Payment attempt enters ambiguous or pending state
Active execution lease expires after an ambiguous provider call Execution requires reconciliation; payment is not redispatched
Verified provider lookup or webhook resolves the attempt Existing execution moves to the corresponding final 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 captured but order finalization fails Payment is not redispatched; order completion resumes from the existing execution
Payment authorized but order commit fails Order is not duplicated; recovery or reversal path is recorded

A simplified expectation type:

type DelegatedPaymentScenarioExpectation = {
  checkoutState: "requires_payment" | "blocked" | "expired";

  mandateStatus: AgentCommerceMandateStatus;

  expectedDecision:
    | "allowed"
    | "blocked"
    | "requires_confirmation"
    | "requires_revalidation";

  expectedBlockerCodes: string[];

  expectedAgentCommercePaymentExecutionStateKey?: AgentCommercePaymentExecutionStateKey;

  expectedDecisionRecord: boolean;
};
Enter fullscreen mode Exit fullscreen mode

The safety of delegated payment depends more on correct refusal than on the happy path.

A practical implementation path

A platform can implement delegated payment authority incrementally.

  1. Separate artifact parsing from authority decisions.
    Adapters may parse protocol artifacts. The delegated-authority owner decides what they mean.

  2. Define a mandate model.
    Include buyer, actor, merchant, cart snapshot, amount, currency, allowed actions, expiry, revocation, confirmation, and evidence.

  3. Bind mandates to checkout snapshots.
    Do not rely only on mutable cart IDs.

  4. Evaluate checkout before payment.
    Payment authority should not bypass checkout validation.

  5. Enforce amount, currency, and merchant scope.
    These should be explicit checks, not assumptions.

  6. Model confirmation as authority evidence.
    If confirmation is required, record it as a structured event tied to a specific scope.

  7. Add mandate lifecycle.
    Support pending confirmation, active, expired, revoked, used, and rejected states.

  8. Make payment execution idempotent.
    Retries should not create duplicate authorizations, captures, or orders.

  9. Model ambiguous payment outcomes.
    Do not treat timeouts or missing provider responses as simple success or failure.

  10. 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.

The tradeoff

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 show 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, trace, and explain.

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.

The key distinction

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?
Enter fullscreen mode Exit fullscreen mode

For the Travel Backpack, delegated payment remains blocked even if a payment artifact exists, because checkout state is not valid for payment. 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
Enter fullscreen mode Exit fullscreen mode

That structure prevents protocol artifacts, generated messages, or adapter shortcuts from becoming accidental payment authority.

Next in the series

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 generated product descriptions, policy summaries, comparisons, recommendations, and checkout explanations. It will show why they should remain derived claims with review status, source references, freshness, invalidation rules, and audit—not become automatic commercial truth.

About the author

Written by Dimitrios S. Sfyris, Founder & Software Architect at AspectSoft.

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 for updates on software platforms, commerce systems, AI tooling, and developer-focused products.

Top comments (2)

Collapse
 
mateo_ruiz_6992b1fce47843 profile image
Mateo Ruiz •

This highlights an important shift in agentic commerce. Payment tokens answer "can this payment be processed?" but not "should this payment be executed?" Once AI agents can act on a buyer's behalf, authority, checkout state, policy validation, and auditability become just as important as authentication. Building these decision boundaries early saves a lot of complexity when moving from demos to production systems.

Collapse
 
hayrullahkar profile image
Hayrullah Kar •

tying a mandate to a rigid CartSnapshot instead of a mutable cart id is pure gold. too many architectures treat a valid token as a blanket permission to charge whatever mutated state exists at checkout. splitting buyer authority, checkout validity, and provider auth is the only way to build safe agent pipelines. if inventory goes stale mid-flight, the mandate must trigger a revalidation event before hitting the provider api. super solid take.