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?
The Bishorn V2 release will provide price breakdown for fixed price season tickets, including championships. Here are the main characteristics of this feature:
- The breakdown will be available for fixed price season tickets:
- Bought alone
- Bought by means of an advantage. As in the current situation, the advantage doesn't change the price of the season ticket. The advantage is mainly intended to provide a privileged sales period to a subset of your customers.
- External price components (which amount comes in addition to the catalog price) are also available
Set-up (see details in next section)
The set-up of the catalog price itself undergoes only minor changes, As in the current solution, the prices of a fixed price season ticket cannot be reused for another season ticket. This approach allows to keep a very simple way of setting-up prices. Indeed, prices can directly be set-up when creating the fixed price season ticket without having to assign explicitly a price grid to it.
Difference between calculated price and fixed price season tickets
The price of a calculated price season ticket is computed by adding the prices of the single events it contains. The season ticket itself doesn't have a price breakdown but some or all of the events contained in the season ticket may have one, including for the season ticket holder tariffs.
The price of a fixed price or championship season ticket is defined at season ticket level and doesn't depend directly on the price of the contained performances or matches. The price breakdown is (only) stored at season ticket level.
Advantage on fixed price season tickets modifying the price
Currently, advantages on season tickets don't modify their price. However, thanks to the technical refactoring performed, a further development would allow to create advantages on fixed price and championship season tickets modifying their price. Such a development is foreseen but hasn't been planned yet. Note that this feature won't concern calculated price season tickets.
Getting started
Setting up the prices of a fixed price or championship season ticket
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).
