Overview

The guidance below is based on the currently available feature design and implementation architecture.

Additional details may be added as SDK artifacts, API specifications, and production implementation guidance become available.

Frequently Asked Questions

Which integration methods are supported?

Visa Click to Pay currently supports the following integration models:

• Hosted Payment Page
• Hosted Session
• Direct API
• Mobile SDK

Each integration model provides different levels of frontend control and backend responsibility.

Does Visa Click to Pay support saved cards?

Yes.

Customers may retrieve previously enrolled Click to Pay cards after successful customer identification and authentication.

Saved cards may be retrieved using:

• email address,
• mobile number.

Availability depends on the customer’s Click to Pay enrollment status.

Is OTP authentication supported?

Yes.

Some flows may require OTP verification during customer identification or card retrieval.

Frontend integrations should support:

• OTP input,
• retry handling,
• expired OTP handling,
• customer re-authentication flows.

Does the integration support new card enrollment?

Yes.

If no saved cards are available, customers may be able to add a new card during the Click to Pay checkout flow.

The final behavior may vary depending on:

• SDK implementation,
• integration model,
• supported frontend experience.

Is 3DS supported?

Yes.

Some transactions may require additional 3DS authentication depending on:

• ECI values,
• issuer requirements,
• wallet authentication status,
• transaction risk conditions.

Backend systems may need to:

• return an await_3ds state,
• continue authorization after authentication,
• handle authentication failures.

Does the backend need to validate the JWS signature?

Yes.

The backend must validate the JWS signature before decrypting the payload.

This ensures:

• payload integrity,
• authenticity,
• trusted SDK response handling.

Does the backend decrypt the payload?

Yes.

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

Frontend applications should never have access to backend private keys.

Are private keys exposed to the frontend?

No.

Private keys must remain securely stored on backend systems only.

Only public encryption keys are exposed to frontend integrations where required.

Does the integration support tokenized wallet payments?

Yes.

Direct API integrations support tokenized wallet processing using decrypted payment token data.

The decrypted payload may include:

• token values,
• cryptograms,
• transaction identifiers,
• authentication data.

Are full API specifications currently available?

Not yet.

The current documentation is based on:

• feature design documentation,
• onboarding architecture,
• integration flows,
• implementation planning.

Additional API schemas, request examples, response models, and Postman collections may be added in future revisions.

Is Visa Click to Pay enabled automatically for all merchants?

No.

Visa Click to Pay requires:

• merchant onboarding,
• Platform-level enablement,
• Tenant-level enablement,
• required configuration and key setup.

Which environments are supported?

The current documentation references the sandbox environment:

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

Production configuration details should be confirmed during implementation and onboarding.

Current Limitations

Native mobile SDK support may vary

The current implementation design indicates that mobile integrations may rely on the Visa JavaScript SDK and mobile bridging approaches.

Platform-specific implementation behavior may differ between:

• Android,
• iOS.

Final API contracts may still evolve

Some endpoint behavior, request schemas, response fields, and HTTP methods may change during implementation finalization.

Developers should confirm final integration contracts before production deployment.

SDK implementation details may vary

Frontend implementation details may differ depending on:

• integration method,
• SDK version,
• frontend architecture,
• mobile platform handling.

Direct API integrations require advanced backend handling

Direct API integrations require merchants to handle:

• backend payload validation,
• decryption,
• token processing,
• authorization handling,
• 3DS orchestration,
• secure credential storage.

This integration model is intended for advanced implementations.

Retry behavior depends on failure type

Not all errors should be retried automatically.

For example:

• invalid signatures,
• payload decryption failures,
• malformed payloads

should not be retried using the same payload data.

Saved card availability depends on customer enrollment

Saved cards are only available if:

• the customer is enrolled in Click to Pay,
• the provided identifier matches enrolled wallet data,
• authentication succeeds.

Merchant onboarding synchronization may require updates

Merchant onboarding and update flows may depend on synchronization between:

• merchant configuration,
• onboarding services,
• Visa-side configuration.

Changes to merchant data may trigger update flows.

Some implementation assets are not yet finalized

The following assets may still be pending finalization:

• SDK implementation samples
• OpenAPI specifications
• Postman collections
• final error schemas
• production onboarding guidance
• environment-specific examples

Best Practices

Developers integrating Visa Click to Pay should:

• validate all signed payloads,
• avoid exposing sensitive payment data,
• securely store credentials and private keys,
• handle authentication failures gracefully,
• support retry and recovery flows,
• implement secure backend processing,
• confirm final API contracts before production rollout.

Related Documentation

• Overview
• Integration Options
• Payment Flow
• API Endpoints
• Security & Encryption
• Hosted Session Integration
• Direct API Integration
• Mobile SDK Integration
• Error Handling & Authentication

Additional Notes

This page reflects the currently available Visa Click to Pay implementation guidance and known considerations. Additional FAQs, implementation guidance, and finalized platform behavior may be added as the integration evolves.