# Payment conditions

[Payment conditions](https://docs.tink.com/api-connectivity-v1#connectivity-v1/provider/get-payment-conditions-for-a-provider "Payment conditions API documentation") is used to evaluate submitted payments before they reach a payment provider.

Use this feature to ensure that all of your submitted payments fulfill your payment providers' requirements to avoid failed payments.

Payment conditions apply when you create a payment request to initiate a payment with Tink Link and when creating a money transfer.

A payment condition is a combination of a rule, an operator, and a value. These parameters form an evaluation condition that must be fulfilled by data that is sent to a bank, or the request will fail. The value contains the data types (string, integer, regex, list) that should be used to evaluate the condition.

## The problem that payment conditions solves

Different payment providers require different conditions to be met to accept a payment. Some examples:

- The minimum transfer amount is €1 for a specific bank.
- Payment is only allowed when the payment reference number for a transaction contains a maximum of 50 characters.
- Payment is only allowed when the recipient name contains a maximum of 70 characters.

By using payment conditions, your payments are never left to chance. Use our endpoint to evaluate that payment-provider conditions are met, in order to avoid failed payments.

## How to use payment conditions

We offer two ways to use payment conditions. We recommend that you use our endpoint when applicable.

- __Endpoint__: Use our endpoint to programmatically validate payment conditions, where applicable.
- __CSV files__: Download and use our lists to create general rules to enforce in your UI.

## UI and UX app considerations

!https://images.ctfassets.net/tmqu5vj33f7w/1kdi2RDop2uCnSaVey8PqT/d9fd414e9729b063a183e79a27f0840d/Payment_conditions.png

## Endpoint

The first image shows a scenario where an end user has selected a payment method but has not manually entered any payment data in your app or in a website.

For this scenario to work, you must programmatically populate all payment-request fields. This can be validated through our payment conditions endpoint. The only thing that remains for the end user to do, is sign the payment.

This scenario is only applicable when you know which provider the end user will select before the payment request is created. This information is determined from the PIS flow that first includes an AIS aggregation (applicable for SE, DE, IT) or by otherwise having access to this information.

### Payment conditions CSV files

We offer [CSV files](#download-payment-conditions-csv-files) as an overview markets in which payment conditions work.

Use the files to find a common denominator and set general rules to enforce in your UI (as seen in the right-hand part of the image above). For example, you can set the max remittance length or minimum payment amount to make sure that a payment is likely to succeed.

The files are intended for use when an end user enters data (for example, amount, recipient name, and remittance) in your app or on your website instead of with Tink, and when the end user's bank is unknown before a payment request is initiated.

## Rule

The rule part of the response provides some contextual information on what data the condition should be evaluated.

| Rule     | Description     |
| ---------- | ---------- |
| REMITTANCE_INFORMATION_TYPE       | Evaluation of the remittance information type. This is most often associated with the ONE_OF operator, which specifies a list of supported remittance information types. |
| REMITTANCE_INFORMATION_VALUE       | Evaluation of the remittance information for account-to-account transfer. Could be to evaluate the length of the message or allowed characters.       |
| REFERENCE_REMITTANCE_INFORMATION_VALUE       | Evaluation of the  REFERENCE remittance information for account-to-account transfer. Could be to evaluate the length of the message or allowed characters.       |
| UNSTRUCTURED_REMITTANCE_INFORMATION_VALUE       | Evaluation of the UNSTRUCTURED remittance information for account-to-account transfer. Could be to evaluate the length of the message or allowed characters.       |
| GIRO_UNSTRUCTURED_REMITTANCE_INFORMATION_VALUE       | Evaluation of the remittance information for bank and post giro specifically. Could be to evaluate the length of the message or allowed characters. __Only applicable for the Swedish market.__       |
| INTRA_BANK_TRANSFER_CUTOFF_TIME       | Evaluation of the execution date of the payment/transfer request for transfers between accounts within the same bank. For the Payment Request model, this is the executionDate. For the Transfer model, it is the dueDate.       |
| INTER_BANK_TRANSFER_CUTOFF_TIME       | Evaluation of the execution date of the payment/transfer request for transfers between accounts outside of the source bank. For the Payment Request model, this is the executionDate. For the Transfer model, this is the dueDate.       |
| GIRO_CUTOFF_TIME       | Evaluation of the execution date of the payment/transfer request for payments with bank or post giro. __Only applicable for the Swedish market.__       |
| SOURCE_MESSAGE       | Evaluation of the source message (the message shown on the user's transaction). Could be to evaluate the length of the message or allowed characters.       |
| RECIPIENT_NAME_VALUE       | Evaluation of the recipient name. This is to evaluate the length of the name.       |
| SOURCE_ACCOUNT_REQUIRED_BEFORE_REDIRECT       | Evaluation of the bank's ability to provide account selection within a redirect as controlled by the specific bank, or if source accounts have to be aggregated separately.       |
| SOURCE_ACCOUNT_PROVIDED_SKIPS_AIS       | Evaluation of the ability of the bank to skip the AIS SCA if the source account is provided on every journey.       |
| RECURRING_PAYMENT_ALLOWED_FREQUENCY       | Evaluation of the recurring payment frequency. Will most often be associated with the ONE_OF operator, which specifies a list of supported frequencies |
| RECURRING_PAYMENT_ALLOWED_PAYMENT_SCHEME       | Evaluating the payment scheme of the recurring payment. Will most often be associated with the ONE_OF operator, which specifies a list of supported payment schemes. |
| END_DATE_REQUIRED_FOR_RECURRING_PAYMENT       | Evaluating the requirement of providing end date for the recurring payment. If it is not required, not supplying it will result in infinite recurring payment. |
| RECURRING_PAYMENT_ALLOWED_EXECUTION_RULE       | Evaluating the execution rule of the recurring payment. Will most often be associated with the ONE_OF operator, which specifies a list of supported execution rules. UNSPECIFIED value means it is optional for recurring payment. |
| RECURRING_PAYMENT_FIRST_PAYMENT_DATE_<br>MIN_DAYS_FROM_TODAY       | Evaluating the first payment date of recurring payment. First payment date must be at least the minimal number of days from today. |
| RECURRING_PAYMENT_FIRST_PAYMENT_DATE_<br>MAX_DAYS_FROM_TODAY       | Evaluating the first payment date of recurring payment. First payment date cannot be more than the maximum number of days from today. |
| SEPA_PAYMENT_AMOUNT       | Evaluating amount in case of "paymentScheme": "SEPA_CREDIT_TRANSFER" |
| SEPA_INSTANT_PAYMENT_AMOUNT       | Evaluating amount in case of "paymentScheme": "SEPA_INSTANT_CREDIT_TRANSFER" |
| MULTIBANCO_PAYMENT_REFERENCE       | Evaluating length of payment reference in case of service-payments, special-service-payments and public-sector-payments. __Only applicable for Multibanco in Portugal.__ |
| MULTIBANCO_PAYMENT_ENTITY       | Evaluating length of payment entity. __Only applicable for Multibanco in Portugal.__ |
| FUTURE_PAYMENT_DATE       | Evaluating the requirement for future date payment if the specific provider has a maximum execution date, if payment is scheduled outside of this period it will fail. Is to be associated with the MAX_DAYS_AFTER operator. |
| BULK_PAYMENT_MAX_TOTAL_AMOUNT       | Evaluating total amount for all payments within a bulk. |
| BULK_PAYMENT_MAX_PAYMENTS       | Evaluating number of payments within a bulk. |

## Operator

The operator specifies how the evaluation should be performed.

| Operator     | Description     |
| ---------- | ---------- |
| EQUALS       | A simple equals comparison between the values.       |
| MATCHES       | A regular expression evaluation of the data.       |
| ONE_OF       | A list of possible valid values to evaluate against.       |
| LENGTH_MIN       | The minimum length of a value.       |
| LENGTH_MAX       | The maximum length of a value.       |
| REQUIRED       | Given value is required.       |
| MIN_DAYS_AFTER       | Minimal number of days after date.      |
| MAX_DAYS_AFTER       | Maximum number of days after date.       |
| MINIMUM       | Minimum value for the field.       |
| MAXIMUM       | Maximum value for the field.       |

## Value

The value of a condition is the data that should be used as the counterpart of the input to perform the evaluation.

The value can be of different data types depending on the combination of rule and operator. For example a `ONE_OF` condition would have an array of values to choose from.

## Examples

Calling the payment conditions endpoint with `GET /api/v1/payments/providers/{name}/payment-conditions` will give you the response as follows.

### Response

```json
{
 "conditions": [
   {
     "rule": "REMITTANCE_INFORMATION_TYPE",
     "operator": "ONE_OF",
     "value": [
       "OCR",
       "UNSTRUCTURED"
     ]
   },
   {
     "rule": "REMITTANCE_INFORMATION_BANK_TRANSFER_VALUE",
     "operator": "LENGTH_MAX",
     "value": 12
   },
   {
     "rule": "GIRO_UNSTRUCTURED_REMITTANCE_INFORMATION_VALUE",
     "operator": "LENGTH_MAX",
     "value": 18
   },
   {
     "rule": "INTER_BANK_TRANSFER_CUTOFF_TIME",
     "operator": "EQUALS",
     "value": "12:45"
   },
   {
     "rule": "INTRA_BANK_TRANSFER_CUTOFF_TIME",
     "operator": "EQUALS",
     "value": "immediate"
   },
   {
     "rule": "GIRO_CUTOFF_TIME",
     "operator": "EQUALS",
     "value": "9:45"
   },
   {
     "rule": "SOURCE_ACCOUNT_REQUIRED_BEFORE_REDIRECT",
     "operator": "EQUALS",
     "value": true
   }
 ],
 "providerId": "nordea-bankid"
}
```

### Parsing a rule example

Let's take a look at this condition:
```json
{
  "rule": "REMITTANCE_INFORMATION_TYPE",
  "operator": "ONE_OF",
  "value": [
    "OCR",
    "UNSTRUCTURED"
  ]
}
```

In the payment request for this provider, the [`remittanceInformation.type`](https://docs.tink.com/api#payment/payment-request/the-payment-request-model/remittanceinformation) should be evaluated for correctness in accordance to the list specified in `value`.

In Java, that would look something like this:

```java
List<String> providerSupportedRemittanceInfoTypes = condition.getValue();
if (!providerSupportedRemittanceInfoTypes.contains(
        paymentRequest.getRemittanceInformation().getType())) {
    // Propagate relevant error upwards
}
```

This feature can also be used preemptively by using the conditions to do input validation. For example a `LENGTH_MAX` `REMITTANCE_INFORMATION_VALUE` condition could be used to set the maximum allowed characters for the `remittanceInformation` input field.

### Download payment conditions CSV files

__Note__: Make sure to use the latest versions of these files as they are continuously updated by Tink to reflect possible bank-side changes. This is to ensure that you always have access to the most up-to-date and accurate data.

<br>
<div class="info yellow">
  <strong>Note:</strong> these files are updated every day.
</div>

| COUNTRIES              | CSV FILES |
| ---------------------- | --------- |
| France (FR)            | [Download](https://d2bt5tz6u3gd01.cloudfront.net/payment_conditions_fr.csv) | 
| Germany (DE)           | [Download](https://d2bt5tz6u3gd01.cloudfront.net/payment_conditions_de.csv) | 
| Ireland (IE)             | [Download](https://d2bt5tz6u3gd01.cloudfront.net/payment_conditions_ie.csv) | 
| Italy (IT)             | [Download](https://d2bt5tz6u3gd01.cloudfront.net/payment_conditions_it.csv) | 
| Portugal (PT)          | [Download](https://d2bt5tz6u3gd01.cloudfront.net/payment_conditions_pt.csv) | 
| Spain (ES)             | [Download](https://d2bt5tz6u3gd01.cloudfront.net/payment_conditions_es.csv) | 
| Sweden (SE)            | [Download](https://d2bt5tz6u3gd01.cloudfront.net/payment_conditions_se.csv) | 
| United Kingdom (GB)    | [Download](https://d2bt5tz6u3gd01.cloudfront.net/payment_conditions_uk.csv) | 
| Finland (FI)    | [Download](https://d2bt5tz6u3gd01.cloudfront.net/payment_conditions_fi.csv) | 
| Norway (NO)     | [Download](https://d2bt5tz6u3gd01.cloudfront.net/payment_conditions_no.csv) | 
| Austria (AT)    | [Download](https://d2bt5tz6u3gd01.cloudfront.net/payment_conditions_at.csv) |  
| Estonia (EE)    | [Download](https://d2bt5tz6u3gd01.cloudfront.net/payment_conditions_ee.csv) |
| Denmark (DK)    | [Download](https://d2bt5tz6u3gd01.cloudfront.net/payment_conditions_dk.csv) |
| Netherlands (NL)    | [Download](https://d2bt5tz6u3gd01.cloudfront.net/payment_conditions_nl.csv) |
| Belgium (BE)    | [Download](https://d2bt5tz6u3gd01.cloudfront.net/payment_conditions_be.csv) |