サンドボックスSDK環境

Use the Sandbox Environment to test and validate your Thales SDK integration.

This environment is mainly used to validate Visa CTF and DAF flows:

• Device binding (green flow and yellow flow).

• On-device authentication and signed payload generation.

• Server-side transaction creation with DAF parameters.

Configure the Thales SDK

Initialize Thales SDK with:

• Server URL

• Server certificate

• Key identifier

Get these values from your Thales delivery team.

Use the SDK variant that matches the target environment (Sandbox vs Production). Mixing variants often fails due to security checks.

Visa CTF and DAF flows in the Sandbox Environment.

How the Sandbox Environment tests work

In Production, Visa CTF and DAF typically involve:

1. Tokenization (token creation).

2. Device binding (green flow or yellow flow).

3. On-device authentication to generate a Visa signed payload.

4. Transaction creation to fetch token data and a cryptogram.

For Sandbox Environment test cases:

• Tokenization is bypassed for SDK test cases by using a pre-registered vProvisionedTokenId.

• Device binding is simulated by the Sandbox Environment when the SDK calls binding APIs.

• Transaction creation is server-side. Use the Sandbox Environment transaction scenarios (DAF test case A32).

See Sandbox environment for the backend test cases.

Test scenarios

vProvisionedTokenId is the Visa identifier for a token.

In these test cases, Thales provides a predefined vProvisionedTokenId for each scenario.

B1: Successful device binding without step-up authentication (green flow)

• vProvisionedTokenId: ctf-000000000001

• Flow: Create device binding (green flow)

Call visaCTFHelper.createBinding(...) with this vProvisionedTokenId.

Expected result: the SDK completes binding successfully without step-up authentication.

B2: Successful device binding with step-up authentication (OTP) (yellow flow)

• vProvisionedTokenId: ctf-000000000003

• Flow: Create device binding (yellow flow)

1. Start binding with visaCTFHelper.createBinding(...).

2. When the SDK returns an IDVSession, get the list of ID&V methods:

   • idvSession.getIdvMethods() (Android)

   • idvSession.idvMethods (iOS)

ID&V method list includes:

• OTP/SMS

  • id: 875053a2-365e

  • type: OTP_SMS

  • value: +336*****55

• OTP/Email

  • id: 48fd-b606-b4c

  • type: OTP_EMAIL

  • value: test***@email.com

1. Select an ID&V method:

   • idvSession.selectIdvMethod(...) (Android)

   • idvSession.selectIDVMethod(...) (iOS)

2. Activate binding with an OTP:

   • Call idvSession.activateBinding(...).

   • Use any value except 0000.

Expected result: binding completes successfully.

B3: Unsuccessful device binding due to invalid OTP

Repeat test case B2, but use OTP value 0000.

Expected result: the SDK returns an error for invalid OTP.

B4: Device binding declined by the issuer

• vProvisionedTokenId: ctf-000000000002

Call visaCTFHelper.createBinding(...).

Expected result: the SDK returns an issuer decline outcome for binding.

B5: Get Visa signed payload (transaction authentication)

• vProvisionedTokenId: ctf-000000000003

• Flow: Authenticate a transaction

Call visaCTFHelper.authenticateTransaction(...).

Expected result: the SDK returns a Visa signed payload.

B6: Delete device binding

• vProvisionedTokenId: ctf-000000000003 or ctf-000000000001

Call visaCTFHelper.removeBinding(...).

Expected result: the SDK removes the local binding for this device and token.