> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sumvin.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Payment Links and x402

> Shareable PINT-backed URLs and the HTTP 402 flow for machine-to-machine settlement.

Payment links and x402 are two surfaces of <Tooltip headline="Atomic Money" tip="Sumvin's payments umbrella: ramps, card issuing, x402, and payment links." cta="Glossary →" href="/glossary">Atomic Money</Tooltip>, Sumvin's payments umbrella. Both move value by carrying a <Tooltip headline="Stamped Mandate" tip="A signed authorisation a user grants for specific scoped actions — delivered on the wire as a PINT." cta="Glossary →" href="/glossary">Stamped Mandate</Tooltip> to a verifier.

<Snippet file="product-term-disambiguation.mdx" />

A payment link is a shareable URL carrying a Stamped Mandate — a signed EIP-712 `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.**

<div className="sv-section-eyebrow">01 / FLOW</div>

## 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 a `402` 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.**

```mermaid theme={null}
flowchart TD
  A["Partner generates link<br/>with PINT mandate"]
  B["Recipient opens URL<br/>in a browser"]
  C["Machine retries<br/>with PAYMENT-SIGNATURE"]
  D["Endpoint responds<br/>402 + payment requirements"]
  E(("Facilitator verifies<br/>and settles on-chain"))
  F["X402SettlementResponse<br/>returned"]

  A --> B
  A --> D
  D --> C
  B --> E
  C --> E
  E --> F
```

<div className="sv-section-eyebrow">02 / RESPONSIBILITIES</div>

## 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 <Tooltip headline="Envoy" tip="The money agent that acts on a user's behalf." cta="Glossary →" href="/glossary">Envoy</Tooltip> settling an <Tooltip headline="Errand" tip="An agent's scope-bound tasking run: Intent → Authorization → Vigilance." cta="Glossary →" href="/glossary">Errand</Tooltip> retries a `402` 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`. |

<div className="sv-section-eyebrow">03 / VERIFICATION</div>

## 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.**

<CardGroup cols={3}>
  <Card title="Envelope validation" icon="shield-check">
    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.**
  </Card>

  <Card title="Settle-once guard" icon="rotate-ccw">
    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.**
  </Card>

  <Card title="Facilitator verify and settle" icon="file-pen">
    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.**
  </Card>
</CardGroup>

<div className="sv-pullquote">
  A URL a person opens, or a `402` a machine retries. The on-chain settlement underneath is the same.
  <span className="sv-pullquote__close">Two shapes, one settlement.</span>
</div>

<div className="sv-section-eyebrow">04 / SETTLEMENT</div>

## Settle a payment link.

<Note>
  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](/guides/quickstarts/payment-link). That is the settlement path for both the browser and machine audiences.

  Note that this is distinct from the [PINT resource-gating flow](/merchant/quickstarts/accept-pint-checkout), where a verifier authorises a JWT against the published JWKS to grant access to a protected resource — a separate rail, not payment-link settlement.
</Note>

<div className="sv-section-eyebrow">05 / SEE ALSO</div>

## Related.

<CardGroup cols={2}>
  <Card title="Payment request links" icon="link-2" href="/products/payment-links/payment-request-links">
    User-originated, identity-anchored requests any x402-capable wallet can settle.
  </Card>

  <Card title="Global x402 acceptance" icon="globe" href="/products/payment-links/global-x402-acceptance">
    The persistent, resolvable receive surface for machines.
  </Card>

  <Card title="Accept a PINT at checkout" icon="shopping-cart" href="/merchant/quickstarts/accept-pint-checkout">
    The verifier-side resource-gating flow — JWT-over-JWKS authorisation, a separate rail from payment-link settlement.
  </Card>

  <Card title="Purchase Intents" icon="file-text" href="/identity/pint">
    The signed primitive underneath both surfaces.
  </Card>
</CardGroup>

<div className="sv-section-eyebrow">06 / QUESTIONS</div>

## Questions.

<AccordionGroup>
  <Accordion title="What is a PINT, and how does it settle here?">
    A [Purchase Intent](/identity/pint) 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.**
  </Accordion>

  <Accordion title="Is this the same as the JWT-over-JWKS verifier flow?">
    No. PINTs are also exchanged for [JWS-signed JWTs](https://datatracker.ietf.org/doc/html/rfc7519) — with issuer keys published via [JWKS](https://datatracker.ietf.org/doc/html/rfc7517) — 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](/merchant/quickstarts/accept-pint-checkout) for the JWT rail.
  </Accordion>

  <Accordion title="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](/products/payment-links/global-x402-acceptance), which issues a new PINT per attempt. **One link, one settlement.**
  </Accordion>
</AccordionGroup>