Skip to main content
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 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.
01 / DIFFERENCE
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.

Issued by the user

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.

Identity-anchored on the requester

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.

Rail-agnostic settlement

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.

Agent-fulfilable

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.

Cryptographic receipt

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.
The requester is verified. The payer is free. The link carries both. Closed loops, opened.
02 / WHAT IT ENABLES

​
What it enables.

Request money between people

Issue a link against a verified identity. The payer sees who is asking and under what scope. Identity-backed, not phone-number-matched.

Invoice from any channel

Send an invoice-style link from any app, any message, any thread. No merchant account needed.

Expose a payable endpoint to an agent

Publish a resolvable URL a counterparty’s agent can settle under its own policy. A standardised, addressable payable.

One-shot receives

Deposits, split bills, freelance invoices, any single receive. No closed-loop app. No full merchant stack.
03 / WHO IT’S FOR

​
Who it’s for.

Sumvin users and the apps that host them

Consumers and prosumers who need to be paid and want the transaction to carry a verified identity. Paid as themselves, not as an address.

Receive-money experiences built on Sumvin

Partner platforms ship identity-anchored request money without standing up merchant infrastructure. Rails, not acquiring.

A standardised, resolvable payment primitive

Agent builders settle against a structured endpoint under owner policy. A payable that machines can read.
04 / EARLY ACCESS

​
Shape the spec.

Payment request links are in early access. 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.

Contact your account manager

We co-design the integration, agree the scope surface, and wire you in against the current spec.
05 / START HERE

​
Where to start.

1

Create a payment link

Issue a shareable, identity-anchored payment request URL. Start with the payment link quickstart.
2

Accept a PINT at checkout

The settling side of the same primitive. Walk through accept a PINT at checkout.
3

Understand the rail

Read payment links and x402 for the conceptual model behind the primitive.
4

Layer on global acceptance

Global x402 acceptance is the persistent counterpart to ad-hoc links.
06 / RELATED

Verified checkout use-case

The authorising side of the primitive.

Agentic commerce overview

How agents read and settle payable endpoints.

Purchase Intents (PINTs)

The standardised scope object inside the link.

Sumvin identity overview

The identity layer every payment surface hangs off.
07 / QUESTIONS

​
Questions.

x402 is an HTTP-native payment standard: a server issues a 402 Payment Required challenge, the client signs an 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.
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 for the full conceptual model. Identity-anchoring is on the requester side, not the payer side.
No. Sumvin is an identity and payments platform. 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.