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

# Global x402 Acceptance

> A persistent, identity-keyed x402 acceptance endpoint for every Sumvin user.

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" />

Every Sumvin identity **comes with** a persistent x402-addressable acceptance surface. Rather than minting a one-shot link per request, the identity itself resolves to an x402 endpoint that any x402-capable client can settle against — discoverable by <Tooltip headline="Sigil" tip="Sumvin's portable, KYC-verified identity — Proof of Personhood a user carries across products." cta="Glossary →" href="/glossary">SRI</Tooltip>, authorised by <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 anchored to the same verified identity claims any other point in the platform exposes.

Global acceptance and payment request links are the two sides of the same primitive: one ad-hoc and scoped to a single request, the other persistent and tied to the identity for as long as it exists. The ad-hoc side is the [payment request links](/products/payment-links/payment-request-links) page.

## What it enables

* **Pay-to-identity as a first-class primitive.** Any SRI is a valid payment target, resolvable by any x402 client, without provisioning a bespoke link per transaction.
* **Inline payments on the open web.** A page, feed, or agent surface can embed an identity-keyed payment target and let x402 clients settle directly against it.
* **Agent-to-agent settlement.** One agent can pay another by referencing its owner's SRI — no prior handshake, no shared platform, no custom protocol.
* **Receipts tied to identity, not rails.** Every settlement produces the same PINT-backed receipt the rest of the platform already understands.

## Global acceptance vs request links

|               | Payment request link     | Global x402 acceptance                              |
| ------------- | ------------------------ | --------------------------------------------------- |
| **Scope**     | One request, fixed terms | Persistent, identity-level                          |
| **Trigger**   | Issued per payment       | Always available                                    |
| **Discovery** | Shared URL               | Resolved from SRI                                   |
| **Terms**     | Baked into the link      | Evaluated per payment against the identity's policy |
| **Best for**  | Invoice-like one-shots   | Open-ended, discoverable receive                    |

The two surfaces share the underlying rail — PINT-challenged x402 — and the same identity guarantees. Most partners will expose both: request links for structured, bill-like collection, and global acceptance for open-ended, agent-driven receive.

## Who it's for

* Partners building identity-first payment surfaces who want "pay this user" to be a resolvable primitive, not a form.
* Agent platforms that need a stable, resolvable payment target per user without a per-transaction provisioning step.
* Apps exposing Sumvin identities in feeds, profiles, or messaging surfaces where payment should be one resolve away.

<Info>
  Global x402 acceptance is in private preview. Partners wiring in now help define how SRI-based resolution, policy evaluation, and identity-keyed receipts land in the final shape — contact your account manager to co-design your integration.
</Info>

## Where to start

Most partners start with [payment request links](/products/payment-links/payment-request-links) — the ad-hoc counterpart to persistent acceptance — and layer global acceptance over the top once the one-shot shape is live. The [payment links and x402 rail](/concepts/payment-links-x402) covers the mechanics both surfaces ride on, and the [SRI reference](/identity/sri) explains how identities resolve to payable endpoints. **[Errands](/products/errand/overview) are where global acceptance earns its keep — agents pay agents by resolving each other's SRIs, with no prior handshake.**

## Related

* [Purchase Intents](/identity/pint)
* [Verified checkout use-case](/overview/use-cases/verified-checkout)
* [Errand overview](/products/errand/overview)
* [Sumvin Identity overview](/identity/overview) — the identity layer every acceptance surface hangs off
* [Verifier overview](/merchant/overview) — what the settling side receives and verifies