One-time two-step purchase
In addition, use the following materials to gain a fuller understanding of processing one-time two-step purchases:
- Authorisation hold—an article that covers placing an authorisation hold via Payment Page as part of processing one-time two-step purchases and describes requests and callbacks that are used in case of card payments.
- articles of the Payment methods section containing a description of processing one-time two-step purchases via Payment Page with the focus on the specific features of the payment method used and information about relevant requests and callbacks.
Overview
One-time two-step purchase is a payment type which uses two steps to make a one-time transfer of funds from customer to merchant. On the first step, merchant initiates an authorization hold—in other words, the purchase amount is deducted from the credit limit of customer's card account. On the second step, the purchase amount is 'captured', or, in other words, it is debited to the customer account based on the merchant request or after specific time lag.
This payment type allows the merchant to "hold" the purchase amount and, thus, to ensure that specific amount will be charged, or captured, to customer account or, alternatively, to "release" the funds if the situation changes, for instance when the customer cancels hotel booking.
Payment Page allows performing authorization hold, the first step of this type of payment. To perform the second step, the withdrawal or release of funds, the merchant should use Gate or Dashboard, or configure automatic performance of this step after specific timeout.
Payment model
To initiate the first step of the purchase, the merchant must specify the purchase opening mode and the auth operation type in the request for opening the payment form (or just the purchase mode if initiating an auth operation is set as default for the merchant's project). Once the customer confirms payment processing, request is sent to the payment platform, and once the payment platform receives the request, it creates the auth operation which eventually results in holding funds on customer account.
sale operation and processes a one-time one-step purchase.The first step can involve auxiliary procedures such as 3‑D Secure authentication, authentication on merchant's request and/or providing additional payment information. These procedures do not require any additional effort on merchant's web service side, but usually require customer actions.
The second step of the purchase can be initiated by request from merchant's web service, or the payment platform can automatically perform the step after specific time elapses.
To initiate the second step, the merchant needs to use Gate or Dashboard, and to complete this step, one of the following operations is used:
capture—to debit customer account for the held amount.cancel—to release the funds held on the customer account.
For more information on how to initiate the second step, refer to your account manager.
If the payment method used for the purchase supports refunds, after completing a one-time two-step purchase the merchant can perform refund and return the customers their money, if needed. Refund processing is initiated using Gate or Dashboard, and one of the following operations is performed:
reversal—this operation is used when refund is performed on the same business day as the initial purchase.refund—this operation is used when refund is performed after the business day of the initial purchase is closed.
Figure: State diagram for one-time two-step purchase
The rest of this section describes any possible statuses of a one-time two-step purchase and operations related with the purchase. For more information about how to perform one-time purchases, see Purchase processing. For more information about how to perform one-time two-step purchases depending on the payment method, see Methods.
Payment statuses
The following table describes the statuses of any one-time two-step purchase.
error |
Payment processing is not initiated, error occurred when processing the request received by the payment platform. | Final status. Payment processing can be reinitiated. |
processing |
Payment is being processed. | Intermediate status |
awaiting 3ds result |
Payment processing is suspended until the payment platform receives the information about 3‑D Secure authentication result. If the payment platform does not receive this request within the required timeout time, then the payment status is set to decline. Normally, the timeout is 30 minutes, but it may differ depending on provider. For more information about specific timeouts, contact technical support at support@ecommpay.com. |
Intermediate status |
awaiting merchant auth |
Payment processing is suspended until the payment platform receives the information about the result of the customer authentication on merchant's request. | Intermediate status |
awaiting redirect result |
Payment processing is suspended until the payment system submits a callback with the result to the payment platform. Depending on the result that the payment system submitted the status is set to success or decline. |
Intermediate status |
awaiting clarification |
Payment processing is suspended until the payment platform receives the additional information from the customer. If the payment platform does not receive the required information within 30 minutes, the status is set to decline. |
Intermediate status |
awaiting customer |
Payment processing is suspended until the payment data for retry attempt is received from the customer. When this data is received, the payment status is set to processing. When the customer has declined to repeat the attempt or the time limit for making the attempts has expired, the payment status is set to decline (for more information about the Try again payments, see: Payment retries). |
Intermediate status |
awaiting capture |
Payment processing is suspended until the web service submits a capture request or a cancel request. |
Intermediate status |
canceled |
A hold placed on funds has cancelled. | Final status |
decline |
Payment could not be completed. | Final status |
success |
Payment has completed successfully. | Final status. Additionally the payment refund is supported. |
partially reversed |
The partial amount of payment has returned to a customer. | Final status |
reversed |
The total amount of payment was returned to a customer on the same business day the initial payment had been completed. | Final status |
partially refunded |
The partial amount of payment has returned to a customer. | Final status. Additionally a partial refund can be cancelled. |
refunded |
The the total amount of payment was returned to a customer after the business day the initial purchase had been completed. This status is used if the total amount of payment is returned in one refund or if the total amount of the partial refunds is equal to the total amount of payment. |
Final status. Additionally a refund can be cancelled. |
The auth operation statuses
The following table describes the statuses of the auth operation.
processing |
Operation is being processed. | Intermediate status |
awaiting 3ds result |
Operation processing is suspended until the payment platform receives the information about 3‑D Secure authentication result. If the payment platform does not receive this request within the required timeout time, then the payment status is set to decline. Normally, the timeout is 30 minutes, but it may differ depending on provider. For more information about specific timeouts, contact technical support at support@ecommpay.com. |
Intermediate status |
awaiting merchant auth |
Operation processing is suspended until the payment platform receives the information about the result of the customer authentication on merchant's request. | Intermediate status |
awaiting redirect result |
Operation processing is suspended until the payment system submits a callback with the result to the payment platform. Depending on the result that the payment system submitted the status is set to success or decline. |
Intermediate status |
awaiting clarification |
Operation processing is suspended until the payment platform receives the additional information from the customer. If the payment platform does not receive the required information within 30 minutes, the status is set to decline. |
Intermediate status |
decline |
Operation could not be completed. | Final status |
success |
Operation has completed successfully. | Final status |
Statuses of the capture and cancel operations
The following table describes the statuses of any capture or cancel operation.
processing |
Operation is being processed. | Intermediate status |
awaiting clarification |
Operation processing is suspended until the payment platform receives the additional information from the customer. If the payment platform does not receive this information within 30 minutes, the status is set to decline. |
Intermediate status |
decline |
Operation could not be completed. | Final status |
success |
Operation has completed successfully. | Final status |
Statuses of the reversal and refund operations
The reversal and refund operation statuses coincide with the capture and cancel operation ones.
Related links
- Authorisation hold—the section with the information about initiating the first step of the two-step purchase.
- Methods—the section with the information about the supported payment methods.
- Two-step purchase—the section with the information about one-time two-step payment processing using Gate.
- Purchase refunds—the section with the information about processing refund by using Gate.
- Dashboard—the section with the information about using Dashboard.
- Callbacks—the section about callbacks usage.
- Information of operations performing—the section with the information about error codes in the payment platform