Wiki · Concept · Last reviewed June 25, 2026

Payment Method Identifiers

Payment Method Identifiers are the W3C Web Payments strings that name which payment methods a browser-mediated checkout can route toward.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: payment method identifiers, web payments, Payment Request, payment handlers, agentic commerce, browser API

Definition

Payment Method Identifiers, often shortened to PMIs in the W3C specification, are strings used by Web Payments specifications to identify payment methods on the web platform. The W3C Recommendation was published on September 8, 2022, and defines how these identifiers are validated, compared, minted, and, when applicable, registered. A PMI is not a credential, merchant account, or proof of payment. It is the name used before payment method-specific protocol can begin.

The specification divides PMIs into URL-based payment method identifiers and standardized payment method identifiers. A URL-based identifier is an HTTPS URL controlled by some web origin. A standardized identifier is a lower-case, hyphenated string for a W3C-standardized payment method. The base 2022 registry had no standardized identifiers at publication; the later Secure Payment Confirmation work defines secure-payment-confirmation as one for that authentication flow.

How It Works

In the Payment Request API, a merchant supplies payment method data when constructing a PaymentRequest. The supportedMethods value tells the user agent which methods the merchant says it can accept. The identifier is the routing key for payment choice: it helps the browser decide whether matching capabilities or handlers are available.

For URL-based PMIs, the W3C validation algorithm requires HTTPS and rejects URLs that include a username or password. A user agent may dereference the URL, but the identifier itself is not necessarily the machine-readable manifest. The W3C Payment Method Manifest draft describes how a payment method can point user agents toward a JSON manifest using an HTTP Link header. That manifest can name default payment applications and origins permitted to return credentials.

Payment handlers use the same naming layer. The Web-based Payment Handler API filters candidate handlers against the payment method identifier supplied in the payment request, then considers origin and manifest rules for URL-based methods. Secure Payment Confirmation is a narrower case: it builds a payment authentication ceremony around the standardized secure-payment-confirmation identifier and associated transaction context.

Agent Context

For Agentic Commerce, PMIs are a quiet but important boundary. An agent can search, compare, recommend, and prepare checkout, but the payment method identifier states which payment route the browser ceremony is being asked to use. If an agent controls copy, cart construction, or merchant-side integration, the identifier is part of the audit trail separating recommendation from authorization.

This matters because payment labels shown to a user are often softer than the underlying identifier. A button may say wallet, card, bank, pay later, or one-click checkout, while the browser sees a method string or URL. Governance should treat the identifier as a protocol fact, not marketing text.

Risks and Boundaries

A PMI does not prove the payee is legitimate, the product is accurately described, the payment handler is reputable, or the user intended the purchase. It names a payment method; other systems must handle consent, authentication, fraud controls, settlement, disputes, and compliance. Treating a PMI as trust would confuse a namespace with an institution.

URL-based identifiers add web-origin governance. That is useful because an origin can publish or reference a manifest, but operational drift matters: domains can expire, ownership can change, manifests can fail, and third-party handler authorization can be too broad. Standardized identifiers avoid domain ownership issues, but still require implementers to understand the specification that gives the string meaning.

Minimum Evidence Record

A governed checkout should record the merchant origin, top-level origin, embedding origin if any, supportedMethods values, identifier type, URL validation result, manifest URL and retrieval status when used, selected handler or authentication method, visible payee and total, user activation source, agent task identifier, response status, completion result, and dispute or refund path. Logs should avoid raw payment credentials and minimize retained address or contact data.

Defense Pattern

Spiralist Reading

Spiralism reads Payment Method Identifiers as a lesson in small names carrying large power. A short string can decide which institutions, handlers, user experiences, and dispute paths become available when desire turns into payment.

The humane demand is legibility. If machines help shop, negotiate, and transact, the payment namespace should remain inspectable by the person who bears the cost.

Sources

Return to Wiki