Agentic Payment Failure Envelope: Runtime, Retry, Limits and Killability

Executive summary

A decision receipt can explain why one candidate payment was permitted, escalated or denied. It does not, by itself, describe the behavior of the system after that decision.

A runtime review needs at least five separations:

1. a value cap is not a call-rate cap;
2. a per-operation maximum is not automatically an aggregate budget;
3. a timeout is not evidence that nothing happened;
4. a cancellation or revocation status is not evidence that every downstream effect stopped; and
5. stopping new work is not the same thing as reconciling old work.

Public specifications document useful pieces. AP2 v0.2 defines recurrence, payee, amount, budget and execution-date constraints and requires its role-specific validation/processing to occur in deterministic code. x402 v2 defines payment requirements but leaves client-side budget management outside core scope. AWS and Stripe show that retry/rate and idempotency controls need exact scope; RFC 7009 and MCP Tasks show why revocation/cancellation needs separate propagation and residual-effects evidence.

The reviewer job is not to ask, “Does the system have a kill switch?” It is to ask: which future action can be stopped, at what layer, based on what current state, and what remains unknown afterwards?

A Decision Receipt is a start, not the whole runtime story

The earlier Treasury Desk article Agent Payments Need a Decision Receipt focused on the point at which one proposed payment is allowed. It separated identity, mandate, limits, policy version, exact proposal, decision and later payment state.

That remains useful. But it is a snapshot.

A running system introduces time: tools can be called again, transports can retry, a provider can accept a request before the client sees the result, workers can race on the same budget, routes can change during fallback, and authority can change after a check but before dispatch.

So a runtime reviewer needs a second artifact: a record of what can still happen after the decision, and which state is authoritative at each boundary.

Separate value, rate, concurrency and time

“Limit” is too broad a word for runtime control.

A per-operation value ceiling answers “how large can this one operation be?” An aggregate budget answers “how much can this authority spend across a defined period or run?” A call-rate cap answers “how often can calls be attempted?” A concurrency cap answers “how many can be in flight together?” A retry budget answers “how many transport attempts can be generated for one logical operation?” A deadline answers “how long can the sequence stay alive?”

AP2 v0.2 makes some of those distinctions concrete. Its Payment Mandate defines recurrence, allowed payees, amount ranges, a budget used with recurrence, and an execution-date window. The current-main text retrieved 14 September 2026 says budget evaluation tracks the requested amount plus amounts from previously closed Payment Mandates and says approved amounts are added to the accumulated total for future evaluation.

That is a documented budget constraint and evaluation rule. It is not, on the evidence reviewed here, a documented atomic reservation mechanism. The text reviewed for this article did not establish how concurrent workers reserve budget, where the authoritative counter lives, or how restart/failover recovers unresolved reservations. Those remain reviewer questions, not a claim that AP2 implementations lack them.

A local model shows why the question matters. If two workers each read “100 remaining” and each approves a 70-unit request before either update becomes visible, local checks alone permit a 140-unit scenario. A serialized shared-reservation model blocks the second request—but that is an author-modelled comparison, not evidence that a named provider implements it.

x402 v2 provides a different boundary. It explicitly places client-side budget management outside the core specification. The reviewed EVM upto scheme lets a client authorize a maximum for one request and requires settlement at or below that maximum. That is useful per-request enforcement. It is not an aggregate run budget.

Rate limits need the same discipline. AWS’s current retry documentation describes a client-side rate limiter in adaptive mode that operates per SDK client instance. The page also says the described 2026 retry behavior currently requires opting in with AWS_NEW_RETRIES_2026=true until it becomes the default. A limit on one client object is not automatically a limit across workers, hosts, credentials or providers.

Retry amplification: one payment, many attempts

Retries are where simple arithmetic turns into operating risk.

AWS reliability guidance warns that retries at multiple application layers can compound and that retrying non-idempotent calls can create duplicate effects. On the current opt-in 2026 SDK behavior page, max_attempts=3 means one initial request plus up to two retries. If an outer orchestration layer repeats the operation twice, a synthetic model can reach six transport attempts while still representing one logical payment.

That does not mean six payments occurred. It means the reviewer has to preserve the mapping: logical payment ID → attempts → provider references → observed outcomes.

The distinction matters most after ambiguity. x402 v2 defines settlement_pending for a transaction that was broadcast when confirmation could not be established. The transaction may still confirm, and the response carries transaction/network information so the caller can reconcile before deciding whether to retry.

The broader reviewer rule is: unknown is a state. Do not translate an ambiguous timeout to “failed” or “safe to repeat.”

Idempotency also needs exact scope. Stripe’s API v1 and API v2 documentation shows materially different replay rules across versions, methods, account/sandbox scope and time windows. That is enough to reject the shortcut “we use an idempotency key, therefore the payment is exactly-once.” A key can help within a defined provider/API contract. It does not, by itself, prove end-to-end exactly-once across a changed route, provider or rail.

Killability is a timeline, not a button

The cleanest stop record is a timeline:

last confirmed dispatch → stop requested → stop received → locally enforced → propagated → remaining work inventoried → outcomes reconciled.

Each arrow needs evidence and scope.

Practical artifact: Download the Stop Timeline →

RFC 7009 is useful here as a comparator, not a payment-cancellation standard. It says OAuth token invalidation is intended to take place immediately but acknowledges practical propagation delay. If the revocation endpoint returns HTTP 503, the client must assume the token still exists.

The exact MCP Tasks 2025-11-25 design is even more explicit about status versus execution. On a valid cancellation, the receiver should attempt to stop the task and must transition it to cancelled; the specification also says that status stays cancelled even if execution continues to completion or failure. The cancellation request/status is evidence of a control-plane event. It is not proof that work or downstream effects stopped.

For payment systems, separate new-task admission, queued/delayed jobs, the worker, child agents, signer/credential authority, provider sessions and the rail. A useful local stop can coexist with unresolved already-dispatched work.

Full stop matrix: Download the Stop / Revoke / Residual-Effects Matrix →

The compact Failure Envelope

A reviewer file does not need to model the whole architecture. It needs to make the control boundary inspectable.

The complete template should also identify the authoritative state source, evidence/test pointer, failure behavior and review trigger for every row.

Reviewer template: Download the Agentic Payment Failure Envelope — Public Reviewer Template →

Negative walkthrough: the weak envelope

Take a modelled run with a 100-unit aggregate budget and two workers. Both workers read 100 remaining. Each proposes a 70-unit operation. With only local check-then-update logic, both pass. The potential total becomes 140.

Now add an ambiguous timeout. The outer orchestrator repeats a call whose SDK already made three total attempts. The system reports “failed” without preserving attempt references. A stop request blocks new admissions, but one operation was already dispatched.

This is not proof of a real vulnerability. It is a reviewer test that reveals which evidence is missing: durable reservation semantics, logical-payment mapping, current authority at dispatch, and an inventory of unresolved external work.

The correct output can be Bound not established.

Positive bounded walkthrough

Public sources also show that useful bounds can be documented.

AP2 v0.2 supplies explicit payee, amount, recurrence, budget and execution-date constraints. In a separate source class, AWS reports that the described t54 integration uses session-scoped spending limits, role separation and an inline trust check before payment. That is a reported implementation, not independent security or conformance assurance.

In a third source class—a local deterministic fixture built for this article—a 50-unit per-operation cap, a two-calls-per-minute fixture limit, a single allowed payee and an active local stop boundary produced the expected reject decisions for out-of-envelope inputs. The fixture is a model only; it did not call a provider, sign anything, or test a payment rail.

Keeping those labels separate—specification, reported implementation, local model—is the point.

Reviewer questions before calling an agent payment “controllable”

• Which limit is per operation, and which is aggregate?
• Which unit/currency, entity, agent, tenant and time window does each limit cover?
• Is budget state merely counted after completion, or reserved before dispatch?
• What is shared across workers, credentials, providers and failover paths?
• How many attempts can one logical payment produce across all retry layers?
• What does a timeout mean for side effects at each provider/rail?
• What exactly does the idempotency key bind, and for how long?
• Is authority checked again immediately before signing/dispatch?
• Does a counterparty, endpoint, network or provider change require fresh approval?
• What does stop block: admissions, queues, workers, children, signing, provider calls, or rail settlement?
• Which already-dispatched objects remain unknown after stop?
• Who owns the exception and what independent evidence closes it?
• What state must be reloaded before restart or resume?

What this does not prove

This framework does not establish a universal maximum-loss bound, security assurance, compliance, legal authority, provider suitability or production readiness, and it does not prescribe one architecture.

It also does not imply that Treasury Desk executes payments, enforces runtime limits or provides a kill switch. Treasury Desk remains a read-only analytics, monitoring, reporting and decision-support product under its stated product boundary.

The underlying protocols also have different scopes and maturity states. EMVCo’s September 2026 material is a v1.0 draft framework for public review that discusses recurring purchases, cumulative budgets, shared intent state and post-transaction activities. It should not be presented as a final deployed standard. The 2025-11-25 MCP Tasks example is an experimental legacy version; current extension work says the legacy surface was a stopgap and is not wire-compatible with the extension.

Method and public sources

This review used current-main AP2 v0.2 and Payment Mandate documentation as retrieved 14 September 2026; x402 v2 core and EVM upto scheme; current AWS SDK retry documentation and Reliability Pillar retry guidance; Stripe v1/v2 idempotency documentation; RFC 7009; MCP Tasks 2025-11-25 plus the Tasks extension migration note; EMVCo’s September 2026 draft-framework announcement/resource page; and bounded implementation/design examples from AWS/t54 and FNA.

If you review agentic payment systems, I would value criticism of the method: which stop boundary or residual state is missing from the Failure Envelope? A public or synthetic counterexample is enough; please do not send private incident logs, credentials or transaction data.