Payment Flow

The exact flow may vary depending on the selected integration method, but a typical Visa Click to Pay transaction includes customer identification, card retrieval, authentication, checkout response handling, and payment authorization.

High-Level Flow

A typical Visa Click to Pay payment flow includes:

The customer selects Visa Click to Pay during checkout.
The frontend initializes the Click to Pay experience.
The customer enters an email address or mobile number.
Saved cards are retrieved, where available.
The customer selects a saved card or adds a new card.
The customer completes authentication, if required.
A secure checkout response is generated.
The backend validates and processes the response.
The payment is authorized.
The payment result is returned to the checkout experience.

Flow Diagram

flowchart LR

%% --- Frontend ---
subgraph FE["Frontend (User + SDK)"]
    A[Select Click to Pay]
    B[SDK Initialises]
    C[Enter Email / Mobile]
    D[Select or Add Card]
    E["Authentication (if required)"]
end

%% --- System / Network ---
subgraph SY[Click to Pay Service]
    X[Retrieve Saved Cards]
end

%% --- Backend ---
subgraph BE["Backend (Merchant)"]
    F[Validate Response]
    G[Decrypt & Process Payment]
    H[Authorisation Complete]
    I[Return Result to Checkout]
end

%% --- Flow ---
A --> B --> C

C --> X
X --> D

D --> E --> F --> G --> H --> I

%% --- Styling ---
classDef frontend fill:#E8F0FE,stroke:#1A73E8,stroke-width:1.5px;
classDef system fill:#FFF4E5,stroke:#F9AB00,stroke-width:1.5px;
classDef backend fill:#E6F4EA,stroke:#188038,stroke-width:1.5px;

class A,B,C,D,E frontend;
class X system;
class F,G,H,I backend;

Frontend Flow

The frontend is responsible for presenting the Visa Click to Pay experience during checkout.

Depending on the integration method, the frontend may:

Display Visa Click to Pay as a payment option
Initialise the Click to Pay SDK
Collect the customer’s email address or mobile number
Retrieve available saved cards
Display eligible cards
Handle card selection
Support OTP or authentication screens
Call the checkout function
Send the checkout response to the backend for processing

The document notes that the frontend flow includes SDK initialization, card retrieval, checkout handling, OTP handling, and saved-card or add-card experiences.

flowchart TB

A[Frontend Responsibilities]

A --> B[Initialisation]
A --> C[Customer Input]
A --> D[Card Management]
A --> E[Authentication]
A --> F[Checkout Handling]

B --> B1[Initialise SDK]

C --> C1[Collect Email / Mobile]

D --> D1[Retrieve Saved Cards]
D --> D2[Display Eligible Cards]
D --> D3[Handle Card Selection]

E --> E1[Support OTP / Auth Screens]

F --> F1[Call Checkout]
F --> F2[Send Response to Backend]

%% Styling
classDef root fill:#E8F0FE,stroke:#1A73E8,stroke-width:1.5px;
classDef group fill:#F1F3F4,stroke:#5F6368,stroke-width:1px;

class A root;
class B,C,D,E,F group;

Backend Flow

The backend is responsible for securely processing the result of the frontend checkout flow.

After a successful checkout response is generated, the backend should:

Receive the checkout response from the frontend
Validate the response signature
Decrypt the encrypted payload
Extract the payment token or payment data
Determine whether wallet or card payment processing applies
Handle authentication or 3DS requirements where applicable
Submit the payment for authorization
Return the payment result to the checkout experience

The backend processing flow in the source document describes validating the checkout response signature, decrypting the encrypted payload, and using the resulting token or card data for payment processing.

flowchart LR

%% --- Input ---
A[Checkout Response Received]
subgraph SEC[Validation & Decryption]
    B[Validate Signature]
    C[Decrypt Payload]
    D[Extract Payment Data]
end

%% --- Decision ---
E{Payment Type?}

%% --- Processing Paths ---
subgraph CARD[Card Processing]
    F[Handle 3DS / Authentication]
end

subgraph WALLET[Wallet Processing]
    G[Process Wallet Payment]
end

%% --- Finalisation ---
H[Submit for Authorisation]
I[Return Payment Result]
A --> B --> C --> D --> E

E -->|Card| F --> H
E -->|Wallet| G --> H

H --> I

%% --- Styling ---
classDef input fill:#E8F0FE,stroke:#1A73E8,stroke-width:1.5px;
classDef secure fill:#FCE8E6,stroke:#D93025,stroke-width:1.5px;
classDef decision fill:#FFF4E5,stroke:#F9AB00,stroke-width:1.5px;
classDef process fill:#E6F4EA,stroke:#188038,stroke-width:1.5px;

class A input;
class B,C,D secure;
class E decision;
class F,G,H,I process;

Checkout Response Handling

After the customer completes the Visa Click to Pay checkout journey, the frontend receives a checkout response.

This response should be passed to the backend without modification.

The backend then validates and processes the response before completing the payment authorization.

For standard Click to Pay flows, the payment may be accepted using the Click to Pay payment endpoint. For direct wallet flows, the direct Click to Pay endpoint may be used.

Authentication and 3DS

Depending on the transaction, issuer, card scheme, and authentication result, additional verification may be required.

This can include:

OTP verification
Authentication challenges
3DS handling
Awaiting customer authentication
Additional payment authorization steps

The source document notes that ECI values and 3DS handling may affect whether the payment follows the normal wallet flow or requires additional authentication handling.

Payment Completion

Once the checkout response has been validated and the payment data has been processed, the payment is submitted for authorization.

The final payment result is then returned to the checkout experience so the customer can see whether the transaction was successful, declined, or requires further action.

Integration Considerations

When implementing the Visa Click to Pay payment flow, developers should consider:

Which integration method is being used
Whether the flow is hosted, embedded, direct, or mobile
Frontend SDK responsibilities
Backend validation and payload handling
Authentication and 3DS requirements
Error handling and retry behavior
Payment result messaging
Security and compliance requirements