| Internet-Draft | The pay URI Scheme | July 2026 |
| DiMare | Expires 28 January 2027 | [Page] |
This document defines the "pay" Uniform Resource Identifier (URI) scheme, a rail-neutral, human- and agent-friendly name for a payment payee that resolves, through a resolution protocol, to one or more concrete payment endpoints. Unlike a URI that names a specific account on a specific payment method, a "pay" URI names a payee independently of any settlement rail; a resolver deterministically maps the name to the rail(s), endpoint(s), and metadata a payer needs to construct a payment. This document specifies the scheme syntax and semantics, the resolution mechanism and its discovery, the deterministic resolution property, and requests provisional registration of the scheme with IANA per RFC 7595. It does not define a settlement protocol and takes no custody of funds; it composes with agent-payment protocols such as x402 for the actual money movement.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 28 January 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
AI agents and their operators increasingly need to pay one another without prior knowledge of each other's banking or on-ledger details. Today a payer must know a specific account on a specific rail (an IBAN, an on-ledger address, a card token) before value can move. That couples the payee's identity to a rail and leaks sensitive routing information to anyone who wants to pay.¶
The "pay" URI scheme decouples the two. A "pay" URI - for example
pay:acme or pay:agent.example - names a payee in a rail-neutral way. To pay it,
a payer submits the name to a resolver, which returns the payment endpoint(s) the
payee accepts, the preferred rail, and the metadata needed to construct a
compliant payment. The intelligence - rail selection, endpoint ordering - lives in
the resolver and is deterministic (see Section 4.4); the payer receives a
verifiable answer, not a probabilistic one.¶
This scheme is a naming and resolution layer only. It defines no settlement protocol, holds no funds, and is not a payment method in the sense of [RFC8905]. It is designed to compose with agent-payment protocols - notably x402 [X402], Agent2Agent [A2A], and agent-discovery systems such as [ANS] - which carry out the actual payment once a "pay" URI has been resolved.¶
This document specifies the reference resolution wire format used by the first deployed registry in an informative appendix (Appendix A). The normative content - the scheme syntax, the resolution mechanism, resolver discovery, and the deterministic property - is deliberately operator-neutral: nothing here requires any particular registry, and multiple independent resolvers can serve the scheme.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The following terms are used:¶
The rail-neutral payee name carried in a "pay" URI, i.e. the portion after the
pay: prefix.¶
A service that records the mapping from an alias to a payee and its payment endpoints.¶
A service that answers resolution requests for aliases, returning payment endpoints and metadata. A registry typically operates a resolver; the roles are logically distinct.¶
A settlement network or payment method (for example, a specific ledger or a bank-transfer scheme) over which value ultimately moves.¶
The act of mapping an alias to payment endpoint(s) and metadata.¶
The "pay" URI syntax is defined by the following ABNF [RFC5234], and is a restricted profile consistent with the generic syntax of [RFC3986]:¶
pay-URI = "pay:" alias alias = label *( "." label ) label = alnum *62( alnum / "-" ) alnum = DIGIT / lc-alpha lc-alpha = %x61-7A ; a-z (lowercase only)¶
Additional constraints:¶
The entire "pay" URI, including the pay: prefix, is at least 5 and at most 128
octets in length.¶
Each label is 1 to 63 octets and begins with an alphanumeric character.¶
Only lowercase ASCII letters, digits, and the hyphen appear in a label. No percent-encoding, uppercase letters, Unicode, userinfo, host, port, query, or fragment components are permitted. This restriction is deliberate: it eliminates homograph and normalization ambiguity (see Section 7).¶
A "pay" URI has no authority, path, query, or fragment component; the entire scheme-specific part is the alias.¶
A "pay" URI identifies a payee independently of any settlement rail. It does not identify an account, a wallet, a ledger address, or a transaction. Dereferencing a "pay" URI means submitting its alias to a resolver (Section 4) and receiving the payment endpoint(s) and metadata the payee accepts. The mapping from alias to payee is stable; the set of endpoints returned MAY vary over time and MAY be tailored to the resolution context (for example, an amount or currency hint).¶
The "payto" scheme [RFC8905] identifies a payment target on a specific method:
payto://iban/DE75... names an account reachable over a named payment method. The
"pay" scheme, by contrast, names a rail-neutral payee whose concrete
account(s)/endpoint(s) are discovered only at resolution time and MAY span several
rails. The two are complementary, not competing:¶
A "payto" URI is a fully-qualified destination; a "pay" URI is a name that resolves to one or more destinations.¶
A resolver MAY represent one of a payee's resolved endpoints as a "payto" URI where the target rail has a "payto" method registered.¶
"pay" adds rail selection and endpoint discovery above the destination layer that "payto" occupies.¶
A payer MUST determine a resolver for an alias before resolving it. Two mechanisms are defined; a payer that supports both SHOULD prefer a locally configured resolver.¶
A payer MAY be configured with a default resolver origin (an "https" origin). This is the simplest deployment and matches the reference deployment (Appendix A).¶
A resolver for a given operator domain MAY be discovered via a Service Binding
(SVCB) record [RFC9460] published at the name
_pay._agents.<operator-domain>, following the DNS-AID conventions [DNSAID].
The SVCB TargetName gives the resolver host; ALPN and port parameters give the
transport. When DNS-based discovery is used, the zone SHOULD be signed with
DNSSEC and a payer SHOULD NOT act on unsigned discovery data (see Section 7).¶
The _pay._agents label composes with the other _<service>._agents service
labels defined by [DNSAID] (for example _mcp and _a2a), allowing an operator
to publish payment-resolver discovery alongside agent-protocol discovery in one
zone. This mechanism keeps the scheme operator-neutral: any operator publishing the
record becomes discoverable in the standards-track way, with no central registry
required.¶
A resolver exposes resolution over HTTP. A payer resolves an alias by issuing an HTTP GET whose final path segment is the alias, or an HTTP POST carrying the alias and optional context (an amount, a currency, or a preferred rail) that the resolver MAY use to tailor the response. The reference request and response shapes are given in Appendix A.¶
A resolution response conveys, at minimum, the alias, a resolution status, and - on success - the payment endpoint(s) and preferred rail. The status is one of:¶
| status | meaning |
|---|---|
| resolved | the alias resolved to at least one payment endpoint |
| not_found | no payee is registered for the alias |
| compliance_pending | resolution is held pending compliance review |
| blocked | resolution is refused (for example, a sanctions match) |
| degraded | resolved, but with reduced confidence or a fallback path |
A resolver MAY disclose different levels of detail to different callers (for example, returning only status to unauthenticated callers and full routing metadata only to authorized ones). Such tiering is a resolver policy matter and is not constrained by this document, except that a resolver MUST NOT disclose payee routing metadata (account numbers, ledger addresses) to an unauthenticated caller.¶
Resolution MUST be deterministic: for a given alias and resolution context, a resolver MUST return the same routing decision. No probabilistic model, heuristic scorer, or machine-learning system is permitted in the resolution path. This is a verifiable protocol property: a payer, an auditor, or a compliance system can reproduce and check any resolution. Intelligence, if any, belongs in the calling agent that decides whether and how much to pay - never in the mapping from name to endpoint.¶
The "pay" scheme names and locates a payee; other protocols move the money.¶
x402 [X402]: after resolving pay:name, a payer MAY obtain HTTP 402 payment
requirements for the alias and settle over x402. The resolved endpoint and the
x402 "accepts" block describe the same payee.¶
Agent2Agent [A2A] and agent discovery [ANS]: an A2A Agent Card MAY advertise the ability to resolve or be paid via a "pay" URI; an ANS endpoint's metadata URL MAY point at such a card. In these compositions "pay" supplies the payee-naming and resolution layer that the discovery and messaging protocols lack.¶
In all cases the "pay" scheme remains off the settlement path: it answers "who is this payee and where can I pay them", not "move value now".¶
This document requests provisional registration of the "pay" URI scheme in the "Uniform Resource Identifier (URI) Schemes" registry, per the procedure in Section 7.2 of [RFC7595]:¶
pay¶
Provisional¶
Rail-neutral naming and resolution of payment payees for human- and agent-initiated payments; composition with agent-payment protocols (for example x402) that carry out settlement.¶
J. DiMare jdimare@pm.me¶
J. DiMare jdimare@pm.me¶
This document.¶
A payer relies on the resolver to map an alias to the correct payee. Payers MUST resolve over TLS. When a resolver is discovered via DNS (Section 4), the zone SHOULD be DNSSEC-signed and payers SHOULD reject unsigned discovery data, to prevent an attacker from substituting a hostile resolver.¶
The alias grammar admits only lowercase ASCII letters, digits, and the hyphen. There is no Unicode, no percent-encoding, and no case variation, so two distinct aliases cannot be visually confused through homograph or normalization tricks that affect internationalized identifiers.¶
Payee routing metadata (account numbers, ledger addresses) is sensitive. A resolver MUST NOT return such metadata to unauthenticated callers, and SHOULD apply least-disclosure by caller authorization.¶
A resolver holds no funds and does not settle. The deterministic-resolution requirement (Section 4.4) prevents a resolver from covertly steering payments through model-driven or non-reproducible logic, and makes every resolution auditable.¶
This scheme does not bind an amount or prevent replay; those properties belong to the settlement protocol (for example x402) invoked after resolution.¶
This appendix is informative. It documents the resolution wire format of the first deployed "pay" resolver, as an illustration of the mechanism in Section 4. It is not normative; other resolvers MAY use other encodings.¶
The reference resolver serves resolution at an "https" origin under /api/v1:¶
GET /api/v1/resolve/{alias} - resolve by path.¶
POST /api/v1/resolve - resolve with a JSON body
{ "alias_name": "...", "amount": "...", "currency": "...", "preferred_rail": "..." },
of which only alias_name is required.¶
Responses carry an X-Resolved-From header with value origin, cache, or
negative_cache, and a JSON envelope:¶
{
"success": true,
"data": { "...": "resolution object" },
"error_code": null,
"message": null,
"timestamp": "2026-07-27T00:00:00Z"
}
¶
The resolution object (fully disclosed) contains: resolution_id, message_id,
alias, status, resolved_at, resolved_from, and - on success -
preferred_rail, preferred_endpoint, fallback_endpoints, and optional
iso20022_hint, compliance, and agent_commerce blocks. Each endpoint carries a
rail_type, currency, priority, and (only to sufficiently authorized callers)
routing_metadata. An unauthenticated caller receives only
{ alias, status, resolution_id, message_id, resolved_at }, consistent with the
disclosure rule in Section 4.¶
Thanks to the maintainers of the DNS-AID, ANS, and x402 efforts, whose adjacent work this scheme is designed to compose with.¶