x402 verification and payment state
Does an x402 v2 successful verify response establish that funds have moved?
The pinned x402 v2 specification defines verify as read-only. It checks an authorization without committing payment state. Settle is a separate operation whose effect depends on the selected scheme and payment flow. An isValid response therefore cannot substitute for the applicable settlement evidence.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Independent verification of payment, delivery or deployed controls
- The buyer network, actual transfer and delivered resource have not been observed.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
x402 payment flow and execution order
Must every x402 v2 payment settle after the protected resource executes?
The reviewed v2 specification defines authorization, upfront and escrow flows with different ordering around resource execution. A non-authorization flow must be declared in the offered requirements. Clients must not construct payments for an unrecognised flow, and servers must reject unsupported method-and-flow combinations.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Independent verification of payment, delivery or deployed controls
- Implementation conformance and the effect of a failed buyer request remain unverified.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
x402 pending settlement and retry decisions
Does x402 settlement_pending mean that no payment transaction was broadcast?
The reviewed EVM exact binding permits settlement_pending when a transaction was broadcast but confirmation could not be established. The response carries its transaction hash so the caller can reconcile the chain outcome before retrying. This state is different from proof that no transfer occurred.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Independent verification of payment, delivery or deployed controls
- No chain transaction or buyer retry implementation was inspected.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
x402 upfront charges and failed resource delivery
Does x402 exact upfront define an automatic refund when the resource handler fails?
The pinned exact scheme allows upfront settlement before resource execution. It explicitly notes that a handler failure can leave the client charged without delivery and that this scheme defines no refund for that situation. Any remedy is an arrangement made by the resource server.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Independent verification of payment, delivery or deployed controls
- Actual merchant recovery arrangements and transferred funds are not assessed.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
x402 metered ceilings and final charges
Does the x402 upto amount mean the same thing during verification and settlement?
For the reviewed upto scheme, verification-time amount is the authorised maximum and settlement-time amount is the actual charge. The actual amount cannot exceed the signed maximum and may be zero. The facilitator must verify the signature against the original authorised maximum rather than the later charge.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Independent verification of payment, delivery or deployed controls
- Usage measurement accuracy and the buyer actual charge are not independently established.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
x402 metered authorization reuse
Can an x402 upto authorization be charged again for its unused allowance?
The reviewed upto specification requires at most one settlement per authorization. Settlement consumes it regardless of the amount charged. Repeated settlements, recurring charges and open-ended allowances are outside this scheme; a lower first charge does not preserve the remainder as reusable authority.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Independent verification of payment, delivery or deployed controls
- Actual nonce enforcement and any separately negotiated subscription remain unverified.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
x402 retry identifiers and operation binding
Can an x402 payment identifier safely identify different paid operations across tenants?
The reviewed payment-identifier extension calls for binding an identifier to a normalized request fingerprint. Reuse with changed operation details should produce a conflict. It also recommends scoping keys by tenant, merchant, route or facilitator account where those boundaries exist, rather than using the identifier alone for authorization.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Independent verification of payment, delivery or deployed controls
- Cache persistence, key scope and deployed conflict handling have not been tested.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
x402 delegation changes after simulation
Can a successful x402 ERC-7710 simulation guarantee that the later transfer will execute?
The pinned EVM binding verifies ERC-7710 authority through simulation. Its security discussion identifies a race in which the client invalidates delegation before execution, leaving the facilitator paying gas for a failed transaction. The permission context depends on the particular delegation-manager implementation.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Independent verification of payment, delivery or deployed controls
- No delegation manager, live authority or network transaction has been validated.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
x402 Permit2 spender and payee checks
Is the facilitator the signed spender in x402 exact Permit2 authorization?
The reviewed EVM exact binding identifies the x402ExactPermit2Proxy as the signed spender, rather than the facilitator. Its witness binds the destination address. The setup separately requires token approval to Permit2, with ordinary or supported sponsored approval paths; these roles should not be collapsed into one recipient identity.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Independent verification of payment, delivery or deployed controls
- Contract deployments, approval state and buyer wallet behaviour are not independently tested.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
x402 Solana transfer identity and amount
Does x402 Solana exact require the matching transfer amount to equal the quoted amount exactly?
The pinned Solana exact binding permits a matching transfer greater than or equal to the required amount, including rounding-related overpayment. It nevertheless requires exactly one matching transfer across top-level and inner instructions, with the correct mint, destination and token program. Zero or multiple matching transfers must be rejected.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Independent verification of payment, delivery or deployed controls
- The wallet transaction and any actual overpayment are not observed.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
x402 Solana hidden-account verification
Can an x402 Solana sponsor sign before resolving the transaction address lookup tables?
The reviewed binding requires address lookup tables to be resolved before fee-payer isolation checks, making the reachable accounts visible. If the sponsor cannot resolve them, including a transient resolution failure, it must reject rather than verify an incomplete account set. The rule applies before signing.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Independent verification of payment, delivery or deployed controls
- Actual table contents and signing controls have not been inspected.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
x402 smart-wallet execution evidence
Can a successful smart-wallet simulation alone establish x402 Solana settlement success?
The pinned Solana binding requires post-confirmation transfer verification for its smart-wallet path. The primary check inspects confirmed inner instructions; a documented fallback checks destination balance change when those instructions are unavailable. Simulation establishes expected behaviour, while settlement success must reflect actual chain effects.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Independent verification of payment, delivery or deployed controls
- No buyer transaction, RPC data or attribution of a balance change has been independently verified.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
x402 Solana transfer replay and duplicate access
Does Solana transaction deduplication alone prevent repeated x402 resource access?
The reviewed binding describes a settlement race in which repeated submissions can receive successful responses although the chain executes the transfer once. It recommends tracking in-flight payloads to reject duplicate settlements. Chain-level transfer deduplication and application-level resource access are separate controls.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Independent verification of payment, delivery or deployed controls
- No multi-instance deployment or deduplication storage was tested.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
x402 batched commitment and later payment
Does a successful x402 batch-settlement response prove that value has already transferred?
The pinned batch-settlement scheme accepts and stores a cryptographic commitment during the request; its network binding redeems value later. A successful response must include a non-empty commitment identifier. That identifier is not necessarily a chain transaction hash and does not itself establish completed redemption.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Independent verification of payment, delivery or deployed controls
- Commitment storage, redeemability and actual receipt of funds remain unobserved.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
x402 batch backing and collection risk
Are all x402 batch-settlement commitments backed by the client on-chain funds?
The reviewed scheme permits capital-backed and credit-backed commitments. In the latter model, a trusted intermediary associates identity with a billing account and settles later. Each network binding must specify its trust model, redemption process and seller guarantee; the shared scheme name does not make those protections identical.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Independent verification of payment, delivery or deployed controls
- Intermediary creditworthiness, enforceability and recoverability have not been assessed.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
x402 signed offers and unsigned selection indices
Can an x402 signed offer be bound to checkout terms using acceptIndex alone?
The reviewed offer extension describes acceptIndex as an unsigned convenience field. Clients should check its range and compare the selected payment requirements with the signed fields. The signature-covered terms, including network, asset, payee and amount, are the binding evidence; the index itself is not authoritative.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Independent verification of payment, delivery or deployed controls
- Actual server keys, offers and client matching behaviour have not been tested.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
x402 receipt keys and historical authority
Does a valid x402 receipt signature prove that its key was authorised for the service when issued?
The reviewed extension distinguishes signature validity from authority to sign for the resource URL. Historical verification should evaluate authority at receipt issuance. Removing a key from a current authorization source does not by itself establish that it was unauthorised earlier; dated authority evidence is therefore relevant.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Independent verification of payment, delivery or deployed controls
- Actual key ownership, authority and receipt truth have not been independently checked.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
x402 receipt content and independent reconciliation
Does every x402 signed receipt contain a transaction reference and payment amount?
The pinned receipt format deliberately permits omission of the transaction reference for privacy. Its canonical fields identify the resource, payer, network and issuance time, without requiring a payment amount. A signature authenticates the server statement; independent financial reconciliation may require additional transaction evidence.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Independent verification of payment, delivery or deployed controls
- Actual payment and delivery are not independently observed by this documentation review.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
x402 MCP settlement failure and prior execution
Does an x402 MCP payment error prove that the tool did not execute?
The reviewed MCP transport uses isError tool results for payment requirements and failures. It specifically covers settlement failing after tool execution and says the tool content should then be withheld. An error result therefore does not establish absence of a prior tool effect; the failure phase matters.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Independent verification of payment, delivery or deployed controls
- No actual tool effects or server retry protections have been inspected.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
x402 A2A task and payment-state evidence
Does x402 A2A payment-submitted or payment-verified establish completed payment?
The pinned A2A transport distinguishes submitted, verified and completed payment statuses. Payment payloads carry task correlation, and settlement results appear as receipts in task-status metadata. The submitted or verified labels are earlier states; they must not be treated as the completed settlement result.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Independent verification of payment, delivery or deployed controls
- Actual task execution, payment and delivered artifact are unobserved.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Open Payments grants for unspecified future recipients
Does an Open Payments outgoing grant always identify the recipient before consent is obtained?
The reviewed future-payments guide supports obtaining sender-side authority before the recipient is known. Its example authorises a bounded monthly amount for future destinations, as used by Web Monetization. Possession of that grant does not establish that a particular later merchant was individually identified during the initial consent.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Independent verification of payment, delivery or deployed controls
- Buyer consent details, selected recipient and account configuration remain unobserved.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Open Payments interval ceilings and unused amounts
Does unused Open Payments recurring-grant allowance roll into the next interval?
The pinned future-payments guide describes an amount that resets for each configured interval, without carrying forward the unused portion. Its example also bounds the number of repetitions and the start time. A monthly allowance is not a cumulative balance that grows when earlier periods are underspent.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Independent verification of payment, delivery or deployed controls
- The actual grant, remaining amount and provider enforcement are not inspected.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Open Payments spend reporting scope
Does Open Payments spent-amount retrieval return the lifetime total for a recurring grant?
The reviewed API guide identifies the current grant through the supplied access token and returns its debit and receive amounts. For a recurring grant, the reported amounts cover the current interval only. A lifetime spend history cannot be inferred from that one response.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Independent verification of payment, delivery or deployed controls
- Historical payments and completeness of retained buyer records remain unverified.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Open Payments completion and received amounts
Does marking an Open Payments incoming resource complete prove that a target amount was paid?
The reviewed completion API tells the recipient account servicing entity that no further payments will be sent toward an unexpired incoming resource. The resource model also permits sessions without an incomingAmount. Completion therefore needs to be reconciled with received-amount evidence rather than interpreted as proof of an independently specified purchase total.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Independent verification of payment, delivery or deployed controls
- Actual received funds and satisfaction of the buyer invoice are not assessed.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Open Payments quote validity and replacement
Can an Open Payments recurring payment keep using the original quote after it expires?
The reviewed guide states that quote responses include expiresAt and the outgoing payment should be created before that time. If creation fails because the quote expired, a new quote is required. A reusable grant does not extend the lifetime of the separately quoted payment terms.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Independent verification of payment, delivery or deployed controls
- The latest quoted price and adequacy of buyer approval remain unobserved.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Open Payments sender cost and recipient amount
Does an Open Payments fixed-send quote guarantee the recipient receives that same amount?
The reviewed resource model distinguishes fixed-send quotes, which specify the amount debited from the sender, from fixed-receive quotes, which specify the amount received. A quote accounts for applicable costs and is time-limited. The debit and receipt objectives are different and should be preserved separately in reconciliation.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Independent verification of payment, delivery or deployed controls
- Actual conversion, fees and received value have not been independently reconciled.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Open Payments recurring authority and payment initiation
Does obtaining an Open Payments recurring grant automatically initiate every later payment?
The reviewed recurring-payment guide requires the application to create a new incoming payment, quote and outgoing payment at each later interval. Existing grants may remain usable, but they do not replace those resource requests. Authority to make periodic payments is separate from scheduling and successfully initiating them.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Independent verification of payment, delivery or deployed controls
- Actual scheduling, resource creation and financial outcomes are not observed.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Open Payments outgoing instructions and settlement
Does creating an Open Payments outgoing resource prove that inter-provider settlement completed?
The reviewed resource model says an outgoing resource can represent a payment that will be, is being or was sent. It is an instruction to the sender account servicing entity. Open Payments supplies payment instructions; settlement between the account servicing entities uses a separate shared rail.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Independent verification of payment, delivery or deployed controls
- No inter-provider settlement or actual recipient credit is verified.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Open Payments incoming amount and payment allocation
Does Open Payments incomingAmount require exactly one payment of that amount?
The pinned resource model describes incomingAmount as the maximum to pay into the recipient account. One or more payments may use the incoming resource details, but their combined amounts cannot exceed that maximum. The field is an aggregate ceiling, not proof of one exact transfer or complete commercial payment.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Independent verification of payment, delivery or deployed controls
- Actual incoming payments and allocation completeness remain unobserved.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review