Mobile SDK Integration

Overview

The Mobile SDK integration allows customers to use Click to Pay within a mobile checkout experience, while the payment flow continues to rely on secure SDK interaction, backend validation, payload decryption, and payment authorization.

This integration is intended for merchants who want to offer Visa Click to Pay inside a mobile app experience.


Supported Mobile Platforms

Visa Click to Pay mobile integration may support:

  • Android
  • iOS

Implementation details may vary by platform. Final SDK-specific steps should be confirmed against the latest implementation artifacts and available SDK documentation.


Mobile SDK Approach

The current design indicates that mobile implementations may use the Visa JavaScript SDK within the mobile experience, with a bridge between the JavaScript layer and the native mobile application.

This approach allows the mobile app to:

  • initialize the Click to Pay experience,
  • collect or pass customer identification details,
  • retrieve saved cards,
  • handle authentication,
  • complete checkout,
  • pass the checkout response to backend services.

High-Level Flow

The Mobile SDK flow typically follows these steps:

  1. Customer selects Visa Click to Pay in the mobile app.

  2. Mobile app initializes the Click to Pay experience.

  3. Customer enters an email address or mobile number.

  4. Customer completes OTP verification, if required.

  5. Saved Click to Pay cards are retrieved.

  6. Customer selects a saved card or adds a new card.

  7. SDK performs checkout().

  8. Checkout response is returned to the mobile app.

  9. Mobile app sends the response to backend services.

  10. Backend validates, decrypts, and processes the payment.

  11. Payment result is returned to the mobile checkout experience.

flowchart LR

%% --- Mobile App ---
subgraph APP["Mobile App (Client)"]
    A[Select Click to Pay]
    B[Initialise SDK]
    C[Enter Email / Mobile]
    
    D{OTP Required?}
    E[Complete OTP Verification]
    
    F[Retrieve Saved Cards]
    G{Saved Card Available?}
    
    H[Select Saved Card]
    I[Add New Card]
    
    J["Execute checkout()"]
    K[Receive Checkout Response]
end

%% --- Backend ---
subgraph BE[Backend Processing]
    L[Send Response to Backend]
    M[Validate & Decrypt Payload]
    N[Process Authorisation]
    O[Return Payment Result]
end

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

D -->|Yes| E --> F
D -->|No| F

F --> G

G -->|Yes| H --> J
G -->|No| I --> J

J --> K --> L --> M --> N --> O

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

class A,B,C,E,F,H,I,J,K frontend;
class L,M,N,O backend;
class D,G decision;

Architecture Overview

The Mobile SDK integration includes:

  • mobile app checkout interface,
  • Visa Click to Pay SDK or embedded SDK layer,
  • JavaScript-to-native bridge, where required,
  • backend payment processing,
  • JWS signature validation,
  • payload decryption,
  • authorization handling.

The mobile app manages the customer experience, while backend services handle sensitive validation, decryption, and payment processing.


Customer Identification

The Click to Pay flow may require the customer to identify themselves using:

  • email address,
  • mobile number.

After the identifier is submitted, the customer may be asked to complete OTP authentication before saved cards are retrieved.


Saved Card Retrieval

After successful identification and authentication, the Click to Pay experience may return available saved cards.

The mobile app should support:

  • rendering saved cards,
  • handling empty-card states,
  • allowing customers to switch identity,
  • allowing customers to add a new card,
  • handling card selection.

New Card Flow

If no saved cards are available, or if the customer chooses to add another card, the mobile app should support a new card flow.

This may include:

  • rendering card input components,
  • collecting required card details,
  • encrypting card data,
  • calling checkout(),
  • handling the payment result.

Checkout Response Handling

After the customer completes checkout, the SDK returns a checkout response.

The mobile app should forward this response to backend services without modifying it.

The backend is responsible for:

  • validating the JWS signature,
  • decrypting the encrypted payload,
  • extracting tokenized payment data,
  • processing payment authorization,
  • handling 3DS, where required.

Payment Processing Endpoint

The backend may process the Click to Pay response using:

POST /transactions/outlets/{outletId}/orders/{orderRef}/payments/{paymentRef}/click-to-pay

Base URL:

https://api-gateway.sandbox.ngenius-payments.com

3DS Handling

If additional authentication is required, the mobile checkout experience should support 3DS handling.

The backend may return a response requiring the customer to complete authentication before authorization can continue.

The mobile app should be able to:

  • display the required authentication screen,
  • handle customer completion,
  • continue the payment flow,
  • display the final payment result.

Mobile App Responsibilities

The mobile app is responsible for:

  • rendering the Click to Pay checkout experience,
  • initializing the SDK,
  • managing customer input,
  • handling OTP flows,
  • displaying saved cards,
  • supporting new card entry,
  • forwarding checkout responses to the backend,
  • displaying payment results.

Backend Responsibilities

The backend is responsible for:

  • validating signed checkout responses,
  • decrypting payloads,
  • processing wallet token data,
  • handling authorization,
  • managing 3DS flows,
  • protecting private keys and credentials,
  • returning payment status to the mobile app.

Error Handling

Mobile SDK integrations should handle:

  • SDK initialization failures,
  • invalid customer identifiers,
  • OTP failures,
  • empty saved-card responses,
  • checkout failures,
  • backend authorization failures,
  • 3DS failures,
  • network timeouts.

Error messages should be clear to the customer but should not expose sensitive payment or security details.


Limitations and Considerations

Mobile SDK implementation may require additional platform-specific handling.

Considerations include:

  • JavaScript SDK bridge behaviour,
  • Android and iOS differences,
  • OTP handling,
  • 3DS rendering,
  • saved-card display,
  • mobile session state,
  • secure transmission between app and backend.

Final implementation details should be confirmed once SDK samples, collections, or platform-specific integration guides are available.


Related Documentation

  • Overview
  • Payment Flow
  • API Endpoints
  • Security & Encryption
  • Hosted Session Integration
  • Direct API Integration

Additional Notes

This page provides the current Mobile SDK integration guidance based on the available Visa Click to Pay feature design. Additional code samples, SDK setup steps, and platform-specific examples should be added once final implementation assets become available.

© Network International LLC. All Rights Reserved.