The workflow diagram and the accompanying descriptions cover the peculiarities of both schemes but are intended to explain a general case.
i. A shopper wants to make a deposit via a merchant's front-end resource.
2. The merchant creates a server session ("POST Create Server Session By Merchant API Key") by specifying relevant required and optional body parameters and using the provided cashier key and generated access token. The response contains a server-side (cashier) token.
3. The merchant shows the shopper a Cashier widget formed on the basis of
a script or an iframe with required and optional parameters (the regular Cashier scheme) or
a script or an iframe with the cashier token and some optional parameters (the server-side Cashier scheme).
The shopper enters missing information there, including debit or credit card credentials if applicable (3*). Upon submission, the merchant is notified that the Cashier session has been created (2*), and the request is forwarded to a PSP. The response contains one of the following: 3D Security dialog box requiring the payment confirmation, status "approved", or status "declined". Depending on this, the subsequent conduct varies.
The shopper is asked to confirm the payment by entering a security code, and after that the transaction is approved or declined (3**).
Upon confirmation or without it, the merchant is notified that the transaction has been approved or declined. The shopper is redirected to the respective page—"Success" or "Failure"—earlier defined by the merchant (3***). After that, the Cashier session is closed; the merchant is notified of this event too (2**).