Capabilities define specific functions of each financial provider, such as whether we need to use a custom otp process for the bank, whether the otp can be forwarded, etc.
When integrating a new financial provider, you will find specific behaviours that are particular for a given integration. Our front end is reactive to these particularities but must be defined at a financial provider level. Below you can find a list of the existing capabilities and the definition of what is enable/disable by setting up the value (boolean) as true or false.
This MUST be used accordingly to the capabilities of the financial provider. As an example, if the provider does not allow beneficiary edition and the capability is set to true, the edition of the beneficiary won't work.
- hasOwnOTP: Used to define whether we need to use a custom otp process for specific actions managed by the banking provider.
- canResendOTP: Defines whether the otp can be resent. This only applies if previous capability is true.
- canRetrievePan: Defines whether the Card provider has any endpoint to obtain the PAN of a card.
- allowSixMonthsStatements: Defines whether the user can get account statements older than 6 months.
- allowVirtualCards: Defines whether the bank has virtual cards enabled.
- allowEditBeneficiaries: Defines whether it is possible to edit the beneficiaries.
- hasSecurityQuestions: Used during the credentials creation, currently it is only used in Modulr now, since they require these procedure for card creation. (The questions and responses are sent as part of the card creation payload).
- hasPhysicalCardVerificationNumber: Defines whether the activation of a physical cards needs a verification number. It is a number of 9 digits in the back of the card.
- hasBusinessCode: Defines whether the client has business codes set up. Business codes are a set of IDs defined by the European Union that categorise the type of activity a merchant does. In Toqio we use the top level business codes defined in this page.
- hasToCreateEndUserKYC: Defines whether the client has to create a merchant into the financial provider or not. This is only available nowadays for Railsr integrations.
- canCancelAccounts: Defines whether the provider allow canceling cancel accounts.
- canRemoveAccounts: Defines whether the provider allow removing accounts.
- hasMeaWalletConfig: Defines if the provider is integrated with Mea Wallet and the necessary configuration data from for push-provisioning has been setup in the customer configuration.
- hasAccountPurposes: Defines if the provider requires the user to define, when the merchant is created, the account purposes of its use.
- hasExpectedVolume: Defines if the provider requires the user to define, when the merchant is created, the expected volume of its use.
- needAccountSignature: Defines if the provider needs Account signature during the account creation process.
- allowTodayStatement: Defines if the restriction that users can only download statements up to two days prior to today's date must be removed when setup to true. So, if true, users can download a bank statement with today as the last date.
Below you can find an example of what this looks like once defined for a given financial provider. The front end will react accordingly by showing or hiding components and forms based on the setup.
{
"hasOwnOTP": true,
"canResendOTP": true,
"canRetrievePan": true,
"allowSixMonthsStatements": false,
"allowVirtualCards": true,
"allowEditBeneficiaries": false,
"hasSecurityQuestions": true,
"hasPhysicalCardVerificationNumber": false,
"hasMeaWalletConfig": false,
"hasBusinessCode": false,
"hasToCreateEndUserKYC": false,
"canCancelAccounts": true,
"canRemoveAccounts": true,
"hasAccountPurposes": false,
"hasExpectedVolume": false,
"needAccountSignature": false
}
See here about the documentation of the endpoint you must implement https://docs.toq.io/reference/getcapabilities