NEW V2.12 A new direct debit payment method for the SEPA area has been developed in Bishorn V2. Like the payment method developed a few years ago and based on the services provided by our Slimpay partner, this new in-house payment method is also based on the pending (suspense) account, meaning that the tickets may be printed before they are paid. The main difference between both methods resides in the mandate creation in case of online sales. Slimpay provides an automatic mandate creation while, with this new payment method, mandates are created outside of SecuTix (see section Solution below for more details).
Solution
Comparison of the different direct debit payment methods
The table below compares the three available direct debit payment methods:
- Bank withdrawal: the first direct debit payment method provided by SecuTix
- Slimpay direct debit: the direct debit payment method based on pending account and using Slimpay (for bank file generation and automatic mandate creation for on-line sales)
- SEPA direct debit: the new direct debit bank payment method also based on pending account
| Bank withdrawal | Slimpay direct debit | SEPA direct debit | |
|---|---|---|---|
| Installments dates | Installment must take place before the dated products it contains | No restriction | No restriction |
| Installments amounts | Amount matches the price of the included products (each installment has its own amount) | All installments have the same amount. You may define a different amount for the first one. | All installments have the same amount. You may define a different amount for the first one. |
| Tickets available before payment | No | Yes | Yes |
| Payment method available on box office | Yes | Yes | Yes |
| Payment method available on Ticket Shop | No | Yes | Yes |
| Mandate required to process payment | Yes | Yes | No |
| Mandate management from box office | Manual management | Manual management | Manual management or no management |
| Mandate management from Ticket Shop | N/A | Internet user is redirected on Slimpay page that will trigger an automatic mandate generation | Internet user enters the bank information and checks a box to give his consent for direct debit. If needed, the actual mandate must be handled outside of SecuTix. |
| Generation of bank payment file to be provided to the bank | Yes (triggered manually from a screen) | Yes (manual or automatic batch schedule) | Yes (manual or automatic batch schedule) |
| Import of payment status file provided by the bank | No. A screen allows the operator to mark each payment as succeeded or failed | Yes. The feature imports the SEPA file pain.002 that describes the failed payments only. Payments without bank feedback are considered successful 5 days after its due date. | Yes. The feature imports the camt.053 or camt.054 file belonging to the ISO20022 standard. These files contains the successful payments, not the failed ones. |
| Payment method available for EUR | Yes | Yes | Yes |
| Payment method available for £ | No | Yes | No |
| Payment method available for CHF | No | No | No but feasible since the ISO20022 standard is also used for bank transfers in CHF (would need some development) |
| Reconciliation screen comparing payment status between SecuTix and external system | No | Yes | No |
SEPA and mandates
SEPA allows to withdraw money from a bank account with or without a mandate. In absence of a mandate, the debtor will be allowed to refuse this bank withdrawal more easily and during a longer period of time. Concretely, you may have to credit a bank account several months after having performed a debit on it. As a result, establishing a signed mandate before the first bank withdrawal is a matter of financial risk, not a technical matter of failed or succeeded payments.
Which direct debit payment method should I use?
- If you want to be sure that tickets are paid before the corresponding event or visit, use the bank withdrawal payment method.
- If you want an automated mandate generation during on-line sales, use the direct debit payment method based on our Slimpay partner.
- If you want a flexible and easy to use solution, however providing a lower level of "built-in" security, use the new direct debit payment method described in the next sections.
Use of the new payment method
Getting started
You have first to create a payment method of type direct debit. This payment method will be used when performing the actual direct debit.
You have to define a payment method of type pending account with follow-up. This payment method will be used when creating the sales order.
Make sure to select Contact's mandate as the direct debit authorization type. This means that the bank information (IBAN, BIC. etc..) have to be entered in SecuTix since they aren't managed by an external system (like Slimpay).
All other parameters used to configure the installment creation process (number of installments, dates, amount) are identical to the other pending account based payment methods provided in SecuTix.
The prices are set-up exactly in the same way as before.
The price grid displays one column for each seat category for which a quota has been defined.
Setting up the price breakdown
The price breakdown uses the price components defined in the season. Please refer to Define flexible price breakdowns for the definition of the price components.
You can enter a price breakdown for each fixed price season ticket price. The definition of the price breakdown is optional.
The set-up process is exactly the same as for the other product families. You can find more detailed information on Define flexible price breakdowns.
Reporting
The sold amounts of the price components defined above (that may need to be shared among the different stakeholders) are provided by the reporting domain "Summary of fees". An example is given below:
Documents
You can display the price components on order related documents as well as on the file summary. You will find more details here.
Data migration
You can immediately start working with this new feature and create price breakdowns for fixed price season tickets. Indeed, all pricing data have been migrated to the new pricing model. The reports will only take into account the defined price breakdowns for the reservations and sales created after the definition of the price breakdown (no retroactive effect).
