One-time two-step purchase

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 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 model

You initiate the first step of a purchase by sending an auth request to the payment platform or by opening the payment form in the purchase mode with the auth operation type specified. Once the payment platform receives the request, it creates an auth operation which eventually results in holding funds on customer account.

The first step may require merchant to issue additional requests:

  • If the payment requires customer to be authenticated by using the 3‑D Secure technology, the payment platform sends to the web service a callback that contains the data required to generate a request to the issuer and suspends the purchase processing until the authentication result information is received. For submitting the information, in case of working via Gate, it is required to send a request with the authentication result—3ds_result—, while in case of working via Payment Page, all actions are carried out without the merchant's web service involved.
  • If the payment requires customer to be authenticated by the payment system on merchant's request, the payment platform receives a notification from the payment system and sends to the web service a callback with notification that authentication is required, and then suspends the payment processing in the platform. To continue processing the payment, in case of working via Gate, two merchant_auth requests should be sent: start—after the customer confirms the payment and finish—after the customer enters the validation code, while in case of working via Payment Page, all actions are carried out without the merchant's web service involved.
  • If any payment stakeholder requests additional information (For example, the payment system may request cardholder address which was missing from the initial request.), the payment platform sends to the web service a callback that lists the requested parameters and suspends the purchase processing until the required information is received. In case of working via Gate, a request should be sent with the needed information included—clarification, while in case of working via Payment Page, all actions are carried out without the merchant's web service involved.

The second step may be initiated by a request from merchant's web service, through an action in the Dashboard or the payment platform may automatically perform the step after specific time elapses.

The merchant initiates the second step by sending one of the following requests to the payment platform:

  • capture—this request processing results in a capture operation and the customer account is debited for the held amount.
  • cancel—this request processing results in a cancel operation and release of the funds held on the customer account.

In your capture request, you can specify a to-be-debited amount which is different from the initially authorised amount.

For more information on how to initiate the second step, refer to your account manager.

If the payment method supports refunds, after completing the second step of a one-time two-step purchase, you can refund the purchase. This can be done by sending a refund request to the payment platform or as a result of the corresponding action on the payment information tab in the Dashboard interface. For a refund within a card payment, depending on the refund time and amount and the payment instrument used for the payment, one of the following operations is initiated:

  • reversal if the refund is initiated within the operation day regardless of the purchase amount for a Mastercard card and provided that the total purchase amount is refunded for a card of any other card network;
  • refund if the refund is initiated for a card of any card network after operation day and regardless of the amount and within the operation day provided that a partial purchase amount is refunded for a card of all card networks except Mastercard.
Figure 1. 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 the related operations. More information about processing one-time two-step purchases using payment cards is provided in the Payment Page and Gate sections, while the information about processing purchases with the use of other payment instruments is provided in the Payment methods section.

Payment statuses

The following table describes the statuses of a one-time two-step purchase.

error Error occurred when request processing. Payment is not performed. Final status. The request can be resent with the same payment identifier and the same payment can be retried.
processing Payment is being processed. Intermediate status
awaiting 3ds result Payment processing is suspended until the information about the 3‑D Secure authentication result is received. If this information is not received 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 a 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 customer authentication initiated in a payment system on the merchant's request is completed. 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 required additional information is received. If the information is not received within 30 minutes, the payment is assigned the decline status Intermediate status
awaiting customer

Payment processing is suspended until one of additional attempts to perform this payment is completed (in this case, the status is set to successor all additional attempts are used up (in this case, the 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 was cancelled. Final status
decline Payment could not be completed. Final status
success Payment has been completed. Final status. Additionally, the payment refund is supported.
partially reversed Payment amount is partially refunded within the operation day on which the payment was completed. Final status
reversed Total payment amount is refunded within the operation day on which the payment was completed. Final status. Additionally, the refund can be cancelled.
partially refunded Partial amount of the payment is returned to the customer. Final status. Additionally a partial refund can be cancelled.
refunded Payment amount is fully refunded after the operation day on which the payment was 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 Payment processing is suspended until the information about the 3‑D Secure authentication result is received. If this information is not received 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 a 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 customer authentication initiated in a payment system on the merchant's request is completed. 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 Payment processing is suspended until the required additional information is received. If the information is not received within 30 minutes, the payment is assigned the decline status Intermediate status
decline Operation could not be completed. Final status
success Operation has been completed. Final status

Statuses of the incremental operation

The following table describes the statuses of the incremental operation.

decline Operation is declined. Final status
success Operation is completed. 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 Payment processing is suspended until the required additional information is received. If the information is not received within 30 minutes, the payment is assigned the decline status Intermediate status
decline Operation could not be completed. Final status
success Operation has been completed. Final status

Statuses of the reversal and refund operations

The reversal and refund operation statuses coincide with the statuses of the capture and cancel operations.