Skip to main content
A payment link is a shareable URL carrying a challenge. x402 is the HTTP 402 response carrying the same challenge at the protocol edge. A person opens one. A machine retries the other. Both converge on a signed PINT JWT the verifier already knows how to authorise. The verifier cannot tell them apart. It does not need to.
01 / FLOW

Two triggers. One signature.

Requesting a payment and gating a resource are the same gesture in two envelopes. A URL a person clicks, or a 402 a client retries — either way, the recipient ends up signing the same PINT and presenting it to the same verifier. The shape differs at the edge; the signature is identical.
02 / RESPONSIBILITIES

Same parties. Different surfaces.

The division of labour is identical across both shapes. What changes is where the challenge originates and how the recipient encounters it. The roles stay fixed; only the envelope moves.
PartyPayment linkx402
PartnerGenerates the link carrying the intended PINT challenge.Issues the 402 response carrying the same challenge.
User-clientOpens the link, signs the challenge, presents the PINT JWT.Retries the request with the PINT JWT in the header.
VerifierValidates the JWT on redemption, or returns 402 if stale.Validates the JWT on retry and grants the protected resource.
03 / VERIFICATION

One credential, three checks.

Because both shapes terminate in a PINT JWT, the verifier does not branch by origin. It runs the same sequence either way. The envelope is forgotten at the moment of authorisation.

JWKS-backed signature

The verifier resolves the issuer’s published signing keys and verifies the JWT signature. If the key set is unreachable or the signature does not match, the request is refused. Trust starts with the key, not the transport.

Optional revocation check

Consults the issuer’s published state for a PINT revoked after issuance. A revoked PINT fails here even when the signature is valid. Revocation is the one place where timing matters.

Enhanced-tier signature

For spend scopes, the verifier additionally requires an Enhanced-tier PINT signature, anchored to the account holder’s verified identity. Read-only scopes skip this tier. Stronger authorisation rides on stronger proof of person.
A URL a person clicks, or a 402 a client retries. The signature underneath is the same. Two shapes, one credential.
04 / STATUS

Reference in progress.

The full Payment Links and x402 reference is shipping soon. Until then, the canonical quickstart for accepting a PINT at checkout — which is the settlement step in both flows — lives in the Verifier Guide. The settlement path is already stable; the surfaces around it are still landing.
05 / SEE ALSO

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 settlement flow, end to end.

Purchase Intents

The signed primitive underneath both surfaces.
06 / QUESTIONS

Questions.

A Purchase Intent is Sumvin’s signed scope object — who is asking, for what, under which tier of verification. The PINT JWT is that object serialised as a JWS-signed JWT, with the issuer’s keys published via JWKS. The verifier fetches the key set, checks the signature, and reads the scope. The JWT is the contract; the JWKS is the trust anchor.
The verifier is whoever authorises the action behind the challenge — a merchant accepting checkout, an API gating a resource, a platform validating a redemption. Sumvin issues and publishes the keys; the verifier can live anywhere, including entirely outside Sumvin’s infrastructure. Issuance is centralised; authorisation is not.