CIP: 14
Title: Burst Actions through Deeplink QR-codes
Author: PoCC/Brabantian
Comments-Summary: No comments yet.
Comments-URI: https://github.com/PoC-Consortium/CIPs/wiki/Comments:CIP-0014
Status: Active
Type: Enhancement
Created: 2018-08-19
QR codes with deeplinks enable users to scan a QR code, and be automatically led into a specific screen of an application of a mobile device. This deeplink is similar to a hyperlink we know from webpages. It contains a protocol refering to the application specified, and it can encode extra information on which screen it needs to lead to. This enables a very interactive experience using these QR codes, to improve the user experience of Burst.
One of the main goals of Burst is to be a monetary unit that's easily exchanged between different users. It is to be expected that most person-to-person Burst transactions will happen in stores. A client purchases an amount of items, and wishes to pay for it with Burst.
To facilitate this better, a Point of Sales (PoS) software should exist for the store to use, itemizing the different purchases, and adding them together to the sum that has to be paid by the client. After this, a QR code can be generated, which the client has to scan with their QR scanner, to lead them to the "payment" screen in their Burst mobile application. This screen will have a number of predefined values for the amount of Burst that has to be paid, the suggested fee, and an extra message (to link the transaction back to the internal DB of the PoS software), all defined by the PoS software.
As not all payments will happen in stores, an another use case is when one user wants to pay another one. Generating a QR code can improve the user experience of conducting such a transaction. Instead of requiring the sender to type in the recipient's Burst address, the recipient QR code can be scanned, and the remaining fields filled manually.
The capability improvement is not limited to usage in situations where the sender and the recipient are in the same location. Recipient QR codes can be published in various locations: e.g. an artist publishes their QR code next to a piece of art they created - enabling art lovers to give a donation by scanning the QR code as decsribed above.
To facilitate the QR code generation, a new dependency is added to the Zebra Crossing library, falling under the Apache License v2.0.
The deeplink will be built up with the values specified through the wallet API, and currently only supports a request for Burst. In case new possible actions are found to be useful, this protocol can be extended.
The request for Burst deeplink looks like one of the following patterns:
burst://requestBurst&receiver=[RECEIVER]&amountNQT=[AMOUNTNQT]&feeNQT=[FEENQT]&message=[MESSAGE]&immutable=[ISIMMUTABLE]
burst://requestBurst&receiver=[RECEIVER]&amountNQT=[AMOUNTNQT]&feeSuggestionType=[FEESUGGESTIONTYPE]&message=[MESSAGE]&immutable=[ISIMMUTABLE]
The meanings of these fields are the following:
- [RECEIVER]: Address that should receive the Burst
- [AMOUNTNQT]: Amount of Burst that should be sent
- [FEENQT]: An exact amount of Burst that should be used as the fee value
- [FEESUGGESTIONTYPE]: A CIP13 suggested transaction fee type
- [MESSAGE]: An extra message that can be passed along
- [ISIMMUTABLE]: A boolean field deciding whether the requested transaction should be immutable
In both cases the recipient field is always required. The remaining fields, apart from the message field are required in case [ISIMMUTABLE] is true.
[FEESUGGESTIONTYPE] and [FEENQT] are mutually exclusive. In case both values are given, a preference should be given for [FEENQT].
Additionally, an overlay with the Burst logo will be added to the generated QR code, to make it clear it's for Burst.
The wallet's HTTP API offers a "generateDeepLink" action, which takes the arguments passed into the resulting deeplink as its arguments.
After scanning the QR code, the engrained deeplink enables opening the mobile wallet to a specified screen.
In case all the required values are specified, this screen can lead to the payment screen which displays the payment values like recipient, amount to pay, either exact fee or suggested fee type, and an additional message.
Otherwise it will lead to a screen that will enable missing values to be filled in.
It's also possible for the requester to use a flag that will define whether the values are immutable or not - in case they're immutable, they can't be changed anymore by the Burst sender in the transaction.
Point of Sales Systems should do a HTTP call to their local BRS to generate their required QR code. It is recommended to use at least a standard or priority transaction fee. It is also recommended to pass along a message that enables linking the resulting transaction to somewhere in the Point of Sales System's database, to close up this information loop.
This document is placed in the public domain.