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).
and (3*) get the notification (cashier.session.init) of cashier initialization. The shopper is asked to fill-in any information which was not supplied from merchant during cashier initialization.
Once shopper submits the cashier form; the request to make a deposit is submitted to the PSP who in his turn decides if (3**) 3D Secure dialog box will be shown requesting confirmation for the transaction or respond back with the status of the transaction: "approved" or "declined".
4. We confirm transaction with PSP with transaction check status and only thereafter the transaction is marked as approved or declined. (4*) A notification is send to merchant with the outcome.
5. Shopper is shown the transaction status and afterwards been redirected to the appropriate URL. (5*) The final notification is send to merchant for cashier.session.close