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.