> For the complete documentation index, see [llms.txt](https://docs.payments.thalescloud.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.payments.thalescloud.io/merchant-tokenization/es/entornos/sandbox-environment.md). # Entorno sandbox 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.
{% hint style="warning" %} 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. {% endhint %} ### 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
SetIDUse CaseTest DataDescription
Merchant onboarding#A1Successful merchant onboardingA predefined merchant name in the list Merchant1 to Merchant10Call:
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
SetIDUse CaseTest DataDescription
Tokenization#A10Successful card tokenizationANY 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#A10aSuccessful 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#A11Tokenization 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#A12Tokenization 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#A13Tokenization 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#A14Tokenization error case - Unknown cardCard 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#A15Tokenization error case - Crypto errorANY 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#A16Tokenization error case - Unknown merchantANY Card / ANY Exp Date

invalid merchantId		Call:
1) 'POST /tokens' or 'POST /async-tokens'

Error returned:
400 - UNKNOWN_MERCHANT
Tokenization#A17Successful card tokenization with expired tokenExpireDateANY 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:

| ### 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.

| --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.payments.thalescloud.io/merchant-tokenization/es/entornos/sandbox-environment.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.