Related sections

What the consumer sees during the different flows are found under Execution flow screenshots

Relevant flows

Onboarding/authenticating and opening a wallet dashboard
Processing a payment and handling different payment statuses

Standard flow

createSession + openWallet

Lets the user onboard or authenticate to see their wallet.

createSession + initPayment

Lets the user approve payments initiated from a Point-of-Sale.

Related cancellation flows 🆕

While no Wallets SDK methods are directly involved, Membership App should handle/know about cancellations done by the consumer from the Wallets SDK Payment UI or the Merchant Store.

Payment cancelled from Payment UI

When the payment UI is closed from the Wallets SDK Payment UI before a transaction is processed, a callback is returned from the Wallets SDK.

Payment cancelled from Merchant Store (POS)

When the payment is cancelled from the Merchant Store before a transaction is processed, a callback is returned from the Wallets SDK.

Partial flow

createSession + getOpenWalletURL

Lets the user onboard or authenticate to see their wallet.

Enables the Mobile App to display their own intermediate screens between onboarding/authentication and viewing the Wallets Dashboard, but requires the Mobile App to open the Wallets Dashboard from their own application via a WebView.

getPaymentInstruments + signPayment

Lets the user approve payments initiated from the Point-of-Sale.

When a sale is triggered from a Merchant Store, the Mobile App backend should eventually push session data to the Mobile App. This allows the Mobile App to request payment data via getPaymentInstruments in order to display the info in the Mobile App Payment UI. When a user chooses to pay, the Mobile App calls the signPayment method including the selected payment instrument ID to sign the payment. When Wallets SDK has handled SCA, success or error is returned to the Mobile App which in turn must provide error or success feedback to the consumer.

The Mobile App Payment UI must adhere to payment scheme rules (e.g. PCI, voucher T&Cs) and must reference the official payment screen requirements documentation.

Internal dialog between Wallets SDK and WLW is hidden to avoid diagram complexity.

cancelPayment 🆕

After the Mobile App Payment UI is opened, the Mobile App must notify other systems of any payment cancellation initiated by the consumer, e.g. clicking cancel/close buttons or swiping away a dialog. The method should not be called when cancellation occurs after the transaction has been conducted with success or error result.

Related cancellation flow: Payment cancelled from Merchant Store (POS)

While no Wallets SDK methods are directly involved, Membership App should handle incoming push messages regarding cancellations from Merchant Store.