Visa Click to Pay

If CVV2 is provided, Visa Click to Pay sets the card verification status to VERIFIED, enabling frictionless checkout on first use.

10. Card verification status is set to UNVERIFIED

If CVV2 is not provided, Visa Click to Pay sets the card verification status to UNVERIFIED, requiring step‑up authentication at first use.

11. Enrollment response is returned

• If enrollment is successful, Visa Click to Pay returns a 200 OK response with srcDigitalCardId, masked card details, and a correlation identifier.
• If enrollment fails, a 4xx or 5xx error response is returned with an error code and description.

12. SRCi displays the enrollment result

The SRCi displays the enrollment result (success or failure) to the cardholder.

Endpoint Name: Enroll Card

Method: POST

Endpoint: /cards

Refer to the API specifications for the complete request and response and any additional details.

Identity Lookup enables SRCis to determine whether the provided consumer identity (email address or mobile phone number) exists within Visa Click to Pay. SRCis (Non-Payment SRCi or Payment SRCi) or an SRCi Enabler may use Identity Lookup.

Workflow:

1. Consumer enters identity

The consumer enters an identity (email address or mobile phone number) and provides it to the SRC Initiator (SRCi).

2. SRCi sends Identity Lookup request

The SRCi calls the Identity Lookup endpoint (POST /identities/lookup) using the provided consumerIdentity and srcClientId.

3. Visa Click to Pay searches for the identity

Visa Click to Pay searches for the provided consumerIdentity in the Visa Click to Pay system.

• If the identity is recognized, the response includes "consumerPresent1": true and may include consumerStatus, lastUsedCardTimestamp, and idLookupSessionId (when applicable).
• If the identity is not recognized, the response indicates "consumerPresent1": false.

5. SRCi processes the response

The SRCi uses the lookup result to determine next steps, such as whether to proceed with enrollment or continue with another Visa Click to Pay flow.

6. SRCi displays the result to the consumer

The SRCi displays the lookup outcome to the consumer (recognized or not recognized, and any applicable status).

This information enables SRCis to determine next steps, such as whether to proceed with enrollment, retrieve cards associated with the identity, or initiate any other Visa Click to Pay flows.

Endpoint Name: Identity Lookup

Method: POST

Endpoint: /identities/lookup

Refer to the API specifications for the complete request and response and any additional details.

With the Identity Validation endpoints, you can initiate validation of a claimed consumer identity (email address or mobile phone number) to determine whether that consumer has access to the identity claimed. An SRCi (Payment SRCi or Non-Payment SRCi) or an SRCi Enabler may perform Identity Validation. Identity Validation must be completed before an SRCi or SRCi Enabler may call the Profile Retrieval endpoints.

With express written approval from Visa, an SRCi or SRCi Enabler may use its own identity validation solution to complete consumer identity validation. In this event, the steps below are not applicable.

Identity validation is a two-step process through which Visa Click to Pay confirms that the consumer has access to the identity they have provided. After successful validation, Visa Click to Pay issues a Federated ID Token (idToken), a digitally-signed JWT that attests that a consumer has been successfully verified by an SRC system. The Federated ID Token contains consumer identities that allow other SRC systems to identity the corresponding SRC profile, has an expiration period of 8 minutes, and may be used across multiple API calls within a session.

• returned "consumerpresent1": true, AND
• contains the most recently used card (lastUsedCardTimestamp).

If no SRC system responds with lastUsedCardTimestamp, the SRCi must choose the SRC system that responded first.

SRCis initiate identity validation by requesting Visa Click to Pay to send a One-Time Passcode (OTP) to the consumer. The Visa SRC system generates an OTP and delivers it via email and/or SMS.

• Identity Lookup has completed successfully
• Consumer found in Visa SRC system ("consumerPresent1": true)
• idLookupSessionId available

Workflow:

1. Send Request: SRCi calls the Initiate Validation endpoint to request Visa Click to Pay to send a One-Time Passcode (OTP) to the consumer's email address or mobile phone number.
2. System Processing: Visa Click to Pay generates the OTP and delivers it via email and/or SMS.
3. Response: If successful, the system returns:
   • idValidationSessionID - Session identifier for Step 2
   • validationChannel - Channel used to deliver the OTP (email or SMS)

    

Verify OTP and Obtain Federated ID Token (idToken).

• Consumer has received OTP via email address and/or mobile phone number
• Consumer has provided OTP code to SRCi
• idValidationSessionId available

Workflow:

1. Send Request: SRCi calls the Complete Identity Validation enrpoint, submitting the consumer's OTP along with the idValidationSessionId from Step 1.
2. System Processing: Visa Click to Pay validates the OTP and confirms the consumer controls the claimed identity.
3. Response: If valid, the system returns:

    

   • idToken (Federated ID Token)
   • consumerPresent1 and consumerStatus

    

Endpoint Name: Initiate Identity Validation

Method: POST

Endpoint: /identities/validation/initiate

Refer to the API specifications for the complete request and response and any additional details.

Endpoint Name: Complete Identity Validation

Method: POST

Endpoint: /identities/validation/complete

Refer to the API specifications for the complete request and response and any additional details.

Profile Retrieval enables retrieval of a consumer's Visa Click to Pay profile using the provided consumer identities (email address or mobile phone number) or Federated ID Token(s). The profile contains a list of masked cards and credentials associated with that identity.

Payment SRCis or Non-Payment SRCis may perform Profile Retrieval after the identity is recognized and (where required) validated so a compliant card list can be presented for card selection and proceed to checkout.

Visa supports two forms of identity evidence for Profile Retrieval:

SRCi‑Validated Identity

The SRC Initiator (SRCi) has performed consumer identity verification using its own Visa‑approved methods. In this model, the SRCi may supply consumerIdentities without a Federated ID token and Visa will return profiles accordingly. SRCis must be authorized by Visa to perform identity verification themselves.

Visa‑Validated Identity

Visa performs the consumer identity validation (e.g., OTP) and issues a Federated ID Token. In this model, the SRCi must provide the Visa‑generated ID token in the request. Consumer identity‑only retrieval is not permitted.

If both idTokens[] and consumerIdentities[] are present, the ID token takes precedence.

Workflow:

1. Send Request: The SRCi sends a POST request to the Profile Retrieval endpoint /profiles/prepare with either:
   • a Federated ID Token (idToken, SRC system generated), or
   • a consumerIdentity (validated identity used only when Visa authorizes the SRCi to perform identity validation themselves)

   A srcCorrelationId may be included to continue an existing session; otherwise, a new one is created.

2. System Processing: The Visa Click to Pay system validates the SRCi's API credentials. Based on the type of SRCi (if they are permitted with only consumerIdentity or are required to provide the idToken), Visa Click to Pay then uses the provided consumer identity information to look up and prepare the associated Visa Click to Pay profile and masked card details
   • Identity Source Selection: If idToken is present, the SRC system-verified identity is used. SRCi must be authorized to use their own validated identity if no idToken is present. Otherwise, the request is rejected.
   • Profile Retrieval: The system retrieves the consumer's Visa Click to Pay profile to include:
     • tokenization status (only tokenized cards are returned)
     • expiry check (expired cards are excluded)
     • Visa Terms of Service and Privacy Notice

   Only cards for which the consumer has accepted the Visa Terms of Service and Privacy Notice are eligible to be displayed. Cards pending acceptance will not be returned until the cosnumer completes the required acceptance flow.

3. Response (Consumer Recognized): Visa Click to Pay returns
   • the active srcCorrelationId
   • a profiles[] array containing:
     • maskedConsumer, (primary and alternate identity where applicable)
     • maskedCards[], the filtered and eligible set of cards

   If no cards meet the eligibility criteria (for example, all cards are pending terms acceptance), the reponse contains an empty card list.

Endpoint Name: Prepare SRC Profile

Method: POST

Endpoint: /profiles/prepare

Refer to the API specifications for the complete request and response and any additional details.

Use the POST /transaction/credentials endpoint to initiate and complete a checkout transaction using a consumer‑selected card. Visa Click to Pay performs a transaction risk evaluation and may require additional cardholder authentication before checkout can be finalized.

Both Payment SRCis and Non‑Payment SRCis can invoke the Checkout API. Supported payload types depend on the SRCi classification.

Payload type support

The payloadTypeIndicatorCheckout value determines the type of payload returned in the Checkout API response.

Payment SRCi supported values: FULL, PAYMENT, NON_PAYMENT, SUMMARY

Non-Payment SRCi supported values: NON_PAYMENT, SUMMARY

A Non‑Payment SRCi must not request FULL or PAYMENT payloads.

Visa Click to Pay supports two checkout transaction types. The transaction type is determined by whether the merchant requests an authenticated payload and by the outcome of CTP's risk evaluation.

1. Standard Frictionless Checkout

If the merchant does not request an authenticated payload (i.e. they choose a simpler integration without seeking liability shift) and Visa Click to Pay's risk engine does not flag the transaction as suspicious, Visa Click to Pay aims for a frictionless experience. The transaction typically does not invoke an issuer challenge by default. The card token and cryptogram are returned to the merchant for authorization (with ECI 07, no liability shift) without additional consumer steps.

2. Authenticated Checkout

If the merchant requests an authenticated checkout (signaling they want fraud liability protection on this sale) or risk evaluation determines the transaction as risky, Visa Click to Pay will attempt strong customer authentication inline during checkout. The merchant's integration passes additional data (final transaction amount, merchant ID/name, acquirer BIN, etc.) and sets payloadRequested = "AUTHENTICATED" in the Checkout API call.

Given this indication, Visa Click to Pay engages one of the issuer authentication methods before providing the payment payload:

• EMV 3-D Secure
• Issuer OTP via SMS/Email
• Issuer online banking
• CVV2
• Visa Payment Passkeys

Visa Click to Pay first checks its authentication rules:

• Are all required data fields present?
• Is the issuer supporting the auth method?
• Is the device eligible for passkeys?

If yes, Visa Click to Pay triggers that method (e.g. a 3DS challenge or a passkey prompt) within a lightbox/webview so the cardholder can verify themselves. If authentication is successful, Visa Click to Pay returns an ECI 05 (fully authenticated) token payload with cryptographic proof (e.g. a CAVV/TAVV) to the merchant. This gives the merchant fraud liability shift — any fraud chargeback would be borne by the issuer, just as with 3-D Secure.

Authentication may also be triggered explicitly by a merchant request. When initiating checkout, the SRCi sends a Checkout request that includes authentication-related data via the AuthenticationPreferences object. To request an authenticated payload, set AuthenticationPreferences.payloadRequested to AUTHENTICATED.

The AuthenticationPreferences object may also carry additional merchant- or SRCi-specific attributes that Visa can use when initiating authentication. Supported merchant and transaction details include:

• Acquirer Merchant ID – The acquirer-assigned merchant identifier
• Acquirer BIN – The acquirer BIN
• Merchant Name – The merchant name assigned by the acquirer or payment system

Risk Evaluation

Visa Click to Pay's risk engine evaluates the transaction to determine whether step-up authentication is required. The decision is based on factors such as the card, device, velocity, and region settings.

Visa Click to Pay may require one of the following authentication methods. The method is selected by Click to Pay and returned as SRCS-Hosted-authentication in the Checkout API response — the SRCi must not assume or preselect a specific method.

Click to Pay applies the following preference order when selecting an authentication method (subject to issuer support, device eligibility, and risk evaluation):

1. Visa Payment Passkey (FIDO-Based Passkey Authentication)
2. EMV 3-D Secure (3DS / Visa Secure)
3. Issuer App Authentication via CTF
4. Issuer One-Time Password (OTP) via CTF
5. CVV2 Challenge (Card Security Code Validation)

What it is: A Visa Payment Passkey (VPP) is a FIDO2-compliant passkey (platform authenticator) that binds a cryptographic key pair to the user's device and card credentials. It allows the cardholder to authenticate by simply using a biometric (fingerprint, face recognition) or device PIN, without needing a separate code or password.

How it works: If a cardholder has registered a passkey for their card (typically offered during a prior Click to Pay checkout after completing an issuer-managed authentication), Click to Pay will preferentially prompt them to confirm their identity via biometric or device unlock. The passkey (backed by Visa's FIDO authentication service) locally verifies the user and generates a cryptographic signature (e.g. a TAVV — token authentication cryptogram). Click to Pay then returns an authenticated payload to the merchant indicating successful passkey-based authentication. Visa Payment Passkey will only be supported in Checkout API if SRCI supports pre-init.

If authentication is required, Visa Click to Pay returns the authentication method as SRCS_HOSTED_AUTHENTICATION and uriData. The SRCi launches the URL in a pop-up; Visa Click to Pay will administer passkey authentication. Once the authentication is completed by the cardholder, a postMessage is delivered.

After a successful passkey authentication, Visa Click to Pay returns the authentication result to the SRCi via postMessage. The assuranceData payload identifies passkey-based verification through verificationMethod: "05":

Security & friction: Passkeys provide high security (phishing-resistant, requiring possession of the user's device plus a biometric or PIN) with very low friction. The user experience is seamless — a quick face or fingerprint scan (or phone unlock) confirms the payment, avoiding the need to re-enter codes or passwords. Passkeys offer security comparable to or better than 3DS, while being faster and more user-friendly.

What it is: 3DS ("Three-Domain Secure," branded as Visa Secure for Visa) is a classic industry-standard protocol that enables issuers to authenticate cardholders during online transactions via an additional verification step. In Visa Click to Pay, 3DS is built into the platform — if required, Click to Pay can initiate a 3DS challenge behind the scenes on the merchant's behalf, without the merchant needing a separate 3DS integration.

How it works: If triggered (e.g. by merchant request or risk rules requiring a fully authenticated transaction), Click to Pay launches a 3DS challenge — usually by redirecting the shopper to their issuer's secure page or app (an Access Control Server, ACS) within a popup (iframes are not supported). The shopper may be asked to provide a password, one-time code, or use a biometric login to verify their identity to the issuer. After successful verification, the issuer's ACS returns a cryptographic CAVV/Authentication Value confirming strong authentication, and Click to Pay returns an authenticated payment payload (with appropriate ECI flag and cryptogram) to the merchant.

After a successful 3DS challenge, Visa Click to Pay returns the authentication result to the SRCi via postMessage. The assuranceData payload includes the 3DS-specific result fields (transStatus, dsTransId, acsTransId) inside methodResults.threeDsData:

Security & friction: 3DS authentication is very secure — a multi-factor check under direct issuer control, providing fraud liability shift to the issuer — but can introduce friction if a challenge is needed. In some cases, the issuer's risk engine may allow a frictionless 3DS flow (no user action required), but if a challenge is deemed necessary (e.g. for high-value payments or regulatory SCA requirements in regions like the EU), the customer must complete the extra step (entering an OTP, password, etc.).

What it is: Issuer Online Banking Authentication (also known as issuer "app" authentication) is an issuer-driven method facilitated by the Cloud Token Framework. The issuer uses its own banking app or web portal to authenticate the cardholder (often via a push notification or in-app approval) and signals the result back to Click to Pay via VTS. This leverages token-to-device binding data to securely link the device and card, ensuring the challenge is delivered to the correct cardholder's app. This also leverages cardholder verification for certain scenarios when authentication is required and token-to-device binding already exists for the card and device combination.

How it works: If transaction risk checks or preferences call for it — and the issuer supports CTF app-based authentication — Click to Pay redirects the user to a secure URL provided by the issuer (or opens an embedded frame). Depending on the user's device and issuer capability, the issuer may launch its mobile banking app (if installed) or prompt the user with a push notification. The user approves the pending transaction (often via biometric login or confirming within the app). The issuer then confirms the authentication to Click to Pay through the CTF back-end, and the shopper is seamlessly returned to the Click to Pay checkout screen to finalize the purchase.

After a successful issuer online banking authentication, Visa Click to Pay returns the authentication result to the SRCi via postMessage. The assuranceData payload identifies issuer online banking verification through verificationType: "CARDHOLDER" and verificationMethod: "02":

Security & friction: Issuer Online Banking authentication is very secure, since it happens in the issuer's controlled environment (typically requiring the user's banking login or biometric) — effectively a "bank-grade" multi-factor verification. User experience is convenient when the user has the banking app on the same device (a tap-to-approve), but adds friction if they need to switch apps or devices. It's often considered a more secure alternative to SMS OTP in markets where bank apps are common, and provides SCA compliance in regions like Europe.

What it is: Issuer OTP authentication is a method where the card's issuer verifies the shopper by sending a one-time password (often a 6-digit code) to the cardholder's email or mobile phone on record. In Click to Pay, this is implemented through Visa's Cloud Token Framework (CTF), which leverages token-to-device binding data to coordinate OTP delivery and verification between Visa and the issuer. This also leverages cardholder verification for certain scenarios when authentication is required and token-to-device binding already exists for the card and device combination.

How it works: If Click to Pay's risk engine or the merchant's preferences indicate that step-up verification is needed — and the card's issuer supports CTF OTP — Click to Pay initiates an OTP challenge. The Checkout API response provides the URL. The user is prompted to enter the code sent by their bank via SMS or email. The code is delivered out-of-band through the issuer's systems (or via Visa on the issuer's behalf), ensuring that only the legitimate cardholder with access to the registered phone/email can complete the purchase. The user enters the OTP into the Click to Pay interface, which verifies it with the issuer via the cloud service. Upon successful entry, the cardholder's identity is confirmed and the checkout proceeds with an authenticated status.

After a successful OTP challenge, Visa Click to Pay returns the authentication result to the SRCi via postMessage. The assuranceData payload identifies issuer OTP verification through verificationMethod: "04":

Security & friction: Issuer OTP offers strong two-factor security — requiring something the user has (their phone/email) and something they know (the code). It introduces moderate friction since the customer must retrieve a code from a separate channel and type it in. Overall, OTP provides a good balance between security and usability when passkeys or 3DS challenges aren't available or necessary.

What it is: CVV2-based authentication verifies the 3-digit Card Verification Value (CVV2) printed on the card. It's essentially a "something you have" check — confirming the shopper possesses the physical card by asking for the code.

How it works: During a Click to Pay checkout, a CVV2 prompt may appear, asking the cardholder to enter their card's security code (the familiar e-commerce CVV/CVC field). The code is validated either through Visa's network (if the issuer has shared CVV validation keys with Visa for on-behalf verification) or directly by the issuer in the authorization message. A correct CVV2 entry is taken as evidence that the user has the physical card (or its details) and is likely the legitimate cardholder.

After a successful CVV2 challenge, Visa Click to Pay returns the authentication result to the SRCi via postMessage. The assuranceData payload identifies CVV2-based verification through verificationType: "CARD" and verificationMethod: "02":

Security & friction: CVV2 verification is a basic security step — less robust than the other methods (CVV2 is a static code that can be compromised along with the card number), but it does provide some assurance of card possession. Friction is low (a quick code entry). Unlike 3DS or passkeys, CVV2 is not considered fully strong authentication — it doesn't generate an authentication cryptogram or fulfill two-factor requirements — so it's typically treated as a fallback method in Click to Pay.

The DPA URL is required for hosting the authentication and providing the post message afte completion of authentication. When Visa Click to Pay requires step-up authentication, the SRCi launches the Visa-hosted B2B UX in a popup or iframe (the uriData URL returned in the Checkout response). On completion, the Visa page is on a *.visa.com origin while the merchant page is on merchant.com. Because these are different origins, the result cannot be passed by direct JavaScript access; it is returned via the window.postMessage API.

For postMessage to deliver the result securely and only to the merchant, Visa needs to know the merchant's exact origin. The merchant supplies this through dpaData.dpaUri in the /transaction/credentials Checkout request. Visa uses that value as the targetOrigin when posting the result back.

Key rule: Pass window.location.origin (scheme + host + port) as dpaData.dpaUri — never window.location.href, and never a wildcard (*).

Setting dpa.Data.dpa.Uri

Origin vs. Full URL vs. Wildcard

How Visa Returns the Result

The browser delivers the message only if the receiving window's origin exactly matches dpaData.dpaUri.

Merchant Integration Steps

Merchant Copy/Paste Example

1. Avoids broad message delivery (no * targetOrigin).
2. Restricts the result to the merchant origin only.
3. Reduces accidental data exposure.
4. Avoids leaking full page URLs (path/query/fragment).
5. Supports both popup and iframe launch models.

Merchant Checklist

• Pass dpaData.dpaUri = window.location.origin in the /transaction/credentials B2B API request payload
• Use origin only (https://merchant.com), not the full checkout URL
• Do not use window.location.href
• Do not use the wildcard origin (*) for result messaging
• Register the message listener: window.addEventListener("message", handleVisaMessage)
• Validate the Visa sender origin (*.visa.com pattern)
• Validate the message type — rely on the postMessage contracts in B2B API UX LLD — CVV, 3DS, VPPS → "Post message contracts to partner"
• Handle result statuses (success, cancel, error)

Before invoking the Checkout API, the following conditions must be met:

• The consumer has selected a payment card
• The SRCi has obtained the srcDigitalCardId
• The SRCi has obtained the srcCorrelationId

Workflow:

The following workflow describes the complete checkout sequence, from card selection through payment authorization and consumer outcome. Steps marked (conditional) apply only when step-up authentication is required.

Select card for checkout

The cardholder selects a card for checkout in the SRCi checkout experience.

Initiate Checkout

The SRCi calls the Checkout endpoint, including the selected digital card and the desired payloadTypeIndicatorCheckout value. SRCi requesting authentication includes AuthenticationPreferences.payloadRequested = AUTHENTICATED and supported merchant and transaction details include:

• Acquirer Merchant ID – The acquirer-assigned merchant identifier
• Acquirer BIN – The acquirer BIN
• Merchant Name – The merchant name assigned by the acquirer or payment system

Authentication evaluation

Visa Click to Pay evaluates the transaction for the need for authentication based on risk rules or request from SRCi. Visa Click to Pay determines whether cardholder authentication is required.

Authentication decision

• If authentication is not required, Visa Click to Pay returns the checkout response with ECI = 07.
• If authentication is required, Visa Click to Pay returns the authentication method as SRCS_HOSTED_AUTHENTICATION and uriData.

Launch authentication (conditional)

The SRCi launches the uriData URL in a popup window to initiate the step-up authentication experience.

Consumer authentication (conditional)

The consumer completes the authentication challenge in the Visa-hosted user experience using one of the following methods:

Visa Payment Passkeys

• EMV 3-D Secure
• Issuer OTP via SMS/Email
• Issuer online banking
• CVV2

Authentication result (conditional)

Visa Click to Pay returns the authentication result via postMessage, including:

• assuranceData
• ECI = 05/07, indicating a successfully authenticated transaction

The assurance data provides the details of the authentication method completed.

Complete Checkout

The SRCi resumes checkout by calling the Checkout endpoint again, including the received assuranceData.

Final checkout response

Visa Click to Pay returns the final checkout response.

Payload decision

Payload retrieval (conditional)

If a FULL payload is required, the SRCi calls the Checkout endpoint with the transaction identifier to retrieve a FULL payload.

Payment authorization

The SRCi submits the payment authorization request to the payment processor (gateway/acquirer) using the available FULL payload. The payment processor returns an authorization result.

Consumer outcome

Endpoint Name: Checkout Operation

Method: POST

Endpoint: /transaction/credentials

Refer to the API specifications for the complete request and response and any additional details.

Sample Request

Sample Response - Pending Authentication

The Payload Retrieval capability allows retrieval of payment data and payment‑related information required for payment authorization using the GET /transactions/credentials endpoint. Payload retrieval is typically performed after checkout when the checkout response does not include a FULL payload suitable for authorization, such as when a SUMMARY or NON_PAYMENT payload type is used.

Payload retrieval using GET /transactions/credentials may only be performed by a Payment SRCi. Retrieving a FULL or PAYMENT payload using this endpoint must only be done by Payment SRCis. If the SRCi is operating in a Non‑Payment SRCi role, payload retrieval must be performed by the SRCi’s payment facilitator, payment processor, or gateway (the entity responsible for transaction processing).

This capability is commonly used to obtain payment credentials required to complete authorization, including scenarios where payment data is pre‑stored or where downstream payment systems require an encrypted payload.

Use Cases:

• Card‑on‑file transactions where payment data is pre‑stored
• Retrieving payment credentials to complete checkout
• Obtaining encrypted payloads for downstream payment processing systems

Payload Types:

• FULL – Contains payment credentials and related transaction data required for authorization
• PAYMENT – Contains payment credentials required for authorization without additional consumer data

Retrieval of FULL or PAYMENT payloads using this endpoint is restricted to Payment SRCis.

Cryptogram Details:

• CARDHOLDER_AUTHENTICATION_CRYPTOGRAM
• CARD_APPLICATION_CRYPTOGRAM_LONG_FORM
• CARD_APPLICATION_CRYPTOGRAM_SHORT_FORM

An encryptedSignedPayload contains either:

• CARD_APPLICATION_CRYPTOGRAM_LONG_FORM, or
• CARD_APPLICATION_CRYPTOGRAM_SHORT_FORM

In addition, the payload may also include a CARDHOLDER_AUTHENTICATION_CRYPTOGRAM alongside the LONG or SHORT FORM cryptogram.

The payload retrieved using GET /transactions/credentials is used by the Payment SRCi (or its delegated payment processor) to submit a payment authorization request and complete transaction processing. Payload retrieval itself does not authorize a transaction; it provides the encrypted data required to do so.

Either of the following approaches will work. They differ only in how the cryptogram is delivered to the SRCI/Merchant; via a separate Get Payload API call, or inline in the Checkout API response.

Option 1: Checkout API returns a summary; cryptogram retrieved via Get Payload API

The Checkout API does not return a payload containing the cryptogram. Instead, the merchant application retrieves the cryptogram separately using the Get Payload API.

1. Merchant application calls the Checkout API (Post/src/v1/transaction/credentials) with SUMMARY indicators:

checkout.DpaTransactionOptions.payloadTypeIndicatorCheckout = "SUMMARY"

2. Merchant application calls the Get Payload API (Get/src/v1/transaction/credentials), passing:

• the same srcCorrelationId and srcClientId used in the Checkout API

• payloadTypeIndicator = "FULL"

The Get Payload API response includes the cryptogram (see Cryptogram Response by Authentication Method below).

Any subsequent get Payload API calls for the same transaction will provide a TAVV with no liability shift.

Option 2: Checkout API returns the cryptogram inline

The Checkout API itself returns the payload containing the cryptogram. No separate Get Payload API call is required.

1. Merchant application calls the Checkout API with FULL indicators: checkout.DpaTransactionOptions.payloadTypeIndicatorCheckout = " "FULL"

2. The Checkout API response includes the cryptogram (see Cryptogram Response by Authentication Method below).

Calling Get Payload API a Second Time for the Same Transaction

If the Get Payload API is called again for the same transaction — using the same srcCorrelationId and srcClientId as the Checkout API and payloadTypeIndicator = "FULL" — then regardless of which authentication method was completed earlier, Visa returns only a TAVV (Card Application Cryptogram Long Form) with ECI 07.

Cryptogram Response by Authentication Method:

The cryptogram(s) returned depend on the authentication method completed. This is identical for both options above.

· 3DS authentication completed

Both a CAVV (ECI 05) and a TAVV are returned:

· Other authentication methods (Passkeys, Issuer OTP, Issuer Online Banking)

Only a TAVV is returned, with a liability shift:

Workflow:

1. Initiate payload retrieval

   A Payment SRCi initiates payload retrieval by calling Payload Retrieval (GET /transactions/credentials), providing:

   • srcCorrelationId or srcDigitalCardId

   • payloadTypeIndicator=FULL (or PAYMENT, if applicable)

2. Validate SRCi role

   Visa Click to Pay validates that the caller is acting in the Payment SRCi role and is authorized to retrieve FULL or PAYMENT payloads.

3. Validate request parameters

   Visa Click to Pay validates the request parameters, including the transaction identifier and requested payload type.

4. Retrieve payment credentials

   Visa Click to Pay retrieves the required payment data, including the token and applicable cryptogram(s), for the identified transaction.

5. Assemble encrypted payload

Visa Click to Pay assembles the encrypted payload (encryptedPayload) containing the payment credentials and associated transaction data.

6. Return payload response

   Visa Click to Pay returns a successful response to the Payment SRCi, including:

   • encryptedPayload

   • The applicable Electronic Commerce Indicator (ECI)

7. Submit payment authorization

   The Payment SRCi submits the authorization request to the payment processor (gateway or acquirer) using the retrieved payload.

8. Receive authorization result

   The payment processor returns the authorization result (approved or declined) to the Payment SRCi.

Endpoint Name: GetPayload

Method: GET

Endpoint: /transaction/credentials

Refer to the API specifications for the complete request and response and any additional details.

The Transaction Confirmation capability is used to notify Visa Click to Pay of the final outcome of a checkout or payment authorization. Transaction Confirmation ensures that Visa Click to Pay is informed of whether a transaction was successfully authorized or declined.

Both Payment SRCis and Non‑Payment SRCis may perform Transaction Confirmation using the POST /confirmations endpoint.

Prerequisites:

• Authentication successful
• Payment facilitator or Payment SRCi has retrieved payload (see Get Payload)
• assuranceData available (if authentication was performed)

Workflow:

1. Submit authorization request

   The SRCi submits a payment authorization request to the payment processor or acquirer using the retrieved payment credentials.

2. Authorization processing

   The payment processor processes the authorization request and returns one of the following outcomes:

   • Approved – Transaction authorized

   • Declined – Transaction declined by issuer

3. Handle authorization outcome

   On approval:

   • Update order status to Confirmed
   • Send confirmation to the consumer
   • Initiate fulfillment
   • Store the transaction reference
   • Optionally proceed to account creation

   On decline:

   • Update order status to Failed
   • Notify the consumer of the decline
   • Offer retry or an alternative payment method
   • Log the failure reason for analysis

4. Notify Visa Click to Pay

   The SRCi notifies Visa Click to Pay of the checkout or payment authorization result by calling the Transaction Confirmation endpoint (POST /confirmations), including the event type and authorization outcome.

5. Confirmation response

   Visa Click to Pay records the transaction confirmation and returns a response to the SRCi.

6. Consumer notification

   The SRCi displays the final success or failure status to the consumer.

    

   Transaction Confirmation ensures Visa Click to Pay has an accurate record of the transaction outcome. This step does not authorize a transaction; it records the result of authorization processing performed by the payment processor.

Endpoint Name: Create Confirmation

Method: POST

Endpoint: /confirmations

Refer to the API specifications for the complete request and response and any additional details.