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 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 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 numberType of MFACorrect code
813990168Security device000000
422159212Mobile Application - SuccessN/A
5233137377Mobile Application - FailureN/A
170086177SMS0000
746326042Coordinate Card['00', '00', '00']
defaultCoordinate 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 numberType of MFA
Any number except +52 2222222222.
Example: +52 9876543210
Mobile Application - Success
+52 2222222222Mobile 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"
}