Payment Data Validation

We advise our customers to follow the below recommendations when it comes to submitting the payment data to finAPI to avoid possible payment rejections at the bank.

1. API parameter purpose - Please don’t exceed 140 characters in the purpose.
   

2. Supported character set - Depending on the bank’s technology stack and other requirements, special characters in the input might lead to failed payments. We strongly urge customers to stick to the character set below. This impacts the API parameters purpose, endToEndId, counterpartName.
   
   a b c d e f g h i j k l m n o p q r s t u v w x y z
   A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
   0 1 2 3 4 5 6 7 8 9
   / - ? : ( ) . , ' +
   Space
   

   Some banks support umlauts (ä, Ä, ö, Ö, ü, Ü, ß) while some don't. The simplest solution to ensure high success rates would be to substitute umlauts with ae, AE, oe, OE, ue, UE, ss respectively.
   

3. For Qonto: The maximum allowed amount of payments is 30,000€. Payments with a larger amount will get rejected.

Bank-specific payment constraints

Starting with API V2, we provide information about constraints that only apply to certain banks in the BankInterface.paymentConstraints object which is returned by the Get a Bank and Get and search all banks services and is also contained in the Get a bank connection service response.
Please check the documentation for the available constraints.
If a constraint applies to a bank (the flag is set to true) and a payment issued for the bank doesn’t fulfill it, we will reject the payment during payment creation already, to avoid it being rejected later by the bank.
Payment constraints metadata are currently provided for SEPA and domestic money transfers.

Please check the bank’s payment constraints upfront before creating a payment, to avoid payment creation being rejected.