Overview

Visa Click to Pay uses multiple layers of encryption, signature validation, and secure key management to protect payment data throughout the checkout flow.

The integration uses:

• JWS signature validation,
• asymmetric encryption,
• frontend payload encryption,
• backend payload decryption,
• x-pay-token authentication,
• public/private key pairs,
• secure key storage.

These mechanisms ensure that sensitive payment information remains protected during frontend SDK interactions and backend payment processing.

Security Flow Overview

The Visa Click to Pay payment flow includes:

1. Frontend SDK initialization
2. Frontend payload encryption
3. Secure checkout processing
4. JWS signature validation
5. Backend payload decryption
6. Payment authorization processing

At no stage should raw sensitive payment information be exposed unnecessarily between frontend and backend systems.

flowchart LR

%% --- Frontend ---
subgraph FE["Frontend (Client Side)"]
    A[SDK Initialisation]
    B[Encrypt Payload]
    C[Secure Checkout Processing]
end

%% --- Backend Security ---
subgraph SEC[Backend Security Layer]
    D[Validate JWS Signature]
    E{Signature Valid?}
end

%% --- Backend Processing ---
subgraph BE[Backend Processing]
    F[Decrypt Payload]
    H[Process Payment Authorisation]
    I[Return Payment Result]
end

%% --- Failure ---
G[Reject Request]
A --> B --> C --> D --> E

E -->|Yes| F --> H --> I
E -->|No| G

%% --- Styling ---
classDef frontend fill:#E8F0FE,stroke:#1A73E8,stroke-width:1.5px;
classDef secure fill:#FCE8E6,stroke:#D93025,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 frontend;
class D secure;
class E decision;
class F,H,I backend;
class G secure;

JWS Signature Validation

Overview

After a successful frontend checkout() call, the Visa Click to Pay SDK returns a signed JWS payload.

Before processing the payload, the backend must validate the JWS signature using the Visa-provided signing public key.

Purpose

Signature validation ensures:

• the payload originated from Visa Click to Pay,
• the payload was not tampered with,
• the response can be trusted before decryption occurs.

Signature validation must occur before payload decryption.

Structure of the JWS Payload

A Visa Click to Pay JWS payload typically follows the standard JSON Web Signature compact serialization format:

header.payload.signature

The structure contains:

1. Header
   Contains the cryptographic algorithm (alg) and key identifier (kid).
2. Payload
   Contains the transaction data and payment credentials or token information.
3. Signature
   Used to verify payload integrity and authenticity.

Example JWS Header

{
  "alg": "PS256",
  "kid": "your-public-signature-key-id",
  "typ": "jose"
}

Notes

• alg defines the signing algorithm.
• kid identifies the signing key.
• typ identifies the token format.

Example Encrypted JWS Payload

{
  "protected": "eyJhbGciOiJQUzI1NiIsImtpZCI6InN...",
  "payload": "eyJkZW1udHlwZSI6ICJUVFJBT1NJR...",
  "signature": "b64url.encoded.signature.bytes"
}

Notes

The payload remains encrypted until backend-side decryption occurs using the Network International private key.

Example Decoded Payload

{
  "srcCorrelationId": "12345ab6-7890-12cd-34ef-567890abcdef",
  "dpaTransactionId": "dpa-tx-1234567890",
  "paymentInstrument": {
    "encryptedPayload": "eyJhbGciOi...[JWE-ENCRYPTED-DATA]...",
    "pan": "4111********1111",
    "expiryMonth": "12",
    "expiryYear": "2030"
  }
}

Notes

The decoded payload may contain:

• tokenized payment information,
• masked PAN values,
• transaction correlation identifiers,
• encrypted payment payload data.

Sensitive values should never be logged or exposed unnecessarily.

Payload Encryption

The Click to Pay checkout payload contains encrypted payment data.

The frontend uses Visa Click to Pay encryption keys during the checkout() flow to securely encrypt payment information before transmission.

The encrypted payload is later decrypted on the backend using Network International private keys.

Public and Private Keys

Visa Click to Pay uses asymmetric encryption with multiple key pairs.

Encryption Public Key

The frontend-side encryption public key is used during the checkout() flow.

Purpose

Used to:

• encrypt card data,
• protect checkout payloads,
• secure frontend payment interactions.

Components

The encryption configuration consists of:

• key ID,
• public key or certificate.

Notes

The public key values are retrieved from the Visa Developer Portal configuration.

Signing Public Key

The signing public key is used on the backend to validate the JWS signature returned by the Visa Click to Pay SDK.

Purpose

Used to:

• validate signed checkout responses,
• verify payload authenticity,
• confirm Visa as the payload source.

Important

The signature must be validated before decrypting the payload.

Network International Encryption Certificate

Network International generates its own RSA key pair for backend decryption operations.

Purpose

The public key is shared with Visa and used to encrypt the Click to Pay checkout payload.

The private key is securely stored on the Network International backend and used to decrypt the payload after signature validation.

Important

The private key must never be exposed to frontend applications.

x-pay-token Authentication

Visa Click to Pay integrations use x-pay-token authentication for backend communication with Visa services.

The token is generated using:

• API Key,
• shared secret.

Purpose

Used to:

• authenticate backend API calls,
• validate trusted communication,
• secure service-to-service integrations.

Notes

The shared secret and API credentials are obtained through the Visa Developer Portal.

Frontend and Backend Responsibilities

Visa Click to Pay separates responsibilities between frontend and backend systems.

Frontend Responsibilities

The frontend is responsible for:

• initializing the SDK,
• loading encryption keys,
• handling the checkout() flow,
• collecting customer interaction data,
• securely transmitting checkout responses.

Backend Responsibilities

The backend is responsible for:

• validating JWS signatures,
• decrypting payloads,
• processing payment authorization,
• handling tokenized wallet flows,
• managing 3DS processing,
• securely storing encryption materials.

Encryption Key Retrieval

Frontend integrations may retrieve encryption configuration using the following endpoint:

GET /config/configs/vctp/encryption-keys

Base URL:

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

This endpoint provides:

• payload encryption key ID,
• public encryption key values.

Required permission:

VIEW_UCTP_WALLET_CERTIFICATE

Security Best Practices

Developers integrating Visa Click to Pay should:

• validate all signed payloads,
• never expose private keys,
• securely store credentials,
• avoid logging sensitive payload data,
• use secure backend processing,
• restrict access to encryption materials,
• use HTTPS for all integrations.

Related Documentation

• Overview
• Payment Flow
• API Endpoints
• Hosted Session Integration
• Direct API Integration
• Platform & Tenant Enablement

Additional Notes

The current security implementation is based on:

• Visa Click to Pay SDK requirements,
• Visa Developer Portal key configuration,
• backend payload decryption architecture,
• frontend encryption requirements,
• internal payment processing flows.