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 a payment

Any time you work with a test account, use test API Keys in all API calls.

​

Bank transfer payments

For bank transfer payments, in test mode you use distinct test credentials to simulate the payment flow and error types for each Multi-Factor Authentication (MFA) type:

​

Available MFA types

These are the different MFA types 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, your customer authorizes the transaction from their smartphone. Fintoc detects the authorization automatically.
• SMS: the bank sends a code (generally numeric) to your customer’s phone, and your customer uses it to authorize the transaction.
• Coordinate card: card that banks give their clients with a table with numbers. Your customer inserts the numbers at the coordinates the bank asks for. You can read more about coordinate cards on Wikipedia.

​

Test special values

Fintoc provides test special values for Chile and Mexico. Each country has its own payment authorization flow, and Fintoc test mode lets you test every authorization flow your customer might follow.

​

Chile 🇨🇱

In Chile, a payment has two or three steps depending on the bank:

1. Your customer logs in to their bank account.
2. In some banks and specific cases, your customer authorizes a new contact before authorizing the payment.
3. Your customer 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.

​

MFA to simulate a new contact

Your customer might need to add the recipient’s account before confirming the transaction. To simulate an MFA that asks your customer to add the recipient account of the Checkout Session as a new contact, 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, your customer authorizes the new contact using their Security device. The table below lists the digit combinations, the MFA type each combination triggers, and the correct code to enter. A different code fails the authorization: If the amount of the Checkout Session doesn’t end with any of the previous digits, your customer skips MFA for creating a new contact and goes directly to confirm the bank transfer.

​

MFA to confirm operation

To choose which authorization method to use in test mode to confirm the payment, select a specific origin bank account number during the payment flow. The test mode environment always shows the same accounts. Here’s a list of the test mode bank account numbers and which type of MFA corresponds to each one, along with the correct code to enter. The account 5233138811 fails with error_reason new_contact_amount_limit_reached, an amount-limit error for new contacts. See 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 lets you validate how your system handles transactions that are not immediately confirmed.

​

Mexico 🇲🇽

In Mexico, a payment has only two steps:

1. Your customer enters their phone number to initiate the payment.
2. Your customer authorizes the payment in their bank mobile application.

To simulate a successful or failed payment, use one of the following cellphone numbers when the widget asks for it.

​

Card payments

To simulate a successful or failed card payment, use one of the following card credentials during the payment process:

​

Test webhooks

To test webhooks, perform actions in test mode that send legitimate events to your endpoint. For instance, to trigger the checkout_session.finished event, use a test account that produces a successful payment.

​

Test refunds

Test mode lets you simulate successful and failed refunds. The only difference with live mode is timing. In live mode, refunds take 1 to 2 business days to process. In test mode, Fintoc processes refunds almost immediately, depending on the refund amount. You can use the refund amount to simulate a successful or failed refund. To simulate a total refund, create a checkout session with the amount you want to test.