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

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.

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

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

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

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.

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

A safe causal chain is:

delegate_payment blocked
      ↓
checkout is not valid
      ↓
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 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.
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 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[];
};
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 prove that a payment request is still inside the buyer’s delegated authority.

The authority decision should be evaluated at execution time

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

For the Travel Backpack:

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

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.

Checkout validity comes first

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
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 is valid 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 proof 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 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;
};
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: PaymentAction[];

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

  status: "active" | "expired" | "revoked";
};
Enter fullscreen mode Exit fullscreen mode

The existence of a protocol request does not prove 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 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.

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:
    | "pending_confirmation"
    | "active"
    | "expired"
    | "revoked"
    | "used"
    | "rejected";

  createdAt: string;
  expiresAt: string;

  revokedAt?: string;
  revokedReason?: string;

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

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

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

The authority service should own mandate lifecycle.

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 payment path might look like this:

checkout_prepared
      ↓
payment_authority_required
      ↓
payment_authority_validated
      ↓
payment_pending
      ↓
payment_authorized
      ↓
order_committed
Enter fullscreen mode Exit fullscreen mode

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: PaymentAction;
  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:
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.
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.

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 PaymentAttemptState =
  | "not_started"
  | "authority_validated"
  | "pending_provider_response"
  | "requires_buyer_action"
  | "authorized"
  | "captured"
  | "failed"
  | "ambiguous"
  | "cancelled";
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 attempt is ambiguous.
Order commitment is blocked until 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.

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 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.
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 not valid
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;
};
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.

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 is not valid

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 validity as payment authority

A valid checkout does not mean an actor may request 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 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.

Testing delegated payment

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

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

These tests should emphasize negative cases.

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 authority service 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 validity.

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

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

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.

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 (0)