Diesen Artikel auf Deutsch lesenThe Extended Settings action can be selected in the ≡ actions menu in the settings. The Extended Settings do not need to be changed in most cases. The settings may only be changed if the effects are clear. If in doubt, Komfortkasse Support will be happy to help.
Claim bank fees
Komfortkasse can recognize in most cases when bank fees are incurred as a result of a Bank Transfer. Bank fees can arise, for example, from a paper-based transfer (e.g. payment slip in Switzerland) or from a bank transfer from a non-EU country. In such cases, the fee is usually deducted directly from the amount of the Bank Transfer, so the account will receive a reduced amount.
In this case, the order is still treated as "paid" by default. The fees incurred will therefore not be charged to the customer. This can be adjusted here. If "Claim fees" is activated and such a payment is received, it is treated as a partial payment ("underpayment"). Notifications would therefore be sent to the customer that a partial amount is still outstanding.
If Bank details for refunds are missing
If a Customer refund is to be processed and the Bank details are not known (e.g. for a cash deposit), the customer is automatically asked for the Bank details by default. This can be deactivated here. More about refunds...
Payment status for order amount 0 (or negative)
Orders with an amount of 0 or less than 0 are considered "paid" by default. This can be changed here.
Access key for automated export
A special interface can be used to automatically export internal Komfortkasse data such as fees. This can be used, for example, for automatic booking of Komfortkasse bookings at the merchant. Attention: this key can not be used for the Komfortkasse API!
Waiting period for refunds
By default, refunds are only processed after a waiting period of 5 workdays. During this period, the customer has the option to change the Bank details. If the customer confirms the Bank details as correct or enters and confirms different Bank details, the waiting period is cancelled and the refund is executed immediately.
This is only subject to refunds that are executed from an integrated account with a sufficient balance. If the refund is executed from an Own bank account (or from an integrated account without a sufficient balance), a Direct debit must be processed before the refund. In this case, the timestamp of the next possible Direct debit is used as the planned date for the refund.
Waiting period for automatic returns
If a payment is unassigned on an integrated account, it must be returned to the originator. This automatic return takes place after the waiting period set here.
Waiting period for uncovered direct debits
When a Direct debit is executed (e.g. for Komfortkasse fees or for refunds to Own Accounts), Komfortkasse can check whether the account has sufficient funds. If not, Komfortkasse can delay the Direct debit for up to 5 days until sufficient funds are available.
Selection options:
- automatic (recommended):
Komfortkasse automatically recognizes whether a Direct debit is possible despite insufficient funds and otherwise delays the Direct debit by up to 3 days. - none:
The function is deactivated, Direct debits are always executed. - 1-5 days:
Direct debits are delayed by the specified number of days if there are insufficient funds.
Show as remittee
If the specified Shop name (see Shops) does not match the name of the merchant, you can select here which name is displayed as the payee.
Show as payment reference
If the Payment information is sent to the customer by Komfortkasse, the display of the purpose of payment can be changed here.
Allow prepayment cancellation by customers
When ordering via prepayment, it often happens that customers place several orders but only actually pay for one order. Payment reminders are then sent for the other orders that are still outstanding, which often results in the customer contacting the merchant. These contacts can be reduced with Komfortkasse.
If a customer has several open orders and only pays one of them, the notification to the customer about the successful payment offers the option to cancel the other open orders if required. As a result, Payment reminders are no longer sent for the other orders.
Own Accounts: Ignore postings from
An amount can be specified here. If a posting to an Own bank account exceeds this amount, the posting is automatically ignored.
BCC customer emails to
All notifications sent to customers can optionally be sent as a copy to the merchant's E-mail address.
Switzerland: Use QR-bill
Merchants who use a switzerland account (also collective account) can switch to using the switzerland QR-bill here. Customers in Switzerland will then receive a QR-bill instead of a payment slip.
Switzerland: use QR IBAN
Merchants who have a Swiss account (including a collective account) and use the QR-bill can switch to using the QR-IBAN here. Instead of the IBAN, customers in Switzerland will then receive a QR-bill with QR-IBAN and QR reference.
Send letter in the event of an e-mail error
If an e-mail cannot be delivered, e.g. because the customer's e-mail address is invalid, it can be automatically sent to the customer as a letter. Selection options:
- All: all undeliverable e-mails are sent as letters
- All, except payment information for invoices: e-mails with payment information for orders with invoice payment are not sent as letters. Select this option if the invoice (incl. Payment information) is enclosed with the parcel shipment to the customer.
- None: no letters are sent
If e-mails with Payment information are also to be sent as letters, a payment slip can optionally be included.
Pattern for internal e-Mail addresses
A pattern (with placeholder, e.g. "*@meinshop.de") can be specified here to identify the merchant's internal e-mail addresses. No notifications are sent for internal e-mail addresses. This option can be used, for example, if a dummy e-mail address is used for orders placed by telephone.
Send letter for internal e-mails
If an e-mail matches the Pattern for internal e-mail addresses, it can optionally be sent as a letter to the customer. For selection options, see "Send letter in case of e-mail errors".
Use order number as invoice number
This option can be used to automatically create an Invoice number that is the same as the Order number for an order. This is useful, for example, if the invoice number is not available in Komfortkasse but is always the same as the Order number.
Display payment slips
When Payment information is sent to the customer by Komfortkasse, a payment slip is displayed by default (depending on the country). This can be deactivated here.
Display QR code
If Payment information is sent to the customer by Komfortkasse, a QR code for automatically executing the Bank Transfer via the banking app is displayed by default. This can be deactivated here. More about the QR code...
Add order number to subject
The order number can be automatically attached to the subject of notifications sent by Komfortkasse to the customer or merchant.
Add payment type to subject
For notifications sent by Komfortkasse to the customer or merchant, the payment type to subject of the order (Prepayment, Invoice or Cash on delivery) can be automatically attached.
Due date (Payable until) for customers e-mails
If the "Due date (Payable until)" option is active in the prepayment or invoice payment settings, the reference date for the invoice can be specified here. By default, this is the date of the order (or invoice). Alternatively, the current date can be selected as the reference date. Note: If the date of the order is selected as the reference date, the date displayed in a payment reminder may be in the past.
Disable overpayment by multiple payments
By default, Komfortkasse assigns all payments to an order that the system evaluates as suitable. This option can be used to prevent an order from being overpaid by multiple payments. So if two identical payments are received for an Order number with the matching (or too high) amount, only the first order would be assigned for payment. Further payments for the same order would always be redirected to the merchant for clarification.