PurchaseIntent, delivered on the wire as a PINT. x402 is the HTTP 402 response that surfaces the same mandate at the protocol edge. A person opens the URL in a browser; a machine retries it with a PAYMENT-SIGNATURE envelope. Both converge on the same x402 settlement: the signed payload is dispatched to the facilitator, which verifies and settles it on-chain. The settlement path cannot tell the two audiences apart. It does not need to.
01 / FLOW
Two audiences. One settlement.
A payment request reaches a person and a machine through two different envelopes, but both end at the same on-chain settlement. A URL a person opens, or a402 a machine retries — either way, the signed Stamped Mandate is dispatched to the facilitator, which verifies and settles it. The shape differs at the edge; the settlement is identical.
02 / RESPONSIBILITIES
Same parties. Different surfaces.
The division of labour is identical across both shapes. What changes is where the mandate originates and how the payer encounters it. The machine path is where an settling an retries a402 with a PAYMENT-SIGNATURE envelope. The roles stay fixed; only the envelope moves.
| Party | Payment link | x402 |
|---|---|---|
| Partner | Generates the link carrying the intended PINT mandate. | Surfaces the same mandate behind a 402 response. |
| Payer | Opens the link in a browser and pays. | Retries the request with a PAYMENT-SIGNATURE envelope. |
| Settlement endpoint | Dispatches the signed payload to the facilitator and returns the X402SettlementResponse. | Dispatches the same payload to the facilitator and returns the X402SettlementResponse. |
03 / VERIFICATION
One mandate, three checks.
Whether the request arrived from a browser or a machine retry, the settlement endpoint at/pay/{slug} runs the same boundary checks before it hands the signed payload to the facilitator. The audience is forgotten at the moment of settlement.
Envelope validation
The endpoint confirms
x402Version is 2, scheme is exact, and network is one of the link’s accepted chains. A malformed or unsupported envelope is refused before any settlement attempt. Settlement starts with a well-formed mandate.Settle-once guard
An already-settled link returns
409 (PAYMENT_LINK_ALREADY_SETTLED). A retry against a link that has already paid receives an explicit refusal, not a second charge. One link, one settlement.Facilitator verify and settle
The signed payload is verified and settled on-chain by the configured facilitator, gated by the owner’s fail-closed feature flag. If the flag is off, settlement does not proceed. The on-chain move is the facilitator’s, behind the owner’s switch.
A URL a person opens, or a
402 a machine retries. The on-chain settlement underneath is the same.
Two shapes, one settlement.04 / SETTLEMENT
Settle a payment link.
The canonical walkthrough of the x402 settlement handshake — generating a link, the
402 challenge, and the PAYMENT-SIGNATURE retry that the facilitator verifies and settles on-chain — lives in the Payment link quickstart. That is the settlement path for both the browser and machine audiences.Note that this is distinct from the PINT resource-gating flow, where a verifier authorises a JWT against the published JWKS to grant access to a protected resource — a separate rail, not payment-link settlement.05 / SEE ALSO
Related.
Payment request links
User-originated, identity-anchored requests any x402-capable wallet can settle.
Global x402 acceptance
The persistent, resolvable receive surface for machines.
Accept a PINT at checkout
The verifier-side resource-gating flow — JWT-over-JWKS authorisation, a separate rail from payment-link settlement.
Purchase Intents
The signed primitive underneath both surfaces.
06 / QUESTIONS
Questions.
What is a PINT, and how does it settle here?
What is a PINT, and how does it settle here?
A Purchase Intent is Sumvin’s signed scope object — who is asking, for what, under which tier of verification. On a payment link it rides as a signed EIP-712
PurchaseIntent. The settlement endpoint validates the x402 envelope and hands the signed payload to the facilitator, which verifies and settles it on-chain — it does not authorise a JWT against a key set. The signed mandate is the contract; the facilitator is the settler.Is this the same as the JWT-over-JWKS verifier flow?
Is this the same as the JWT-over-JWKS verifier flow?
No. PINTs are also exchanged for JWS-signed JWTs — with issuer keys published via JWKS — to gate access to a protected resource. That is a separate rail: a verifier fetches the key set, checks the signature, and reads the scope. Payment-link settlement is on-chain via the facilitator, not JWKS-based authorisation. See the PINT resource-gating flow for the JWT rail.
Can the same link be settled twice?
Can the same link be settled twice?
No. A link is single-use by default — once settled, a retry against the same link returns
409 (PAYMENT_LINK_ALREADY_SETTLED). Persistent receive surfaces live on global x402 acceptance, which issues a new PINT per attempt. One link, one settlement.