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 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.
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 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.
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:
- 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.
Test credentials
You can use the following test credentials to log in to a bank account.
Username | Password |
---|---|
41614850-3 | jonsnow |
40427672-7 | jonsnow |
41579263-8 | jonsnow |
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 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 |
---|---|---|---|
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 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.
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 |
170086177 | SMS | 0000 |
746326042 | Coordinate Card | ['00', '00', '00'] |
4420245701 | Coordinate Card | ['00', '00', '00'] |
Mexico 🇲🇽
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 |
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 payment_intent.succeeded
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 payment intent 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 pending . 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 pending . 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 pending . 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. |
Refund webhooks
In test mode you receive the same webhooks as you would receive in live mode.
Updated about 2 months ago