Payment and Subscription Intents
We provide a sandbox so that you can try the Payment Intent or Subscription Intent flow without really having to execute any real transaction, helping you integrate easily and knowing every flow that your users might follow. Using it is easy, just integrate to the product as you would normally, while using the test Secret and Public Keys instead of using the real ones.
Bank operations require the user to enter information: MFA (multi-factor authentication) to authorize operations. Every bank works differently, for example, some may ask for the MFA to add a new contact while others may not when making a bank transfer. This sandbox allows you to try every possible combination so that you can feel** the flow that your users will follow and test the integration.
Available MFA types
These are the different MFA that we have available within the sandbox:
- 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. In the sandbox, we allow you to simulate successful and failed authorizations. The failed authorization will simulate the user rejecting the transaction.
- 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.
MFA to simulate a new contact (Payments only)
For Payment Intents, the user might need to add the recipients 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 confirming the bank transfer.
MFA to confirmate operation
This step is required on every bank, so the sandbox won't allow you to skip it. For the case of Chile, you can also personalize it by choosing a specific origin bank account when the widget asks you to choose one. The sandbox environment will always show the same accounts.
Here's a list of the sandbox accounts 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'] |
default | Coordinate Card | ['00', '00', '00'] |
For the case of México, you can personalize it by choosing the cellphone number 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 |
How to create charges in Subscriptions
To make sure the end to end flow is correct, you may want to test the Charges when they are succeeded and failed. Use the amount attribute to differentiate both scenarios:
- Amounts greater than or equal to 500 results in a succeeded intent.
- Amounts less than 500 results in a failed intent.
In Sandbox mode, both scenarios have inmediate callback responses. Every charge has to be addressed to an existen subscription.
Example - Succeeded
curl --request POST \
--url https://api.fintoc.com/v1/charges \
--header 'Accept: application/json' \
--header 'Authorization: sk_test_9c8dr3ryBTx1VcJzuDgpm4H' \
--header 'Content-Type: application/json' \
--data '
{
"currency": "clp",
"subscription_id": "sub_123ad123",
"amount": 500
}
'
{
"id": "ch_e6dGMaB5UVy2QV3j",
"failure_code": null,
"created_at": "2022-07-15T19:09:51Z",
"object": "charge",
"status": "pending",
"amount": 509,
"currency": "CLP",
"metadata": {},
"subscription_id": "sub_gJYEapRyUg07yvz3"
}
Example - Failed
curl --request POST \
--url https://api.fintoc.com/v1/charges \
--header 'Accept: application/json' \
--header 'Authorization: sk_test_9c8dr3ryBTx1VcJzuDgpm4H' \
--header 'Content-Type: application/json' \
--data '
{
"currency": "clp",
"subscription_id": "sub_123ad123",
"amount": 499
}
'
{
"id": "ch_e6dGMaB5UVy2QV3j",
"failure_code": null,
"created_at": "2022-07-15T19:09:51Z",
"object": "charge",
"status": "pending",
"amount": 50,
"currency": "CLP",
"metadata": {},
"subscription_id": "sub_gJYEapRyUg07yvz3"
}
Updated 8 days ago