Click to Pay security, usage and support FAQs

Cardholders will enter their email address, which is then used to lookup if cards are available in CTP associated with that email. In future, mobile number will also be able to be used to check if there are cards in CTP associated with that mobile number. If cards are available, an OTP is sent to the cardholder, and upon successful OTP entry, the card list tray is displayed.

Cardholders may choose to be remembered on a specific device and browser where this feature is supported. When a remembered cardholder subsequently checks out with Click to Pay, their card list will be shown based on the remembered browser/device and OTP will not normally be requested.

For returning, unrecognised users, OTP will be sent by one of the brands supported by the merchant for CTP. Legacy implementations use the brand that responds with “I’ve got cards for that user” first. New implementations use the brand associated with the most recently used card, or if no cards have been used, the most recently activated card.

Yes, after successful OTP an ID token is returned, which each brand uses to identify any cards they have associated with the same user. The ID token contains details of the identifier that has been verified by the OTP step and enables each brand to tailor the display of the card list tray as needed.

Where OTP is successfully entered from the mobile channel, Visa will tailor the card list tray to return only cards which are associated with both the primary email identifier, and with the mobile identifier which was just used for the successful SMS OTP. These cards are displayed in a masked format.

Where OTP is successfully returned from the email channel, all cards associated with that email address are returned in masked format, regardless of mobile number.

When an issuer provides email and mobile numbers to CTP (i.e. in Issuer-offered CTP and Push to CTP), we require that these are either already on file with the Issuer, (and, therefore, verified by their standard methods); or verified prior to sending to CTP where the issuer allows their customer to add/ edit details in line.

For Visa-offered CTP, a cardholder activates their card for CTP directly via the destination site or merchant checkout flow, and they provide their own credentials directly.

For Issuer-offered CTP, any updates or additions to data can only be completed through the issuer’s standard channels. The same requirements for issuers to validate these changes to email and mobile apply. Edits /additions to cardholder data at destination site or at merchant checkout flow is not permitted for cards where the Issuer is participating in Issuer-offered CTP, with the exception of allowing cardholders to update shipping addresses to facilitate checkout.

For Visa-offered CTP cardholders can update email and mobile directly at the VISA CTP consumer portal.

If a new card is added to CTP using the email address of an existing cardholder, but with a new phone number, both existing and new cards will be associated with that email address. This is because legitimate cardholders may have more than one mobile number, which they use across banks and cards. CTP can support usage across all these identifiers but will limit access depending on the identifier that the cardholder verifies when accessing CTP. CTP does not (and should not) prevent a card from being activated for CTP because the cardholder chooses to use different identifiers with different banks.

However, mistakes can happen, and so it is imperative that issuers validate all identifiers before activating CTP. In addition to this, Visa also has several security features in place to mitigate any risk in the event of such mistakes. These include masking of data, requiring further cardholder challenge to prove card ownership, and tailoring of the card list tray after successful mobile SMS OTP. Further details in questions 4, 8, 9, 10 and 11.

In order to use Click to Pay to access the card list associated with an email address, a user must successfully enter a one-time passcode sent to their email address or mobile number.

If the user accesses Click to Pay by successfully completing an SMS OTP to their own mobile phone number, the card list tray will only display cards with a matching mobile number.

If the user access Click to Pay by successfully completing email OTP, the card list tray will display all cards associated with that email address, but the personal information associated with cards that have not previously completed additional verification on the device/browser, will be masked. Additional verification (e.g. CVV2 entry, 3DS or FIDO) is required before such cards can be used to complete checkout. This proves that the user has access to the card details or has been authenticated by the issuer before displaying unmasked data to the user or returning card data to the merchant.

Visa will unmask the PI data for all cards with matching PI data (e.g. same name, address, phone number, etc) in the card list tray once ownership of one card has been proven. This benefits legitimate CTP users by simplifying their experience. PI data for any cards in the card list tray which is not an exact match to the card that has been validated will not be unmasked.

Using any card within the card list tray is subject to a series of risk and security checks. When a card is selected for checkout, a series of risk-based assessments are made within CTP and Visa, to determine if a cardholder challenge is required. Visa does not disclose all of these but, for example, first-time card usage on new/ unrecognised devices will always trigger the additional cardholder verification where the validated OTP does not match the mobile number on file for the card.

The risk step-ups required can consist of CVV2 validation, FIDO authentication and/ or EMV 3DS. Visa will only share cardholder information with the merchant if the verification was completed successfully. Therefore, before a checkout payload is even created, several steps have been taken to ensure the user is the legitimate owner of that card.

In addition to the checks within CTP, PSD SCA regulation applies in Europe, so merchants often require additional issuer authentication prior to submitting a transaction for authorisation. the Issuer always has the option to request authentication for any transaction submitted without it.

If a cardholder receives an unsolicited OTP, this is not considered to create a negative impression of the CTP product. The notification alerts the cardholder that their email address may be vulnerable to misuse, which they may have been unaware of, and they can take action to secure their details.

OTP is used in the CTP proposition to provide access to the masked card list tray. As described in earlier FAQs, using any card within the card list tray to make a payment is subject to a series of risk and security checks to determine if cardholder challenge is required, such as the need for CVV2 validation, FIDO authentication and/or EMV 3DS. As per recommended best practice, where issuer verification is triggered, this should be done via the issuers app.

Often a fraudster attempts to socially engineer an OTP as the last step before conducting any fraud. In this scenario, masked card details would be obtained by other means to convince the cardholder to pass over the OTP, rather than an OTP being used to obtain masked card details to conduct social engineering.

Social engineering is a rising threat across all payment rails, and the cardholder education and awareness that issuers provide on social engineering and scams is also relevant in this scenario to combat fraudster tactics. CTP is not considered to increase the risk of social engineering to consumers within the current payments ecosystem.

Issuers should ensure cardholders are educated on phishing attacks, particularly those which attempt to steal personal or financial related information. Attack vector specific best practice guidance can be found within Visa Security Alerts, which are accessible to all clients on Visa Online.

A Click to Pay user can choose to be remembered for future transactions on a specific browser/device. To support this process, a cookie is dropped on the browser after a successful transaction where the user has completed OTP verification.

On the consumer’s next use of CTP on that browser/device (which is checked through the presence of the cookie and verification of independent device identification signals), the initial display of the card list tray will occur without the user completing another OTP.

All risk and security steps detailed elsewhere in this document related to unmasking cardholder PI data or using any cards within the card list tray would still take place.

No, the cookie is set only at the browser level (based on consumer choice to be remembered) and only gives access to the card list tray. Visa SRC system has built-in controls to prevent cookie stolen attack vectors. Visa SRCS binds any newly issued cookie for the consumer/device and will validate/renew the expiry each time its read.

No. The FIDO registration process is card specific and requires 3DS issuer authentication with cardholder challenge to complete successfully. Upon successful FIDO registration, a Cloud Token Framework device binding is created between the individual card and the device/browser. This binding is unique to that card and has no impact on any other cards in the user’s card list tray.