Click To Pay

Last updated:March 03, 2025

This guide describes how the Payment is done via Click to Pay offering and describes all the Use Cases for the New Users and the Registered Users. The EMV Secure Remote Commerce (SRC) enable a common consumer e-checkout that promotes simplicity, familiarity, interoperability convenience and trust. Click to Pay is built on EMV standards and it provides the checkout experience that delivers the security, convenience, and control currently offered in the physical world. To provide Click to Pay to our customers, ACI integrated with Secure Remote Commerce Initiator (SRCi) via Mastercard.

To better understand what Click to Pay is, please read the Configuration and Integration Guides.

How it works

Prepare the checkout

Send the request parameters server-to-server to prepare the payment form.

Create the payment form(s)

Display the payment form on your checkout page and the shopper submits the payment information.

Get the payment status

Find out if the payment was successful.


1. Prepare the checkout

First, perform a server-to-server POST request to prepare the checkout with the required data, including the order type, amount and currency. The response to a successful request is a JSON string with an id, which is required in the second step to create the payment form.

For a full list of parameters that can be sent in the prepare checkout request, please see the API Reference

Please note that for a HTTP POST request all the parameters are expected to go into the message body and not into the URL.

2. Create the payment form

To create the payment form you just need to add the following lines of HTML/JavaScript to your page and populating the following variables

  • The checkout's id that you got in the response from step 1
    <script 
    	src="https://eu-test.oppwa.com/v1/paymentWidgets.js?checkoutId={checkoutId}"
    	integrity="{integrity}"
    	crossorigin="anonymous">
    </script>
    
  • The shopperResultUrl, which is the page on your site where the customer should be redirected to after the payment is processed and the brands that will be available.
    <form action="{shopperResultUrl}" class="paymentWidgets" data-brands="VISA MASTER AMEX CLICK_TO_PAY"></form>

View the customization guide for more information on customizing the payment form. Please note if you are using SAQ-A compliant credit card form click Enter button on your keyboard to execute the payment.

  • Display of multiple card forms is now supported. This feature can be used by merchants for card brand promotion and allows the merchant to group card brands across multiple forms as per the need. To put this feature at work, add any number of <form> tag elements as above. The data-brands attribute of the rendered card forms can be configured as per the merchant need.
    <form action="{shopperResultUrl}" class="paymentWidgets" data-brands="VISA"></form>
    <form action="{shopperResultUrl}" class="paymentWidgets" data-brands="AMEX MASTER DISCOVER CARTEBANCAIRE"></form>

Show all supported brands

BrandAsync / sync workflow

A checkout id expires when a payment has been finalized successfully by user, but not later than 30 minutes. Before it expires, it can be used multiple times in order to retrieve a valid payment form. This can occur for example when a user does not finish a payment and reloads the page, or uses the back button of the browser. Therefore you don't have to generate a new checkout ID in such scenarios. However be aware that such cases can generate multiple transactions in the system, for example one (or more) failed and another one successful, based on the same checkout id.


3. Get the payment status

Once the payment has been processed, the customer is redirected to your shopperResultUrl along with a GET parameter resourcePath.

Important: The baseUrl must end in a "/", e.g. "https://eu-test.oppwa.com/".

Then, to get the status of the payment, you should make a GET request to the baseUrl + resourcePath, including your authentication parameters.

Example of a resourcePath:

resourcePath=/v1/checkouts/{checkoutId}/payment

Once a status response is successful the checkout identifier can't be used anymore. In this case the Transaction Reports endpoint can be used to get the transaction status using the payment id.

IMPORTANT: A throttling rule applies for get payment status calls. Per checkout, it is allowed to send two get payment requests in a minute.

We recommend that you verify the following fields from the Payment Status response, by comparing the returned values with expected:

  • ID(s)
  • Amount
  • Currency
  • Brand
  • Type

Backoffice operations

COPYandPAY is used to securely accept the payment data. Once the payment data has been processed you can perform refunds or other backoffice operations by following our backoffice operations guide.


Use cases

New User Registration

The Shopper clicks on the 'Click to Pay' checkbox on the Card widget and completes the Payment. On the click of this checkbox, Click to Pay workflow is triggered. When the payment is confirmed, TF (Token Fetch) is created. TF retrieves the Account Data from the Scheme based on the RIRO Configuration at Administration > Processing > Click to Pay Configuration. It can be Full PAN or DPAN (for Network Tokens). Once TF is completed, actual payment transaction(PA/DB) is created which goes to the Acquirer.

How it works

Capture the Card Details

Shopper enters the Card Details and clicks 'Click to Pay' checkbox on the Card widget

Create the new 'Click to Pay' profile

The Shopper proceeds for the Checkout on the Merchant's website and opts to pay via Credit Card. They will enter their Card details and will agree to register for 'Click to Pay' using the Checkbox on the card widget. The Shopper is then directed to the Scheme's page while doing the payment where they share their information like Name, Address, Contact Number to create their Click to Pay profile. Profile gets created when the payment is completed.

Payment Response

Based on the configuration settings, Scheme returns Email ID, Mobile Number, Address of the Shopper and their masked Account details. If the Dynamic Data type settings indicate that the Scheme returns the Full Card details, then masked Credit card data is retrieved. If the Dynamic Data type settings indicate that the Scheme returns the Token details, then masked Network Token data is retrieved like Token Account Number, Expiry and Cryptogram.

Once the Token Fetch is completed and the account data is retrieved from the Scheme , actual payment is created (PA/DB) which goes to the Acquirer.

Sample request:

Returning Shopper gets recognized via Cookies

The Recognized Shopper is presented with the list of cards registered against their Click to Pay profile when they choose to pay via Credit Card. Scheme Library recognizes the Returning Shopper based on the Browser Cookies and present them the list of cards registered against their Click to Pay profile.

Payment Response

Based on the configuration settings, the Scheme returns Email ID, Mobile Number, Address of the Shopper and their masked Account details. If the Dynamic Data type settings indicate that the Scheme returns the Full Card details, then masked Credit card data is retrieved. If the Dynamic Data type settings indicate that the Scheme returns the Token details, then masked Network Token data is retrieved like Token Account Number, Expiry and Cryptogram. Once the Token Fetch is completed and the account data is retrieved from the Scheme, actual payment is created (PA/DB) which goes to the Acquirer.

Sample request:


See also


Explore More

You can switch the content of this page to learn how to use Omni Tokens as merchant tokens alongside network tokens for payments. Toggle the switch below to see detailed information and update the page content accordingly.