Flow

When a user wishes to make or receive a payment, and is engaging with a counter-party that is able to process Payment Pointers, it provides a Payment Pointer to the counter-party.

The counter-party’s client then uses this Payment Pointer as described below to discover the services and accounts linked to the Payment Pointer and interact with these to send or request a payment.

This is analogous to how a user may provide a credit card number to a merchant to make a payment online, or provide their bank account details to a payer to receive a payment. However, in the case of Payment Pointers the pointer and the services are loosely coupled so a variety of service types could be discovered and payments can be both pushed and pulled from the user’s account initiated via the same Payment Pointer.

Step 1: Resolve Payment Initiation Service URL

The first step the client performs is to resolve the payment initiation service URL from the Payment Pointer using the rules defined in this specification.

Step 2: Discover Available Payment Methods

The client then uses the HTTP protocol to query the resolved payment initiation service URL and discover the payment methods supported by the service at that location.

The client does this by issuing a an HTTP GET to the URL and specifying the content types of the payment method responses it accepts in the Accept header.

The resolved endpoint MAY redirect the client to another URL but the client MUST ensure it affords the sender an opportunity to verify both the originally resolved and ultimate endpoint hosts.

Example:

GET /.well-known/pay HTTP/1.1
Host: alice.wallet.example
Accept: application/spsp+json, application/otherprotocolformat

If the service supports multiple payment methods it should respond using the type that it prefers and offer alternatives via Link headers using the rel type https://paymentpointers.org and the appropriate type parameter.

Example:

HTTP/1.1 200 OK
Content-Type: application/spsp+json
Connection: keep-alive
Link: </other>; rel="https://paymentpointers.org"; type="application/otherprotocolformat"

In the example above, the default service response uses the Simple Payment Setup Protocol as indicated by the Content-Type: application/spsp+json header. However, an alternative endpoint is available at the relative URL /other supporting the application/otherprotocolformat.

The client MAY probe the service endpoint using a HEAD request instead of a GET to avoid downloading the response content.

Step 3: Initiate Payment

Having discovered the available payment methods, the client initiates the payment using one of the supported protocols.