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 payments by country
- Payment errors due to invalid data or failed user authorization
- Refund a payment
Any time you work with a test account, use test API Keys in all API calls.
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 and we will detect 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.
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.
In Chile, a payment has between two to three steps depending on the bank:
- The user logs in to their bank account.
- In some banks and specific cases, the user needs to authorize a new contact before authorizing the payment.
- The user authorizes the payment.
Fintoc provides test special values for each one of those steps.
You can use the following test credentials to log in to a bank account.
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 Payment Intent as a new contact, you should use specific last digits for the
amount attribute of the Payment Intent.
For example, if you create a Payment Intent 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|
|02||Mobile Application - Success||Does not apply|
|03||Mobile Application - Failure||Does not apply|
If the amount of the Payment Intent doesn't end with any of the previous digits, the user won't be required MFA to create a new contact and will go directly to confirm the bank transfer.
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|
|422159212||Mobile Application - Success|
|5233137377||Mobile Application - Failure|
In Mexico, a payment has only two steps:
- The user enters their phone number to initiate the payment.
- 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|
To test webhooks, you have two options:
- Perform actions in test mode that send legitimate events to your endpoint. For instance, to trigger the
payment_intent.succeededevent, you can use a test account that produces a successful payment.
- Trigger test events from the Dashboard
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 payment intent with the amount you want to test.
|Successful refund||Any amount except ||When you initiate the refund, its status begins as |
|Failed refund||When you initiate the refund, its status begins as |
|Asynchronous failed refund||When you initiate the refund, its status begins as |
You can use this case to simulate a refund you want to cancel.
In test mode you receive the same webhooks as you would receive in live mode.
Updated about 1 month ago