]> DNS of Money

jdimare@pm.me

payment URI agent resolution x402 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.

Introduction 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 ); 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 . It is designed to compose with agent-payment protocols - notably x402 , Agent2Agent , and agent-discovery systems such as - 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 (). 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.

Conventions and Terminology 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 when, and only when, they appear in all capitals, as shown here. The following terms are used:

alias:

The rail-neutral payee name carried in a "pay" URI, i.e. the portion after the pay: prefix.

registry:

A service that records the mapping from an alias to a payee and its payment endpoints.

resolver:

A service that answers resolution requests for aliases, returning payment endpoints and metadata. A registry typically operates a resolver; the roles are logically distinct.

rail:

A settlement network or payment method (for example, a specific ledger or a bank-transfer scheme) over which value ultimately moves.

resolution:

The act of mapping an alias to payment endpoint(s) and metadata.

The "pay" URI Scheme

Syntax The "pay" URI syntax is defined by the following ABNF , and is a restricted profile consistent with the generic syntax of : 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 ).

A "pay" URI has no authority, path, query, or fragment component; the entire scheme-specific part is the alias.

Semantics 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 () 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).

Comparison with the "payto" URI scheme The "payto" scheme 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.

Resolution

Resolver discovery 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.

1. 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 ().

2. DNS-based discovery:

   A resolver for a given operator domain MAY be discovered via a Service Binding (SVCB) record published at the name _pay._agents.<operator-domain>, following the DNS-AID conventions . 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 ).

The _pay._agents label composes with the other _<service>._agents service labels defined by (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.

Resolution request 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 .

Resolution response 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.

Deterministic resolution 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.

Composition with Agent-Payment Protocols The "pay" scheme names and locates a payee; other protocols move the money.

• 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 and agent discovery : 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".

IANA Considerations 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 :

Scheme name:

pay

Status:

Provisional

Applications/protocols that use this scheme name:

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.

Contact:

J. DiMare jdimare@pm.me

Change controller:

J. DiMare jdimare@pm.me

References:

This document.

Security Considerations

Resolution integrity:

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 (), the zone SHOULD be DNSSEC-signed and payers SHOULD reject unsigned discovery data, to prevent an attacker from substituting a hostile resolver.

Homograph and normalization safety:

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.

Routing-metadata disclosure:

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.

No custody, deterministic path:

A resolver holds no funds and does not settle. The deterministic-resolution requirement () prevents a resolver from covertly steering payments through model-driven or non-reproducible logic, and makes every resolution auditable.

Amount and replay binding:

This scheme does not bind an amount or prevent replay; those properties belong to the settlement protocol (for example x402) invoked after resolution.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document updates the guidelines and recommendations, as well as the IANA registration processes, for the definition of Uniform Resource Identifier (URI) schemes. It obsoletes RFC 4395. This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] Informative References This document defines the 'payto' Uniform Resource Identifier (URI) scheme for designating targets for payments. A unified URI scheme for all payment target types allows applications to offer user interactions with URIs that represent payment targets, simplifying the introduction of new payment systems and applications.

Reference deployment wire format This appendix is informative. It documents the resolution wire format of the first deployed "pay" resolver, as an illustration of the mechanism in . 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: 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 .

Acknowledgements Thanks to the maintainers of the DNS-AID, ANS, and x402 efforts, whose adjacent work this scheme is designed to compose with.