> ## Documentation Index
> Fetch the complete documentation index at: https://docs.fintoc.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Test your integration
> Simulate payments to test your integration.
To confirm that your integration works correctly, simulate payments without moving any money using special values in test mode.
Test accounts let you simulate several scenarios:
* Successful and failed payments by payment method
* [Refund](/guides/payments/fintoc-collect-payments/payment-initiation-refunds) a payment
Any time you work with a test account, use test [API Keys](/guides/home/api-keys) in all API calls.
## Bank transfer payments
For bank transfer payments, in test mode you use distinct test credential to simulate the payment flow and error types for each Multi-Factor Authentication (MFA) type:
### Available MFA types
These are the different MFA that we have available within test mode:
* **Security device**: electronic device that banks give their clients to authorize transactions. They generally show a number that changes after some time.
* **Mobile application**: banks offer to authorize transactions through their mobile apps. In this case, the user must authorize the transaction from their *smartphone*. Fintoc detects that the transaction was authorized automatically.
* **SMS**: the bank sends a code (generally a numeric code) to the user's phone so that it can be used to authorize the transaction.
* **Coordinate card**: card that banks give their clients with a table with numbers. The user must insert the numbers located at the coordinates asked by the bank. You can read more about coordinate cards [here](https://es.wikipedia.org/wiki/Tarjeta_de_coordenadas).
### Test special values
Fintoc provides test special values for Chile and Mexico. Each country has its own payment authorization flow, and with Fintoc test mode you can test every authorization flow that your user might follow.
### Chile 🇨🇱
In Chile, a payment has between two to three steps depending on the bank:
1. The user logs in to their bank account.
2. In some banks and specific cases, the user needs to authorize a new contact before authorizing the payment.
3. The user authorizes the payment.
Fintoc provides test special values for each one of those steps.
#### Test credentials
You can use the following test credentials to log in to a bank account.
| Username | Password | Detail |
| :--------- | :------- | :---------------------------------------------------------------------------------------- |
| 41614850-3 | jonsnow | Use to simulate normal flows (login + payment authorization). |
| 40427672-7 | jonsnow | Use to simulate normal flows (login + payment authorization). |
| 41579263-8 | jonsnow | Use to simulate normal flows (login + payment authorization). |
| 41885440-5 | jonsnow | Pending-only: use this credential to simulate a payment that ends up in `pending` status. |
#### MFA to simulate a new contact
The user might need to add the recipient's account before confirming the transaction. If you want the widget to ask for some kind of MFA that simulates that the user needs to add the recipient account of the Checkout Session as a new contact, you should **use specific last digits for the `amount` attribute of the Checkout Session**.
For example, if you create a Checkout Session with an amount of `15001`, the user will be asked to authorize the new contact using its **Security device**. You can see the list of specific digit combinations indicating what type of MFA corresponds to which last digits of the amount and which code to introduce. Introducing a different code will result in a failure of the authorization:
| Last digits of the amount | MFA type | Example | Correct code |
| :------------------------ | :--------------------------- | :-------------- | :------------------- |
| 01 | Security device | `amount: 10701` | `0000` |
| 02 | Mobile Application - Success | `amount: 10702` | Does not apply |
| 03 | Mobile Application - Failure | `amount: 10703` | Does not apply |
| 04 | SMS | `amount: 10704` | `000000` |
| 05 | Coordinate Card | `amount: 17505` | `['00', '00', '00']` |
If the amount of the Checkout Session doesn't end with any of the previous digits, the user won't be required to complete MFA to create a new contact and will go directly to confirm the bank transfer.
#### MFA to confirm operation
To choose which authorization method to use while in test mode to confirm the payment, you need to select a specific origin bank account number during the payment flow. The test mode environment will **always** show the same accounts.
Here's a list of the test mode bank account numbers and which type of MFA corresponds to all of them, along with the correct code to enter.
| Account number | Type of MFA | Correct code |
| :------------- | :--------------------------- | :------------------- |
| 813990168 | Security device | `000000` |
| 422159212 | Mobile Application - Success | `N/A` |
| 5233137377 | Mobile Application - Failure | `N/A` |
| 5233138811 | Mobile Application - Failure | `N/A` |
| 170086177 | SMS | `0000` |
| 746326042 | Coordinate Card | `['00', '00', '00']` |
| 4420245701 | Coordinate Card | `['00', '00', '00']` |
The account `5233138811` fails with `error_reason` `new_contact_amount_limit_reached`, an amount-limit error for new contacts. See [Payment Intent Error Reason](/api/payments-api/payment-intents/payment-intent-error-reason) for the full list of reasons.
#### Simulate pending status payment
You can also simulate a pending payment status by choosing specific test origin bank accounts. This allows you to validate how your system handles transactions that are not immediately confirmed.
| Account number | Type of MFA | Correct code |
| :------------- | :------------------------------------- | :----------- |
| 512347890123 | Mobile Application - Pending → Success | `N/A` |
| 983214567890 | Mobile Application - Pending → Failure | `N/A` |
#### Simulate Alternative Payment Methods
You can test the payment flow for Alternative Payment Methods for bank transfers in Chile following the steps at the specific [guide](/guides/payments/alternative-payment-methods/alternative-payment-method-test-your-integration). The available methods are:
* Banco Estado (BotĂłn CompraquĂ)
* Banco de Chile (BotĂłn Banco de Chile)
* Banco Santander (BotĂłn Santander)
* Mach
### Mexico 🇲🇽
In Mexico, a payment has only two steps:
1. The user enters their phone number to initiate the payment.
2. The user authorizes the payment in their bank mobile application.
To simulate a successful or failed payment, you can use one of the following cellphone numbers when the widget asks you for it.
| Cellphone number | Type of MFA |
| :-------------------------------------------------------- | :--------------------------- |
| Any number except +52 2222222222. Example: +52 9876543210 | Mobile Application - Success |
| +52 2222222222 | Mobile Application - Failure |
## Card Payments
To simulate a successful or failed card payment, you can use one of the following card credentials during the payment process:
| Card Number | Expiration Date | CVV | Holder Name | 3DS Challenge Code | Final Result |
| ---------------- | :-------------- | :-- | :---------- | :----------------- | ------------------------------------ |
| 4111111111111111 | Any future date | Any | Any | - | âś… Succeeded |
| 4456524869770255 | Any future date | Any | Any | 1234 | âś… Succeeded if code is correct |
| 4574441215190335 | Any future date | Any | Any | - | ❌ Failed due to invalid credentials |
| 4349003000047015 | Any future date | Any | Any | - | ❌ Failed due to rejected transaction |
## Test webhooks
To test webhooks, you have to perform actions in test mode that send legitimate events to your endpoint. For instance, to trigger the `checkout_session.finished` event, you can use a test account that produces a successful payment.
## Test refunds
Using test mode you can simulate successful and failed refunds. The only difference with live mode is that in live mode refunds take 1 to 2 business days to process, while in test mode, depending on the refund amount, refunds are processed almost immediately.
You can use the refund amount to simulate a successful or failed refund. You can simulate a total refund creating a checkout session with the amount you want to test.
| Description | Refund amount | Details |
| -------------------------- | ---------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Successful refund | Any amount except `2222` or `3333` | When you initiate the refund, its status begins as `created`. Almost immediately, its status transitions to `in_progress` and then to `succeeded`. |
| Failed refund | `2222` CLP or MXN | When you initiate the refund, its status begins as `created`. Almost immediately, its status transitions to `in_progress` and then to `failed`. |
| Asynchronous failed refund | `3333` CLP or MXN | When you initiate the refund, its status begins as `created`. Some time later, its status transitions to `in_progress` and then 5 days later to `failed`.
You can use this case to simulate a refund you want to [cancel](/guides/payments/fintoc-collect-payments/payment-initiation-refunds#cancel-a-refund). |
**Refund webhooks**
In test mode you receive the same webhooks as you would receive in live mode.