1.2. Server-to-Server Preauth, Capture and Cancel
Introduction
Preauthorization is a transaction type in which bank blocks the specified amount in the Payer’s card account and does not allow the cardholder to use this blocked money. It is important to know that the block remains for a definite period of time depending on whether this is a debit or a credit card (usually the maximum block period is 7 days for debit cards and 28 days for credit cards). In this use case Server-to-server Preauth, card data is transferred directly in initiating request.
See terms definitions (Connecting Party, 3DS Method, etc) in Glossary.
Capture is a transaction followed after preauth which deducts the locked amount from Payer’s card.
Cancel is opposite of Capture which cancels the deduction and returns locked amount back to Payer’s card.
Preauth Flow
(2) To implement preauth request see /api/v2/preauth/. See 3DS Overview to get more information about 3DS flow. See 3DS Decision Making Schema and 3DS Implementation Scenarios to correctly implement 3DS flow for this Use-Case.
(5) To implement callback with final status handling see Connecting Party Callback.
(7) To implement order status request see /api/v2/status/. Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
3DS Decision Making Schema
Connecting party has to implement all steps marked in green and purple. Below are the description for steps which reference specific API commands according to the step ID:
(1) To implement order status request see /api/v2/status/. Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
(4) If html and redirect-to fields are present, see Simplified authentication flow with html page.
(5) The same as point (1).
Note
The 3DS decision making schema is showcasing 3DS being initiated and performed by Payment Gateway. 3DS is initiated by Payment Gateway and performed on Connecting Party side., see 3DS Overview
Non3D Flow
Sale transaction should be considered as non3D (no 3DS authentication) if all conditions are met:
1. steps 1-2-(5)-6 of 3DS decision making schema were followed.
2. tds_status, html and redirect-to parameters were not present.
3. transaction received final status (approved, declined, error, filtered).
Note
Please note that transaction status “unknown” might appear for both 3DS and non3D transactions. See details in Statuses.
Simplified Authentication Flow
(1) and (2) To implement order status request see /api/v2/status/.
(9) To implement final redirect see Final redirect.
(10) The HTML wait page on Connecting Party side can have custom design and should communicate with Connecting Party server as described on the diagram.
(15) and (16) The same as point (1) and (2).
Capture Flow
(1) Capture can be initiated by Connecting Party based on internal business process or Payer’s request.
(2) To implement capture request see /api/v2/capture/.
(5) Callback for Capture will be sent only if notify_url was provided in initial transaction request or additional callback URL for Capture transactions is specified on the endpoint level. If server_callback_url was provided in initial transaction request, callback for Capture will not be sent. To implement callback with final status handling see Connecting Party Callback.
(7) To implement order status request see /api/v2/status/. Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
(9) Final Status can be sent by Connecting Party based on internal business model or by Payer’s request.
Cancel Flow
(1) Cancel can be initiated by Connecting Party based on internal business process or Payer’s request.
(2) To implement cancel request see /api/v2/return/.
(5) Callback for Cancel will be sent only if notify_url was provided in initial transaction request or additional callback URL for Cancel transactions is specified on the endpoint level. If server_callback_url was provided in initial transaction request, callback for Cancel will not be sent. To implement callback with final status handling see Connecting Party Callback.
(7) To implement order status request see /api/v2/status/. Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
(9) Final Status can be sent by Connecting Party based on internal business model or by Payer’s request.