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:

  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.

UsernamePassword
41614850-3jonsnow
40427672-7jonsnow
41579263-8jonsnow

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 amountMFA typeExampleCorrect code
01Security deviceamount: 107010000
02Mobile Application - Successamount: 10702Does not apply
03Mobile Application - Failureamount: 10703Does not apply
04SMSamount: 10704000000
05Coordinate Cardamount: 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 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 numberType of MFACorrect code
813990168Security device000000
422159212Mobile Application - SuccessN/A
5233137377Mobile Application - FailureN/A
170086177SMS0000
746326042Coordinate Card['00', '00', '00']
4420245701Coordinate Card['00', '00', '00']

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 numberType of MFA
Any number except +52 2222222222.
Example: +52 9876543210
Mobile Application - Success
+52 2222222222Mobile 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 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.

DescriptionRefund amountDetails
Successful refundAny amount except 2222 or 3333When you initiate the refund, its status begins as pending. Almost immediately, its status transitions to in_progress and then to succeeded.
Failed refund2222 CLP or MXNWhen you initiate the refund, its status begins as pending. Almost immediately, its status transitions to in_progress and then to failed.
Asynchronous failed refund3333 CLP or MXNWhen 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.