Home › Browse › BIP 72

BIP 72: bitcoin: uri extensions for Payment Protocol

In plain English: Extends "bitcoin:" links (BIP 21) with a parameter pointing to a payment request from the payment protocol (BIP 70). Wallets that support the protocol fetch the merchant's signed request, while older wallets fall back to the plain address.

Status
Deployed
Type
Specification
Layer
Applications
Authors
Gavin Andresen
Assigned
Last changed
Topics
Payments, URI Schemes
Source
bip-0072.mediawiki on GitHub · Markdown

Abstract

This BIP describes an extension to the bitcoin: URI scheme (BIP 21) to support the payment protocol (BIP 70).

Motivation

Allow users to click on a link in a web page or email to initiate the payment protocol, while being backwards-compatible with existing bitcoin wallets.

Specification

The bitcoin: URI scheme is extended with an additional, optional "r" parameter, whose value is a URL from which a PaymentRequest message should be fetched (characters not allowed within the scope of a query parameter must be percent-encoded as described in RFC 3986 and bip-0021).

If the "r" parameter is provided and backwards compatibility is not required, then the bitcoin address portion of the URI may be omitted (the URI will be of the form: bitcoin:?r=... ).

When Bitcoin wallet software that supports this BIP receives a bitcoin: URI with a request parameter, it should ignore the bitcoin address/amount/label/message in the URI and instead fetch a PaymentRequest message and then follow the payment protocol, as described in BIP 70.

Bitcoin wallets must support fetching PaymentRequests via http and https protocols; they may support other protocols. Wallets must include an "Accept" HTTP header in HTTP(s) requests (as defined in RFC 2616):

Accept: application/bitcoin-paymentrequest

If a PaymentRequest cannot be obtained (perhaps the server is unavailable), then the customer should be informed that the merchant's payment processing system is unavailable. In the case of an HTTP request, status codes which are neither success nor error (such as redirect) should be handled as outlined in RFC 2616.

Compatibility

Wallet software that does not support this BIP will simply ignore the r parameter and will initiate a payment to bitcoin address.

Examples

A backwards-compatible request:

bitcoin:mq7se9wy2egettFxPbmn99cK8v5AFq55Lx?amount=0.11&r=https://merchant.com/pay.php?h%3D2a8628fc2fbe

Non-backwards-compatible equivalent:

bitcoin:?r=https://merchant.com/pay.php?h%3D2a8628fc2fbe

References

RFC 2616 : Hypertext Transfer Protocol -- HTTP/1.1

Related proposals

  • BIP 20: URI Scheme: Closed. An early proposal for "bitcoin:" links that bundle an address and amount, so clicking or scanning one opens a wallet ready to pay. It was superseded by BIP 21.
  • BIP 21: URI Scheme: Closed. Defines the "bitcoin:" link format that packages an address, amount, label and message into one string, often shown as a QR code. Wallets read these links to fill in payment details automatically,…
  • BIP 52: Durable, Low Energy Bitcoin PoW: Closed. Proposed replacing Bitcoin's mining puzzle with one designed for optical computing chips, so mining costs would depend more on hardware than on electricity. The aim was to cut energy use and spread…
  • BIP 70: Payment Protocol: Deployed. Defines a payment protocol in which a merchant sends a signed payment request directly to the customer's wallet. It aimed to improve checkout and protect against attackers swapping addresses, though…
  • BIP 71: Payment Protocol MIME types: Deployed. Defines official internet media types (MIME types) for payment protocol messages. These labels let browsers and email programs recognize a Bitcoin payment request and pass it to the right wallet.
  • BIP 73: Use "Accept" header for response type negotiation with Payment Request URLs: Deployed. Lets a payment request web link return either a webpage or a payment request file, depending on what the requesting software asks for. This allows short links that fit in QR codes to serve both…