Irrespective of the platform or programming language, integration with the Secure Receipt Wallet platform includes a common set of steps that are implemented in different platforms or languages differently. This chapter describes an overview of these common steps.
This step includes actions that have to be performed to get a POS station registered in Secure Receipt Wallet back-ends.
This is a once-off operation that has to be performed by a POS system user with administrative rights. This step includes calling SDK functions that use cryptographically-secure random generators to generate a range of cryptographic keys, specific to the POS station. The POS system must provide a user interface (e.g. dialog or screen) to guide the user through the registration process.
For a detailed description of the Secure Receipt Transfer protocol, please refer to https://SecureReceiptWallet.com.au/#security-architecture
The SDK includes libraries that securely store all such keys by encrypting them using keys that are either stored in the keychain storage of the POS station (if available) or using APIs available on the platform (e.g. Data Protection APIs on Windows).
The registration process includes an interactive process in which the registering user will have to enter the generated PUBLIC keys into the Secure Receipt Wallet Receipt Issuer’s Portal, following the creation of an account in the portal. The user must be given hints and instructions on needing an account before registering a POS station.
Secure Receipt Wallet never stores any PRIVATE keys on its back-ends, which effectively explains why the registration process has been designed this way. In effect, the registration process involves the sharing of only public keys with the back-ends and in return, receiving identifiers and key indexes that have to be saved as part of the configuration on the POS station.
In order for this process to work, the following steps must be taken.
This step includes actions to generate a receipt object and delivering it to a recipient using the SDK.
Once the configuration is completed, every time a receipt is ready to be transferred to a user, it can be delivered to the user electronically using Secure Receipt Wallet SDKs and APIs.
Obviously, before a 100% adoption is achieved, there may be buyers who may still prefer to receive their receipts in paper format. This is why POS systems adopting the Secure Receipt Wallet platform should provide user interface options to the POS operator to make a selection for the receipt delivery option. Effectively, the buyer should be asked about their preferred receipt delivery option and their choice will be reflected by the PSO operator.
In a similar fashion, for automated teller or check-out machines, the embedded POS system should be modified to provide an option for the user to make a selection for the receipt delivery options.
There are a range of options for the delivery process in the Secure Receipt Wallet platform which include the use of QR codes, or Seamless Transfer using the details extracted from the payment transaction in which the user will receive their receipts seamlessly by their Secure Receipt Wallet app without needing to perform a QR or RFID scan. These methods have been fully described in the Secure Receipt Transfer Protocol documentation at https://SecureReceiptWallet.com.au/#security-architecture . At this point in time, we recommend the QR scheme which minimizes the hassles and complexities of integration with banking systems and provides a quicker pathway to adoption. The process to generate the deliver a smart receipt includes the following steps.
The data model that Secure Receipt Wallet has adopted for receipts is comprehensive enough to cover almost all scenarios and types of receipts with different payment options. Each receipt row is independently created with details that the Secure Receipt Wallet app will use to provide extra options to users (e.g. re-ordering the same item, leaving a review, or simply browsing the properties of the item).
This includes the creation of the Receipt Sender object ad all its dependencies, including event handlers, data transfer facilitators and notifiers. The SDKs have been designed in a fully-extendable and abstracted fashion, leaving all options available to the community for innovation. For example, the QR Notifier can be replaced with an RFID notifier for a totally-different scheme of receipt delivery. At the point in time, the QR notifier is the default option.
This involves calling the delivery functions from the SDK and informing the POS operator (or end user/buyer) of the outcomes.
An end-to-end encryption delivery requires both parties in the conversation to exchange public keys. In practice, this means that the recipient no longer will be a passive entity just waiting to “receive” information. For the protection of buyers’ privacy and preservation of their anonymity (i.e. to ensure Secure Receipt Wallet can never know what buyers are buying or what sellers are selling and also to ensure it can never know who the buyer in a transaction is), the end-to-end encrypted delivery protocol in Secure Receipt Wallet requires the recipient to generate completely ephemeral keys for each receipt transfer that are not persisted in our back-ends (hence reinforcing lack of long-term identity keys for recipients). Together with private recipient’s signatures (derived from private keys), Secure Receipt Wallet is the only receipt transfer intermediary to assure zero knowledge against the data it transfers. For this to work when using the QR delivery scheme, Secure Receipt Wallet mobile apps and the local POS SDKs start a real-time communication using the Message Queue Telemetry Telemetry Transport (MQTT) protocol on a completely-random and independent channel for each receipt. All details on the delivery protocol can be found at https://SecureReceiptWallet.com.au/#security-architecture .
The last step in the transfer process is to report or log the results.