> ## 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 request links

> User-originated, identity-anchored payment requests that any x402-capable wallet or agent can settle.

Payment links are the acceptance rail in Atomic Money — how a user gets paid; the same rail an Errand settles against. See the [Atomic Money overview](/products/atomic-money/overview) for the full picture.

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

A payment request link is a shareable URL a Sumvin user issues to ask for a payment. The recipient — a person, a wallet, or an agent — resolves it against a Sumvin-verified <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">PINT</Tooltip> and settles over x402. The payer needs no Sumvin account. The requester needs no checkout surface. **Nothing about the payer has to change for the requester to get paid.**

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

## What the link carries.

Requesting money has historically been trapped inside closed loops — one app to the same app, one scheme to its own closed settlement. Five properties break that constraint, and the combination is unique to this platform.

```mermaid theme={null}
sequenceDiagram
  Requester->>Sumvin: create payment request link
  Sumvin-->>Requester: short URL + PINT scope
  Requester->>Payer: share link (any channel)
  Payer->>Sumvin: resolve URL
  Sumvin-->>Payer: x402 challenge + PINT manifest
  Payer->>Payer: sign EIP-712 (wallet or agent)
  Payer->>Sumvin: submit settlement
  Sumvin-->>Requester: PINT JWT receipt
  Sumvin-->>Payer: PINT JWT receipt
```

<CardGroup cols={3}>
  <Card title="Issued by the user" icon="user-round">
    Any Sumvin user issues the link themselves. No merchant onboarding. No checkout surface to operate. No acquirer in the middle. **The user is the counterparty.**
  </Card>

  <Card title="Identity-anchored on the requester" icon="badge-check">
    The link carries the requester's verified Sumvin identity. The payer sees who is asking, at what verification tier, under what scope. **Not a phone-number match. Not an opaque wallet address.**
  </Card>

  <Card title="Rail-agnostic settlement" icon="route">
    The link is an x402 resource. Any x402-capable wallet, agent, or browser can settle it. **No shared app, no shared network, no shared chain required.**
  </Card>
</CardGroup>

<CardGroup cols={2}>
  <Card title="Agent-fulfilable" icon="bot">
    Because x402 is HTTP-native and standardised, a counterparty's agent can read the request, apply its policy, and settle autonomously. **Request links become machine-addressable money.**
  </Card>

  <Card title="Cryptographic receipt" icon="file-check-2">
    Settlement produces a PINT JWT both sides can store and verify. Reconciliation is standardised end-to-end. **It is not reconstructed from opaque descriptors or statement exports.**
  </Card>
</CardGroup>

<div className="sv-pullquote">
  The requester is verified. The payer is free. The link carries both.
  <span className="sv-pullquote__close">Closed loops, opened.</span>
</div>

<div className="sv-section-eyebrow">02 / WHAT IT ENABLES</div>

## What it enables.

<CardGroup cols={2}>
  <Card title="Request money between people" icon="hand-coins">
    Issue a link against a verified identity. The payer sees who is asking and under what scope. **Identity-backed, not phone-number-matched.**
  </Card>

  <Card title="Invoice from any channel" icon="send">
    Send an invoice-style link from any app, any message, any thread. **No merchant account needed.**
  </Card>

  <Card title="Expose a payable endpoint to an agent" icon="plug-zap">
    Publish a resolvable URL a counterparty's agent can settle under its own policy. **A standardised, addressable payable.**
  </Card>

  <Card title="One-shot receives" icon="inbox">
    Deposits, split bills, freelance invoices, any single receive. **No closed-loop app. No full merchant stack.**
  </Card>
</CardGroup>

<div className="sv-section-eyebrow">03 / WHO IT'S FOR</div>

## Who it's for.

<CardGroup cols={3}>
  <Card title="Sumvin users and the apps that host them" icon="smartphone">
    Consumers and prosumers who need to be paid and want the transaction to carry a verified identity. **Paid as themselves, not as an address.**
  </Card>

  <Card title="Receive-money experiences built on Sumvin" icon="layers">
    Partner platforms ship identity-anchored request money without standing up merchant infrastructure. **Rails, not acquiring.**
  </Card>

  <Card title="A standardised, resolvable payment primitive" icon="bot">
    Agent builders settle against a structured endpoint under owner policy. **A payable that machines can read.**
  </Card>
</CardGroup>

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

## Shape the spec.

<Note>
  Payment request links are in private preview. Partners building on this rail today help shape the create-link and settle spec, and are the first to ship identity-anchored request money against it. **Scoping happens one integration at a time.**
</Note>

<CardGroup cols={1}>
  <Card title="Contact your account manager" icon="mail" href="mailto:partnerships@sumvin.com">
    We co-design the integration, agree the scope surface, and wire you in against the current spec.
  </Card>
</CardGroup>

<div className="sv-section-eyebrow">05 / START HERE</div>

## Where to start.

<Steps>
  <Step title="Create a payment link">
    Issue a shareable, identity-anchored payment request URL. Start with the [payment link quickstart](/guides/quickstarts/payment-link).
  </Step>

  <Step title="Accept a PINT at checkout">
    The settling side of the same primitive. Walk through [accept a PINT at checkout](/merchant/quickstarts/accept-pint-checkout).
  </Step>

  <Step title="Understand the rail">
    Read [payment links and x402](/concepts/payment-links-x402) for the conceptual model behind the primitive.
  </Step>

  <Step title="Layer on global acceptance">
    [Global x402 acceptance](/products/payment-links/global-x402-acceptance) is the persistent counterpart to ad-hoc links.
  </Step>
</Steps>

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

## Related reading.

<CardGroup cols={2}>
  <Card title="Verified checkout use-case" icon="shield-check" href="/overview/use-cases/verified-checkout">
    The authorising side of the primitive.
  </Card>

  <Card title="Errand overview" icon="bot" href="/products/errand/overview">
    How agents read and settle payable endpoints.
  </Card>

  <Card title="Purchase Intents (PINTs)" icon="file-text" href="/identity/pint">
    The standardised scope object inside the link.
  </Card>

  <Card title="Sumvin identity overview" icon="fingerprint" href="/identity/overview">
    The identity layer every payment surface hangs off.
  </Card>
</CardGroup>

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

## Questions.

<AccordionGroup>
  <Accordion title="What is x402?">
    [x402](https://www.x402.org/) is an HTTP-native payment standard: a server issues a `402 Payment Required` challenge, the client signs an [EIP-712](https://eips.ethereum.org/EIPS/eip-712) payment authorisation, and the server settles on-chain. Any x402-capable wallet, agent, or browser can complete the flow. Sumvin issues the PINT scope that rides inside the challenge, so the payer knows who is asking and under what terms before they sign. **The rail is the standard, not the app.**
  </Accordion>

  <Accordion title="Does the payer need a Sumvin account?">
    No. The payer only needs an x402-capable client — wallet, agent, or browser. The link resolves to a public x402 resource with a PINT-challenged scope; the payer signs with whatever key their client already holds. See [payment links and x402](/concepts/payment-links-x402) for the full conceptual model. **Identity-anchoring is on the requester side, not the payer side.**
  </Accordion>

  <Accordion title="Is Sumvin a neobank?">
    No. Sumvin is an [identity and payments platform](/overview/what-is-sumvin). Payment request links are a standardised payment primitive anchored on verified identity — not a deposit product, not a wallet custodian for the payer, and not a card programme. **A rail, not an account.**
  </Accordion>
</AccordionGroup>