Why is a payment awaiting approval, and how do I resume it?
Understand why an Agent payment needs a one-time administrator decision and safely resume the original Intent after approval.
awaiting_approval means the payment is eligible for a human decision but is not authorized yet. Save the returned Intent ID, let an organization administrator approve or reject the locked payment details, and after approval resume that same Intent with resumeIntentId.
Do not create a replacement Intent while approval is pending.
Why approval was required
A new Payment Agent starts conservatively: its automatic-payment threshold is zero, so every payment requires approval until an operator creates and activates an explicit policy version.
After that, the active policy produces one of three outcomes:
| Policy result | Payment outcome |
|---|---|
| Origin and recipient are allowed, and the amount is at or below the automatic threshold and all other limits | Automatically approved |
| Unknown origin, unknown recipient, or amount above the automatic threshold but within the per-payment limit | Awaits one-time approval |
| Amount above a hard policy or platform limit, unsupported payment details, exhausted budget, or failed risk gate | Rejected; approval cannot override it |
An approval of an unknown origin or recipient applies only to this Intent. It does not add that value to the policy allowlist, so a later purchase from the same unknown target can require approval again.
What the administrator approves
The approval locks a snapshot of the organization, environment, Agent, wallet, method, origin, recipient, network, asset contract, maximum amount, x402 requirement, policy version, and expiry time.
An administrator can approve or reject that snapshot but cannot edit the recipient, asset, network, or amount and then approve the modified payment. Management API Keys may read the approval queue, but the decision itself requires a short-lived session for an administrator in the current organization. Prefer the Agent Payments approvals page.
Safe resume flow
Keep the result from the first request:
const result = await agent.x402Fetch(resourceUrl, {
idempotencyKey: 'research-task-284:market-report:v1',
})
if (result.status === 'awaiting_approval') {
await savePendingPayment({
intentId: result.intentId,
approvalId: result.approvalId,
approvalExpiresAt: result.approvalExpiresAt,
})
}Wait until the approval is actually approved, then load the saved Intent ID and resume it:
const pending = await loadPendingPayment()
const resumed = await agent.x402Fetch(resourceUrl, {
resumeIntentId: pending.intentId,
})Resuming does not reuse the old remote 402 response. The SDK requests the resource again and compares the refreshed payment requirement with the approved Intent before asking for an execution grant.
If the x402 requirement changed
The old approval cannot authorize a materially different payment:
- a different origin, recipient, network, or asset invalidates the approval;
- an amount above the approved maximum invalidates the approval; and
- an unchanged or lower amount may continue only when every other locked field still matches.
This protects against a seller changing the charge between the human decision and signing. Do not bypass a mismatch by calling the signer directly or by changing the Intent payload.
If approval expires or is rejected
An expired or rejected approval cannot be resumed. StableOps releases its uncommitted budget reservation. If the business still wants to attempt the purchase, treat it as a new, deliberate purchase after checking the current resource quote and policy; do not try to revive the terminal Intent.
Approval is valid for 30 minutes by default. Once an execution grant has already been issued, the grant's own short validity and nonce state determine what happens next; approval expiry does not cancel a possibly submitted payment.
Related
How is this guide?
Last updated
Does the Agent or StableOps get access to my wallet key?
Understand where payment keys and credentials run, what the signer can authorize, and why the Agent runtime never needs unrestricted wallet access.
What should I do when settlement is unknown?
Reconcile the original Agent Payment Intent after a paid request times out or returns unreliable settlement evidence without risking a duplicate payment.