mirror of
https://github.com/bitcoinbook/bitcoinbook
synced 2024-12-26 00:18:11 +00:00
88 lines
2.9 KiB
Plaintext
88 lines
2.9 KiB
Plaintext
|
-----------------------------------------------------
|
||
|
|
BIP: 72
|
||
|
|
Title: bitcoin: uri extensions for Payment Protocol
|
||
|
|
Author: Gavin Andresen <gavinandresen@gmail.com>
|
||
|
|
Status: Draft
|
||
|
|
Type: Standards Track
|
||
|
|
Created: 2013-07-29
|
||
|
|
-----------------------------------------------------
|
||
|
|
|
||
|
|
[[abstract]]
|
||
|
|
Abstract
|
||
|
|
~~~~~~~~
|
||
|
|
|
||
|
|
This BIP describes an extension to the bitcoin: URI scheme (BIP 21) to
|
||
|
|
support the payment protocol (BIP 70).
|
||
|
|
|
||
|
|
[[motivation]]
|
||
|
|
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]]
|
||
|
|
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]]
|
||
|
|
Compatibility
|
||
|
|
~~~~~~~~~~~~~
|
||
|
|
|
||
|
|
Wallet software that does not support this BIP will simply ignore the r
|
||
|
|
parameter and will initiate a payment to bitcoin address.
|
||
|
|
|
||
|
|
[[examples]]
|
||
|
|
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]]
|
||
|
|
References
|
||
|
|
~~~~~~~~~~
|
||
|
|
|
||
|
|
http://www.w3.org/Protocols/rfc2616/rfc2616.html[RFC 2616] : Hypertext
|
||
|
|
Transfer Protocol -- HTTP/1.1
|