BRC-27 defines an abstract messaging protocol that facilitates payments on the Bitcoin SV network. This specification extends the protocol with the specifics required for a concrete HTTPS implementation that includes message size limits and HTTPS-specific implementation details.
HTTPS is one of the most widely used transport mechanisms for internet traffic. Enabling users of HTTPS to benefit from the use of the BRC-27 DPP will facilitate increased industry adoption and growth. Defining implementation-specific stipulations for HTTPS-based DPP will address problems and ambiguities specific to this communications substrate.
Below is the table with messages requested from client (wallet) to merchant (server).
The paymentID parameter is assumed to be known as a result of request between client-server before DPP protocol operation.
| MESSAGE | ENDPOINTS | TYPE/SUBTYPE | RESPONSE CODES |
|---|---|---|---|
| PaymentTerms | GET /api/v1/payment/{paymentID} |
application/json | 200 – contains PaymentTerms JSON object with all data used by the payee to construct a transaction 404 – returned if the paymentID has not been found 500 – returned if there is an unexpected internal error |
| Payment | POST /api/v1/payment/{paymentID} |
application/json | 201 – contains PaymentACK JSON object 400 – returned if the user input is invalid, usually an issue with the paymentID 404 – returned if the paymentID has not been found 500 – returned if there is an unexpected internal error |
PaymentTerms messages larger than 10 MB should be rejected by the wallet application, to mitigate denial-of-service attacks.
Payment messages larger than 10 MB should be rejected by the payment host’s server, to mitigate denial-of-service attacks.
PaymentACK messages larger than 11 MB bytes should be rejected by the wallet application, to mitigate denial-of-service attacks. This is larger than the limits on Payment and PaymentTerms messages as PaymentACK contains a full Payment message within it.
The BRC-55 API is implemented in this example from Jad Wahab.