Partner Message Flows
From a partner perspective, a QR payment flow comprises the following operations:
- Notifying Electrum of a QR Code scan.
- Receiving a payment authorisation request associated with the above scan.
- Finalising or reversing this payment based on the advice message received.
Once a scan is made by a mobile application it is necessary to notify the Electrum server of this action by sending a
As it is not possible for the retailer to know at tender time which partner has been selected by the customer, the
ScanNotification plays the important role of alerting the Electrum system which partner has been selected for a given
ScanNotification carries the unique transaction ID (
tranId) encoded in the QR code and allows the Electrum system to match the scan
PaymentRequest sent upstream by the retailer.
There are a number of scenarios in which it is possible for a
ScanNotification to fail. In these scenarios it is necessary to notify the customer via the application that their request to tender has failed. Examples include the following:
PaymentRequest from a retailer was received
ScanNotification reached Electrum after the agreed upon timeout window had elapsed
ScanNotification arrived at Electrum before the
PaymentRequest from the retailer.
Payment Authorisations and Finalisations
ScanNotification is received it is possible for the Electrum system to process the associated
PaymentRequest received from the retailer.
The payment flow is dual message and comprises two messages:
- A payment authorisation request (
PaymentRequest), which requests the funds to be reserved for tender by the partner.
- One of the following two advice messages, which will be sent “offline” and subject to SAF:
- A finalisation advice (
ConfirmationAdvice), which signifies that the tender was successfully completed by the retailer and the funds should be withdrawn.
- A reversal (
ReversalAdvice), which signifies that the tender was not completed and that the reservation on the funds should be removed.
- A finalisation advice (
Tender Reversals and Timeout Reversals
Payment authorisations are required to be reversible. These reversals may be sent in either of the scenarios below:
- By a retailer to void an otherwise successfully processed payment authorisation. This may be for any number of reasons: the customer has opted to not go through with the tender, the POS malfunctioned, the basket has been voided, etc.
- By Electrum in cases where no response to a
PaymentRequestwas received and the state of the transaction upstream is unknown. In this scenario a
PaymentReversal, as a “Timeout Reversal”, will be sent to ensure that it is safe for downstream entities to proceed as if the transaction has not gone through. A
PaymentReversalwill be subject to SAF, thus it is guaranteed that this transaction will eventually be reversed.
In both case above, reversals are intended to correct a system issue or a cancelled transaction, and thus will not be used as a general-purpose refund mechanism. Customer refunds and return of goods are out of scope of this document.
The flow for a Timeout Reversal between a processor and Electrum is as per the diagram below:
The full flow for a retailer-triggered payment reversal is as per the diagram below.
The full flow for a Timeout Reversal is as per the diagram below.