サンドボックス環境

Use the Sandbox Environment to test and validate your Thales API integration during the project. You can also use the Sandbox Environment anytime to reproduce Merchant Tokenization use cases.

Set up the configuration (URL, certificate, API keys, and so on) before connecting to the Sandbox Environment.

Example Sandbox Environment configuration.

How does it work ?

Merchant onboarding

The Sandbox Environment accepts 10 predefined merchant names during onboarding: Merchant1, Merchant2, Merchant3, ..., Merchant10.

Tokenization

You can use any PAN starting with a BIN that belongs to the payment network BIN ranges. The BIN ranges match the Production Environment. See the list below.

Mastercard BIN	Visa BIN	Amex BIN
start : 22200000 end : 27299999	start : 40000000 end : 40117799	start : 340000 end : 349999
start : 50000000 end : 50599999	start : 40118000 end : 43127399	start : 370000 end : 379999
start : 50700000 end : 50899999	start : 43127500 end : 43893499
start : 51000000 end : 59999999	start : 43893600 end : 45141599
start : 60000000 end : 62699999	start : 45141700 end : 45739299
start : 62800000 end : 63599999	start : 45739400 end : 45763099
start : 63700000 end : 64999999	start : 45763300 end : 49999999
start : 65200000 end : 65499999
start : 65600000 end : 69999999
start : 97500000 end : 97599999

Use a PAN that passes the Luhn check, except when the Test Data column explicitly says otherwise.

The year in the card expiry date selects the test case to run: [XXYY]. XX can be any value. YY is the test case number.

Limitations:

• The Get token use case is not available in the Sandbox Environment.

• The Sandbox Environment always returns a different tokenId in response to a Tokenization request. This differs from some payment networks, which may reuse the same tokenId depending on the inputs.

Token life cycle management (LCM)

The Sandbox Environment lets you trigger notifications sent from the TSP by setting a specific year value in the card expiry date.

Transaction

The token PAN returned in the Create transaction response is a random number starting with a predefined token BIN (see the table below).

Payment network	Token BIN
Mastercard	512345
Visa	462294
Amex	371732

The token PAN has the same length as the card PAN and passes the Luhn check. The token BINs are valid payment network token BINs. The cryptogram is hardcoded to a fixed value and uses the same format as in the Production Environment. This lets you simulate a payment in your payment test environment.

Simulating payment transactions is out of scope for the Thales Sandbox Environment. Thales platform does not process payment transactions or authorization messages.

The Sandbox Environment also supports a user-defined token value. In Create token, set encryptedData.accountId to specify the token value and token expiry date returned in the Create transaction response. The token value must be 15 to 19 digits. The token expiry date must be 4 digits.

Example: encryptedData.accountId = 1234567890123456-1025

If accountId is missing, empty, or not in this format, the Sandbox Environment generates the token.

Test scenarios

Merchant onboarding scenarios

Set	ID	Use Case	Test Data	Description
Merchant onboarding	#A1	Successful merchant onboarding	A predefined merchant name in the list Merchant1 to Merchant10	Call: 1) 'POST /merchants' A merchantId is returned. 2) 'PUT /merchants/{merchantId}/mastercard/secure-cof' 'PUT /merchants/{merchantId}/visa' 3) Receive a 'POST /notify-merchant-update' notification for each payment network. Use merchantId as input for the next test cases.

Tokenization scenarios

Set	ID	Use Case	Test Data	Description
Tokenization	#A10	Successful card tokenization	ANY Card / Exp Date [XX]31 merchantId from A1	Call: Synchronous Tokenization 1) 'POST /tokens' Asynchronous Tokenization 1) 'POST /async-tokens' Then 2 seconds later, the token requestor receives a successful: 2) 'POST /notify-token-creation' containing the token data. The generated token stays ACTIVE, regardless of other test cases.
Tokenization	#A10a	Successful Visa card tokenization with token (Visa Token for token)	ANY Token / Exp Date [XX]31 merchantId from A1	Call: Synchronous Tokenization 1) 'POST /tokens' encryptedData.token = <token> source = TOKEN Asynchronous Tokenization Not available. The generated token stays ACTIVE, regardless of other test cases.
Tokenization	#A11	Tokenization error case - The TSP rejects the Tokenization request because the card is not eligible.	ANY Card / Exp Date [XX]32 merchantId from A1	Call: 1) 'POST /tokens' or 'POST /async-tokens' Error returned: 400 - PAN_NOT_ELIGIBLE
Tokenization	#A12	Tokenization error case - The Issuer declines Tokenization (for example, fraud)	ANY Card / Exp Date [XX]33 merchantId from A1	Call: 1) 'POST /tokens' or 'POST /async-tokens' Error returned: 400 - ISSUER_DECLINED
Tokenization	#A13	Tokenization error case - The TSP rejects the Tokenization request because the card is not valid.	ANY Card with invalid Luhn check / ANY Exp Date merchantId from A1	Call: 1) 'POST /tokens' or 'POST /async-tokens' Error returned: 400 - INVALID_PAN_DATA
Tokenization	#A14	Tokenization error case - Unknown card	Card with a BIN outside the payment network ranges / ANY Exp Date merchantId from A1	Call: 1) 'POST /tokens' or 'POST /async-tokens' Error returned: 400 - UNKNOWN_CARD
Tokenization	#A15	Tokenization error case - Crypto error	ANY Card / ANY Exp Date, request with invalid encryption merchantId from A1	Call: 1) 'POST /tokens' or 'POST /async-tokens' Error returned: 400 - CRYPTO_ERROR
Tokenization	#A16	Tokenization error case - Unknown merchant	ANY Card / ANY Exp Date invalid merchantId	Call: 1) 'POST /tokens' or 'POST /async-tokens' Error returned: 400 - UNKNOWN_MERCHANT
Tokenization	#A17	Successful card tokenization with expired tokenExpireDate	ANY Card / Exp Date [XX]40 merchantId from A1	Call: Synchronous Tokenization 1) 'POST /tokens' Asynchronous Tokenization 1) 'POST /async-tokens' Then 2 seconds later, the token requestor receives a successful: 2) 'POST /notify-token-creation' containing the token data. Token expiry date = current month - 1 month.

LCM scenarios

Set	ID	Use Case	Test Data	Description
Delete token	#A20	Successful token deletion	tokenId from A10	Call: 1) 'DELETE /tokens/{tokenId}' with the tokenId to delete.
Lifecycle from TSP	#A22	Successful card tokenization with token update notification	ANY Card / Exp Date [XX]34 merchantId from A1	Call: Synchronous Tokenization 1) 'POST /tokens' Asynchronous Tokenization 1) 'POST /async-tokens' Then 2 seconds later, the token requestor receives a successful: 2) 'POST /notify-token-creation' containing the token data. Then 3 seconds later, the token requestor receives: 3) 'POST /notify-token-update' with tokenState='SUSPENDED' Then 3 seconds later, the token requestor receives: 4) 'POST /notify-token-update' with tokenState='ACTIVE' Then 3 seconds later, the token requestor receives: 5) 'POST /notify-token-update' with tokenState='DELETED'
Lifecycle from TSP	#A23	Successful card tokenization with card update notification	ANY Card / Exp Date [XX]35 merchantId from A1	Call: Synchronous Tokenization 1) 'POST /tokens' Asynchronous Tokenization 1) 'POST /async-tokens' Then 2 seconds later, the token requestor receives a successful: 2) 'POST /notify-token-creation' containing the token data. Then 2 seconds later, the token requestor receives: 3) 'POST /notify-token-update' with: new card last digits new card expiration date new cardDescription new termsAndConditionsUrl new privacyPolicyUrl new completeCardImageId

Transaction scenarios

Set	ID	Use Case	Test Data	Description
Transaction	#A30	Successful transaction	tokenId from A10	Call: 1) 'POST /transactions' The flow is successful. The token and cryptogram are included in the response.
Tokenization + transactions	#A31	Successful card tokenization followed by token state changes	ANY Card / Exp Date [XX]41 merchantId from A1	Call: Synchronous Tokenization 1) 'POST /tokens' Asynchronous Tokenization 1) 'POST /async-tokens' Then 2 seconds later, the token requestor receives a successful: 2) 'POST /notify-token-creation' containing the token data. 3) Initial state: the token is ACTIVE for 5 minutes. - Send 'POST /transactions'. - The flow is successful. The token and cryptogram are included in the response. 4) Token state changes from ACTIVE to SUSPENDED. It stays SUSPENDED for 5 minutes. - Send 'POST /transactions'. - Error returned: INVALID_TOKEN_STATE. 5) Token state changes from SUSPENDED to ACTIVE. It stays ACTIVE for 5 minutes, then moves to DELETED. - Send 'POST /transactions' when the state is DELETED. - Error returned: INVALID_TOKEN_STATE. Note: No notification is sent between state changes.
Transaction	#A32	Successful transaction with Visa DAF enablement	tokenId from A10	DAF enablement is part of the Visa CTF flow. It requires Thales SDK integration in the mobile application and API calls. This test validates the Create transaction call with the additional parameters required to enable DAF. Call: 1) 'POST /transactions' including the mandatory DAF parameters. Any properly formatted values are accepted. - authentication - visaSignedPayload - transactionData - device - cardholder The flow is successful. The token and cryptogram are included in the response. The isDAF indicator is present and set to true.