Bill Request Message - (another) Proposed BIP 70 extension

Here's an idea for a BIP 70 extension to let wallets be scanned by merchant bar code readers to start off a payment request flow instead of the other way around (wallet scanning the merchant QR). Useful for brick and mortar merchants and mobile wallet apps.

Motivation: A mechanism is needed for mobile wallets to request a bill, so that a payment protocol flow can be initiated. Current mechanisms for initiating BIP70 payment flows generally require wallets to either scan a merchant barcode (not optimal, see below), or click on a specially formatted url link (only suitable while browsing and purchasing on a merchant website).

Successful non-bitcoin mobile wallet apps to date (a popular coffee shop app comes to mind) allow for the wallet app to be scanned by the merchant and not the other way around (as is commonly done in bitcoin wallets today). For broad bitcoin adoption we need a mechanism for wallets to be scanned by merchant bar code readers at brick and mortar shops. This will also greatly ease checkouts at drive throughs and allows merchants to leverage existing hardware (barcode readers).

Other technologies like NFC may obviate the need for this extension, however, those technologies remain somewhat uncommon and may not be suitable for smaller wearables hitting the market.

message BillRequest { required uint64 time = 1; optional uint64 expires = 2; required string bill_request_uri = 3; }

time - Unix timestamp (seconds since 1-Jan-1970 UTC) when the BillRequest was created. expires - Unix timestamp (UTC) after which the BillRequest should be considered invalid (wallets may only be monitoring for messages for a short time). bill_req_addr - Typically a URL where a BIP70 payment request can be sent that is being monitored by the wallet. However this could also support URIs like "sms:860-555-1212" or "mailto:asdf@gmail.com" allowing for a variety of connection options.

Recommendations: it is recommended that wallet apps display a non-QR barcode like a PDF417 barcode to initiate the Bill Request flow. This will avoid confusion with existing QR code usage in wallet apps.

-------- Paul G.

I'm not convinced this inversion is really a problem, but as this is quite a complex proposal (e.g. new barcode types) the best way to move it forward at this stage is to implement it in some existing wallets.

FWIW NFC is a lot more common than you might think. For the drive-thru case you could also consider using wifi hotspots with a special name or Bluetooth LE tags. So I suspect before trying to write a specification it'd be better to explore different technologies and see what works best in practice.

On Tue, Jun 24, 2014 at 9:44 PM, Paul Goldstein <paul@realfoot•com> wrote:

> Here's an idea for a BIP 70 extension to let wallets be scanned by
> merchant bar code readers to start off a payment request flow instead of
> the other way around (wallet scanning the merchant QR). Useful for brick
> and mortar merchants and mobile wallet apps.
>
>
> Motivation:
> A mechanism is needed for mobile wallets to request a bill, so that a
> payment protocol flow can be initiated. Current mechanisms for initiating
> BIP70 payment flows generally require wallets to either scan a merchant
> barcode (not optimal, see below), or click on a specially formatted url
> link (only suitable while browsing and purchasing on a merchant website).
>
> Successful non-bitcoin mobile wallet apps to date (a popular coffee shop
> app comes to mind) allow for the wallet app to be scanned by the merchant
> and not the other way around (as is commonly done in bitcoin wallets
> today). For broad bitcoin adoption we need a mechanism for wallets to be
> scanned by merchant bar code readers at brick and mortar shops. This will
> also greatly ease checkouts at drive throughs and allows merchants to
> leverage existing hardware (barcode readers).
>
> Other technologies like NFC may obviate the need for this extension,
> however, those technologies remain somewhat uncommon and may not be
> suitable for smaller wearables hitting the market.
>
> message BillRequest {
>  required uint64 time = 1;
>  optional uint64 expires = 2;
>  required string bill_request_uri = 3;
> }
>
>
> time - Unix timestamp (seconds since 1-Jan-1970 UTC) when the BillRequest
> was created.
> expires - Unix timestamp (UTC) after which the BillRequest should be
> considered invalid (wallets may only be monitoring for messages for a short
> time).
> bill_req_addr - Typically a URL where a BIP70 payment request can be sent
> that is being monitored by the wallet. However this could also support URIs
> like "sms:860-555-1212" or "mailto:asdf@gmail.com" allowing for a variety
> of connection options.
>
> Recommendations: it is recommended that wallet apps display a non-QR
> barcode like a PDF417 barcode to initiate the Bill Request flow. This will
> avoid confusion with existing QR code usage in wallet apps.
>
> --------
> Paul G.
>
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

Alright. I still tend to think it's not a big deal, but there's no reason both or all mechanisms can't co-exist.

BTW: a QR code next to a cash register can be fixed i.e. printed on paper when using BIP70. The PoS would upload payment details to the server and the URL for that particular PoS unit would then serve it when the user scans the QR code. Alternatively, Andreas' work on Bluetooth may be more appropriate: the QR code can contain the BT MAC of the device and the payment request is downloaded that way. That's already implemented! I still feel that if a seller can scan a users phone, the users phone can certainly scan some rectangle that's physically near by the sales counter.

The other nice thing about that approach is the QRcode can also be an NFC tag i.e. have the tag behind it with a little icon in the middle of the QR code to indicate that touching works as well as scanning.

One project I keep wanting to play with is making these little NFC-QRcode hybrids and a simple PoS app to go with them. But no time, alas ....