Payments settings
The payments section defines to which account funds can be credited for the specific profile, if a default plan (subscription) should be added when a document
of this profile is signed, how payment failures are handled (dunning workflow), when a document can be canceled, limit the number or amount of transactions (risk rules)
and if there should be a transaction feedback delay (API).
Payment Branding: Name that will appear on bank statement of customer
- By default this is your company name, this can be customised (requires Professional package or higher)
Default plan: If you defined a plan and you want it to apply to this template automatically, select it here. Plans can be created via our Support.
- When a customer signs the agreement, the subscription created from this plan is added automatically
- The first execution of the subscription is the sign date + recurrence of the subscription (eg. 2 weeks, the first collection is in 2 weeks)
Failed payments: You can set up a dunning workflow to define what should happen in case a payment fails. You can define this for three major types of payment failures:
- Payments failed because of insufficient funds on the debtor's side
- Payments refused by the debtor or refunds requested by the debtor
- Payments refused by the bank for a variety of reasons (such as incorrect account number).
For more information, please read Setting up a failure managment scheme - dunning workflow.
Step strategy: This defines the step strategy for the dunning actions you defined in the Failed payments section.
- Per transaction: The dunning steps will apply to each transaction individually. For each transaction, the step count will start with step 1.
- Per document: The dunning steps will apply to all transactions for the same document. So if there are several transactions on one document, the first one that fails will trigger step 1, and the second one that fails will trigger step 2, et cetera.
- Default: Per transaction for insufficient funds and per document for refusals. We suggest using this option, as it conforms to the way people normally reason about their invoices (if I refuse I will keep on refusing, if I don’t have money on the account you can try again).
Mandate cancellation strategy: Select how open transactions are treated on cancellation:
- Default: Open transactions will become unsettled. They can be found in the Unsettled transactions using the filter: 'Never collected'
- Forbidden: The mandate can't be canceled as long as there are open transactions (not manually nor via dunning).
Risk rules: To limit your risks, you can define a maximum amount to be collected over a given period. For more information about risk rules, see the article Defining a maximum transaction amount with a risk rule.
Transaction delay:
Paid transactions are held in a pending buffer and only shown as paid in the API transaction feed after the delay (in bank working days) set here. The delay is counted from the requested collection date of the batch. Failed transactions are not delayed and are shown in the API transaction feed immediately. The user interface is not affected by this delay.
If you set the delay back to 0 and save, all paid transactions that are still in the pending buffer are released to the API transaction feed immediately. You don't have to wait until the previously configured delay has passed. If you lower the delay to a smaller number of days, the paid transactions that already passed the new delay are released during the next daily processing or when new bank feedback is received.
For more details and an example, see Bank feedback flow for SEPA Direct Debit transactions.