Cascade payment processing

Cascading option with card payments

Overview

Payments could sometimes fail due to different reasons. For example, while a payment is being processed by a provider or a bank, technical issues may occur, or processing of the payment may take too long, or a customer's card limit may have been reached.

The ECommPay payment platform supports cascade payment processing that includes additional attempts to process a payment if your initial attempt to process the payment was unsuccessful. In any of the above cases, the cascading option enabled allows the payment that cannot be processed properly by a provider to be rerouted to an alternative provider with no change of the payment method. In card payments, you can use the cascading option for both one-step and two-step purchases with authentication by using 3‑D Secure as well as without authentication.

In card payments, a customer may be charged only once for the same payment, that's why it is the payment platform which is required to initiate new additional attempts to process the payment.

Using the cascading option requires to update the merchant web service because the workflow of cascade payment processing includes additional steps that are not included in the workflow of regular payment processing. The following section discusses in more details the workflow of cascade payment processing and how to integrate the option in your web service.

Setup and configuration

To integrate and enable the cascading option in your web service, you need to do the following:

  1. Address the organisational interaction issue with ECommPay.

    Contact your ECommPay key account manager and discuss the possibility of implementing the option and updates of your web service that the option requires.

  2. Update your web service to support the cascading option.
    • Update your payment pages with additional user interface elements.

      If an additional attempt requires performing 3‑D Secure authentication, notifications are recommended to inform a customer that the initial attempt was unsuccessful and then to ask the customer to confirm one more 3‑D Secure authentication with the same card details. You may use notification as an informational component and a button as an input control. Also if the limit on the number of allowed attempts has been reached, you may ask the customer to use another payment method and then to initiate a new payment with a new payment identifier (payment_id).

    • Support 3‑D Secure authentication more than once for the same payment without updating card details.

      To support multiple authentication, your web service is required to receive callbacks that contain customer redirection data and the new cascading_with_redirect parameter, and then, if the customer accepts, is required to redirect customer to ACS URL.

  3. Test and deploy cascade payment processing with the ECommPay technical support.

Workflow

Payments with the enabled cascading option are initiated in the same way as regular payments. Your web service is required to send a request for purchase to initiate an attempt to process the payment. The payment platform accepts the request, and then the 3‑D Secure authentication may be required. If a customer is charged for this attempt, the payment platform sends a callback with the payment results and the success payment status. If a customer isn't charged for the initial attempt, the payment platform keeps processing the payment that may require one or more additional attempts to process it.

Until the customer is charged for one of processed additional attempts before the limit on the number of allowed attempts has been reached, the payment platform initiates a new additional attempt. If the new additional attempt doesn't require 3‑D Secure authentication, there is no need any customer and web service involvement. If the 3‑D Secure authentication is required, the payment platform sends another callback with customer redirection data and the cascading_with_redirect parameter. If the customer confirms one more additional attempt to process the payment, the payment platform keeps processing the new additional attempt with new 3‑D Secure authentication. The payment status is set to one of following ones: awaiting_3ds_result, awaiting_redirect_result or processing.

Payment processing with the enabled cascading option is completed in the same way as regular payment processing. The payment platform sends a callback with the success payment status, if the customer has been charged for one of processed additional attempts. The payment status is set to decline, if the customer hasn't been charged for one of processed additional attempts before the limit on the number of allowed attempts has been reached.

The following diagram provides the detailed picture of a one-step purchase processing with the cascade option enabled and 3‑D Secure 1 authentication included.

* ECommPay may function as a provider.

Figure: Payment processing with the cascade option enabled and 3‑D Secure 1 authentication included

  1. The payment platform performs the internal request processing and sends it to the provider.
  2. The provider processes the request and determines whether the 3‑D Secure 1 authentication is required. If it's required, the provider sends customer redirection data. If it's not required, the provider forwards the request for purchase to an issuer.
  3. The payment platform sends the message with the customer redirection data to the merchant web service.
  4. The web service interacts with the customer:
    • if the authentication is required for the first time within the payment processing, the web service redirects a customer to the authentication page.
    • If the authentication is required again, it's recommended to display card details, information about unsuccessful attempt to the customer and ask the customer to confirm one more 3‑D Secure authentication with the same card details. If the customer confirms, the web service redirects a customer to the authentication page.
  5. The authentication page is displayed to the customer.
  6. The issuer authenticates the customer.
  7. The issuer redirects the customer to the web service and sends a message with the authentication results to the web service.
  8. The preloaded page hosted on the web service is displayed to the customer.
  9. The web service sends the request for the payment completion that contains the authentication result to the URL of the ECommPay payment platform.
  10. The payment platform accepts the request.
  11. The payment platform validates and then processes the request.
  12. The payment platform sends the response with the validity check result and the request receipt acknowledgement.
  13. The payment platform performs the internal request processing and sends it to the provider.
  14. The provider processes the request. If the customer isn't charged, the provider sends information about declined payment, and then the payment platform initiates a new additional attempt to process the payment. If the customer is charged, the provider forwards the request to the issuer, and the payment platform keeps processing the payment in the same way as regular payment processing.

Callback format

In card payments, payment processing with the enabled cascading option uses the standard format for callbacks with payment results (for more information, see Callbacks), as well as standard formats for intermediate callbacks with redirection data (for more information, see 3-D Secure 1 or 3-D Secure 2). Note that unlike regular payment processing, in payment processing with the enabled cascading option, callbacks with redirection data contain the cascading_with_redirect parameter. The parameter is set to one of the following values:
  • true—It means you should ask a customer to confirm one more additional attempt to process the payment because one of previous additional attempts has required 3‑D Secure authentication.
  • false—It means you shouldn't ask a customer to confirm one more additional attempt to process the payment because non of previous additional attempts has required 3‑D Secure authentication.

The reason the payment is declined is may be specified in the message parameter of the operations object.

In the following example of callback, the cascading_with_redirect parameter is set to false, so the merchant web service isn't required to ask the customer to confirm one more additional attempts to process the payment.

Figure: Callback example

{
        "cascading_with_redirect": false,
        "payment": {
            "date": "2020-03-28T09:28:54+0000",
            "OperationFee": {
                "amount": 0,
                "currency": "USD"
            },
            "type": "purchase",
            "sum": {
                "amount": 2000,
                "currency": "USD"
            },
            "status": "awaiting 3ds result",
            "method": "card",
            "id": "1115888716",
            "description": ""
        },
        "customer": {
            "id": "11158745"
        },
        "account": {
            "number": "402691******0696",
            "type": "visa",
            "card_holder": "Jane Doe",
            "expiry_month": "11",
            "expiry_year": "2025"
        },
        "project_id": 18616,
        "operation": {
            "id": 50454000052091,
            "type": "sale",
            "status": "awaiting 3ds result",
            "date": "2020-03-28T09:28:54+0000",
            "created_date": "2020-03-28T09:28:53+0000",
            "request_id": "af5e3a32bf6f8742c9are9",
            "sum_initial": {
                "amount": 2000,
                "currency": "USD"
            },
            "sum_converted": {
                "amount": 2000,
                "currency": "USD"
            },
            "code": "9999",
            "message": "Awaiting processing",
            "eci": "07",
            "provider": {
                "id": 4164,
                "payment_id": "",
                "endpoint_id": 4184
            }
        },
        "card_type": "Visa Gold",
        "acs": {
            "pa_req": "eJxVUd85...W6ip/iPo2E=",
            "acs_url": "https://acs.bank.com/pareq",
            "md": "eyZjUtODg...IjoiIn0="
        },
        "signature": "T1e+AOko05D...KupPd7TA=="
    }