Skip to main content

Introduction

From the customer experience point of view, a Zastrpay QR Code Cash Payment in a nutshell consists of 2 steps:

  1. Customer creates online a Transaction Intent or a QR Code (after being redirected to Zastrpay Customer website from the Merchant website or app1) a. In case of a withdrawal the merchant blocks/takes away the money from the customer's wallet
  2. Customer goes to a Zastrpay shop and has the QR Code scanned by the cashier. a. In case of a deposit the customer hands over the cash to the cashier, a Transaction is created, and the money is put on the customer's wallet at the merchant website b. In case of a withdrawal a Transaction is created, and the cashier hands over the cash to the customer (money was deducted from customer's wallet in advance).

Additionally, a Zastrpay QR Code Cash Payment may include as part of the flow the creation of a new account for a customer who is using Zastrpay QR Code Cash Payments for the first time.

From the technical point of view, the basic or minimal integration requires:

  1. an API call (Merchant Backend -> Zastrpay Backend) for creating a so-called Redirect Session
  2. a customer redirect (Frontend) using a javascript helper library
  3. handling a few webhooks (Zastrpay Backend -> Merchant Backend).

On top of that a few additional interactions may be added, e.g. checking whether a customer currently has an active QR code, trigger a refund, register a new customer, etc.

QR Code Deposit​

The diagram below illustrates the basic flow of a customer deposit to his online account at a merchant website, or alternatively, paying with cash for an online purchase at a merchant website:

Deposit

Steps:

  1. Customer goes to the Merchant website or app and chooses Zastrpay QR Code Cash Deposit as the payment method
  2. Merchant Website/Backend creates a Redirect Session by calling Zastrpay Backend
  3. Merchant Website redirects customer to Zastrpay Customer Redirect Website
  4. Customer logs in or registers with Zastrpay, and generates a QR Code or Transaction Intent
  5. Customer goes to a Zastrpay Shop, present the QR Code, upon scanning of which a Transaction is executed and notified to the Merchant Backend (to put the funds in the customer wallet or mark an order as paid)

QR Code Withdrawal​

The diagram below illustrates the basic flow of a customer deposit to his online account at a merchant website, or alternatively, paying with cash for an online purchase at a merchant website:

Withdrawal

Steps:

  1. Customer goes to the Merchant website or app and chooses Zastrpay QR Code Cash Withdrawal as the payment method
  2. Merchant Website/Backend creates a Redirect Session by calling Zastrpay Backend
  3. Merchant Website redirects customer to Zastrpay Customer Redirect Website
  4. Customer logs in or registers with Zastrpay, and generates a QR Code or Transaction Intent
  5. Customer goes to a Zastrpay Shop, present the QR Code, upon scanning of which a Transaction is executed and notified to the Merchant Backend (for example to remove previously blocked funds)
  6. In case the transaction intent expires, then a notification is sent to the Merchant Backend (for example to put back previously blocked funds)

Main involved Resources/Entities​

As mentioned above, there are 3 resources or entities created during the end-to-end processing of a Zastrpay QR Code Cash Payment:

Main Entities

  1. Redirect Session - represents the customer redirect
  2. Transaction Intent - represents the generated QR Code
  3. Transaction - represent the transaction (deposit or withdrawal) executed at the end of the customer journey
note

There is 1:1:1 relationship between Redirect Session : Transaction Intent : Transaction. Furthermore, Redirect Session.Id (client-generated UUID/GUID) = Transaction Intent.Id = Transaction.Id.

Whereas Redirect Session does not have an externally-shared lifecycle (in the form of states/events communicated via webhooks), Transaction Intent and Transaction do have such. The diagram below illustrates the states and emitted events during the processing of the two:

Transaction Intent and Transaction State and Events

Notes:

  1. Finalized state of transaction intent only indicates that the process has finished, but not necessarily that the created transaction is processed successfully.
  2. Therefore the Finalized state of the transaction intent is emitted after the transaction processing is finished.
  3. Transaction intent goes to Expired state 15 minutes after initial creation if not yet in a final state.
  4. Cancelled state of transaction is a state indicating a processing failure

Footnotes​

  1. Using WebView ↩