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.
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.
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:
Cookie Recognition
The Shopper with an existing account with the Merchant proceeds for the Checkout on the Merchant's website. On selecting the Credit Card as the Payment Option, they get recognized by the Browser Cookies since they are the returning shopper and already registered for Click to Pay. After the successful recognition, the Shopper is presented with the list of Click to Pay- registered cards. They select a card from the list, review and make the payment.
This Use case allows the Shopper to pay without any manual card entry.
The Recognized Shopper is presented with the list of cards registered against their Click to Pay profile.
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:
Email ID Lookup
The Shopper with an existing account with the Merchant proceeds for the Checkout on the Merchant's website. On selecting the Credit Card as the Payment Option, they can enter their Email ID. If the Shopper is Registered for Click to Pay, an OTP is triggered to their Mobile Number/Email address. After the successful recognition, the Shopper is presented with the list of Click to Pay- registered cards. They select a card from the list, review and make the payment. This Use case allows the Shopper to pay without any manual card entry.
Shopper opts to pay via Credit Card and they enter their Email Address. the Scheme Library gets called to check if that email is enrolled for Click to Pay. If the email address is registered for Click to Pay, Shopper is requested to enter an OTP triggered on their phone/email. Once the authentication is successful, shopper is presented with the list of cards against their registered Click to Pay profile.
Transactions:
1. Email ID lookup
To check if the email provided by the Shopper is registered for Click to Pay, the Scheme Library is called. If the profile is found, OTP authentication is triggered which when successful, returns the Card list registered against that 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.
The response will include a token transaction history, indicating that the network token provisioning process
has started with the card network. Due to a simulated 2-second delay in the test environment, the network token provisioning
request will be in flight, and the payment will continue using the original PAN upon detokenizing the omni token.
The network token fetching is attempted, but the response will indicate that the provisioning request is still in progress.
Sample request:
CIT payment with network token
A shopper returns on the merchant’s website (card is already tokenized). Network token is provisioned and active for payment.
An unscheduled purchase with the saved token is performed. A cardholder initiated (CIT) payment is then authorized with the
active network token if the acquirer supports it.
Send the payment request using the stored merchant token (shopper is present).
Transactions:
1. Send payment initiated by the cardholder
To send a payment initiated by the cardholder, perform a server-to-server POST request using the stored
merchant token with all required payment and customer data, including payment type, amount, and currency.
Payment response
The response will include a token transaction history, indicating that an attempt was made to fetch the network
token from the card network. If no network token is active for payments, the payment authorization will proceed
using the real card data.
When the network token is fetched, the response will also provide the original PAN BIN. This information will be
exposed in the payment response as part of the card.bin parameter. It’s important to note that the
network token BIN is different from the original PAN BIN. This distinction is crucial for post-authorization
issuer BIN management, ensuring that you have the necessary details to handle the transaction accurately.
Sample request:
MIT payment with network token
A merchant initiated (MIT) payment is submitted based on the available card-on-file agreement with the shopper.
Card is already tokenized. Network token is provisioned and active for payment. MIT payment is authorized with the network token
if the acquirer supports it.
Send the payment request using the stored merchant token (shopper is not present).
Transactions:
1. Send payment initiated by the merchant
To send a payment initiated by the merchant, perform a server-to-server POST request using the stored merchant
token with all required payment and customer data, including payment type, amount, and currency.
Payment response
The response will include a token transaction history, indicating that an attempt was made to fetch the network
token from the card network. If no network token is active for payments, the payment authorization will proceed
using the real card data.
When the network token is fetched, the response will also provide the original PAN BIN. This information will
be exposed in the payment response as part of the card.bin parameter. It’s important to note that the
network token BIN is different from the original PAN BIN. This distinction is crucial for post-authorization issuer
BIN management, ensuring that you have the necessary details to handle the transaction accurately.
Sample request:
Payment with your network token
The merchant has its own Token Service Provider (TSP) and wants to submit payments with its existing network token authorization data.
The merchant provides all the required network token data including dynamic cryptographic data when necessary. The payment is authorized
with the network token if the acquirer supports it.
Send the payment request using the network token and cryptographic data as received from your Token Service Provider.
Transactions:
1. Send payment using your network token
To send a payment using your network token, perform a server-to-server POST request with your available network
token and the required payment and customer data, including payment type, amount, and currency.
Using tokenAccount.* data parameters
When provisioning network tokens and obtaining cryptograms through your own Token Service Provider (TSP),
you can pass the network token authorization data points in the request using the tokenAccount.*
data parameters. This ensures that all necessary information is included for the network token authorization.
Sample request:
One-Time Payment
The merchant collects card data from shopper and initiates the one-time payment. In the background, a network token is
being provisioned by the card network with Issuer involved in the token approval process. The payment is authorized with real card data
or with the network token if available and active.
Send the one-time payment request with the collected card data.
Transactions:
1. Send one-time payment
To send a one-time payment, perform a server-to-server POST request with all the required payment and customer
data, including payment type, amount, and currency.
Payment response
The response will include a token transaction history, indicating that an attempt was made to fetch the network
token from the card network. If no network token is active for payments, the payment authorization will proceed
using the real card data.
When the network token is fetched, the response will also provide the original PAN BIN. This information will
be exposed in the payment response as part of the card.bin parameter. It’s important to note that the
network token BIN is different from the original PAN BIN. This distinction is crucial for post-authorization issuer
BIN management, ensuring that you have the necessary details to handle the transaction accurately.
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.
