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.
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.
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
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.
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
https://paymentpointers.org and the appropriate
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
The client MAY probe the service endpoint using a
HEAD request instead of a
GET to avoid downloading the response content.
Having discovered the available payment methods, the client initiates the payment using one of the supported protocols.