What’s the best Direct Debit Solution?

The Real Costs of your Direct Debit Solution

To ascertain the best Direct Debit solution for your membership organisation, it would be easy to compare the costs of one supplier against the other based on a simple, all-in, per-transaction cost. Unfortunately, that is not how this market works, and there are no suppliers that make it quite this simple (although some suppliers are a lot simpler than others.). There are 3 basic types of cost: –

A simple per transaction cost – easy to understand but may work out expensive on high volumes.
A percentage of the transaction amount capped at a maximum cost per transaction – this can be very good for lower volume, high value transactions because of the cap.
A set amount based on a range of transaction volumes per month/year – this can be great for very high volumes (over 20 000 per month) but may come at a technical cost (see APIs and integrations)

The first type is obviously the easiest to calculate, but the second and third can be dramatically cheaper depending on your volumes. So, before you start comparing, it is good to work out your average monthly volume of transactions, and your average transaction value (as well as what you estimate these figures will grow to in 5 years’ time). Then we can start putting costs into a spreadsheet and comparing. We thoroughly recommend creating a spreadsheet that converts
average monthly volumes and amounts into costs.
If your Direct Debit volumes vary greatly from month to month, then a set monthly fee may not be most economical for you. This can happen if you have a large volume of renewals in any one month. Be aware though, that all Direct Debit providers do enterprise licensing when it comes to high volumes (i.e. they will negotiate). The higher the volumes of transactions, the better your ability to negotiate around their list prices. The sort of level where you could start negotiating would be in the
5 – 10 000 transaction per month area.

Hidden Costs. Most traditional Direct Debit solution suppliers work in conjunction with your bank, and so there are going to be bank charges on top of what the Direct Debit supplier will list. Now, each bank has different charging structures, so it is important to know from your bank what their fees will be – normally an added per-transaction fee – so this should be added to the fees in your spreadsheet. Some banks charge additionally per BACS file uploaded or sometimes downloaded – so this may depend on how you are doing your CRM integration. Some of the newer, challenger Direct Debit providers, like GoCardless, act as the bank as well as the BACS provider, and hence their charges are all-in and actually include the bank charges.
On top of this, whoever is providing your CRM integration may charge partner fees on top of what is listed by the DD provider. Some DD providers do a profit share of the existing fees with their integration partners, some allow partners to put their fee on top of what the provider charges. Be aware of this and add this to your pricing matrix.

Staff costs – Direct Debit processing can eat a tremendous amount of staff time – which should be incorporated into your costs matrix as the percentage of a FTE salary that would be doing this task. Tasks include –

Data entry time if you have not gone paperless.
Preparing the submission files for mandates and payments and uploading them to BACS.
Downloading files into your CRM once ready and processing.
Interpreting failure codes and manually managing failures.
Preparing and submitting retry files and associated downloads.
Creating communication letters and emails around Direct Debits
Time in creating and running reports.

These costs are not insignificant, but with modern technology available, they can be completely or partially removed, depending on which supplier you choose. Look for suppliers that will facilitate you going paperless easily, will do automated communications, automated retries and automated payment submissions and downloads – these will impact your staff costs most significantly.

Bureau or Direct BACs submitter?

In order to submit mandates and payments directly to BACS, an organisation needs a unique BACS Service User Number (SUN) so that banks can identify where the requests have come from. To get a SUN requires some bureaucratic wrangling and takes time and effort.
The alternative to this is to piggy-back off a Direct Debit bureau’s SUN number. These bureaus can submit mandates and payments on your behalf. This option is only really preferred if you are a smaller organisation with low volumes of Direct Debit. Having your own SUN is preferred if you have higher volumes of Direct Debits – its normally cheaper and allows your own company name to appear on your member’s bank statements (which makes them happy).

Look out for Direct Debit solution providers that can offer a combination of these two if you are a growing organisation or just want to test a provider first. Its very quick and easy to get started with a bureau service as there is no legal rigmarole to go through to get a SUN . This may be a good way to try the waters with a new provider. Also check how easy the process is to change from their bureau service to their direct submission service at a later stage.

Going Paperless

The goal of any new Direct Debit solution should be to do away with paper-based sign-ups or sign ups that require staff re-keying.

(we understand it’s not always entirely possible) – the impact on staff time and member service efficiency is huge. To make this happen, organisations have two options –

Create your own mandate creation page on your website – this is costly, takes significant commitment to be compliant (your bank will need to inspect and validate this), and will need to be changed every time the regulations change. Also, you will need to hook this up to a modulus checking (bank account validation) service and optionally to address validation software tool (like AFD or Loqate).
Use a hosted mandate signup page from your DD provider – this is hosted by the DD supplier, is always up to date and compliant and will contain modulus and address validation. It will also be mobile friendly. Lookout for supplier forms that you can brand with your own logo, and that can fit well into your membership sign-up flow. Hosted payment pages are also preferable because they handle all the sensitive customer data (like bank account), and you never have to hold this information, you just get a token or ID back from the DD supplier that references the mandate.

Speaking of Data Security – its highly preferable NOT to hold bank account details from your members or supporters – they would ideally need to be encrypted and have access control to be GDPR compliant.

The other part of going paperless is moving towards email communications. Every time a new mandate is set up, an email that is BACS compliant needs to be sent out. Also, every time a change is made to someone’s payment schedule or amount, they will need a specific, compliant email. Look out for DD providers that can automatically send out email communications for you that are always compliant, even if regulations change. Alternately, look for functionality in your CRM that will easily allow you to create and adjust compliant, responsive templates and schedule them to be sent out at the correct times. Of course, there will always be a few people that need paper based communications because they do not have email addresses – these will need to be dealt with as edge cases.

If your organisation will be taking mandates over the phone, you will need to follow compliant scripts containing certain questions. Look out for DD suppliers that can help you with these scripts. Remember, you cannot use the public signup forms for staff-driven signups – you will need another staff specific form (sometimes called MOTO – mail-order-telephone-order, although this is normally a credit card specific term). This would normally connect with the API of your DD supplier in a
slightly different way to public forms – it has specialist anti-fraud detection on it.

Reach of your Direct Debit Solution

When considering a DD supplier, one should think about the various types of Direct Debit payments that need to be accepted. (Yes, there are more than one!). Many DD suppliers now offer European SEPA and Swedish Giropay on top of the UK BACS Direct Debit scheme – which is great if you have European members. Some providers also have links with platforms like Wise.com to minimise the foreign currency conversion charges back to a UK bank account.

Then you may want to consider broader membership bases in the US (ACH), and Australia, New Zealand (BECS) or South Africa or Canada. There are providers that will allow you to take money from any of these schemes all using the same integration and API, and all into one UK bank account.

And then there are certain card gateway providers, that are venturing into the world of BACs and SEPA, like Stripe or GlobalPayments. However, these should be used with caution as they tend to offer more functionality around the Netflix model (x amount per month until I tell you to stop), than the ad-hoc payments model (our CRM is the master for all payments and amounts may vary from month to month). They are however worth keeping an eye on, but costs should be calculated
carefully on card providers that do Direct Debit.

Looking to the future – there is a new BACS-like scheme called Faster Payments (PayTo in Australia) which allows members to check-out instantly using bank details instead of a credit/debit card (using the underlying Open Banking protocols). Some DD providers are including this with their payment schemes – and some even allow fallback to regular DD if this fails. This is a massive challenge not only to existing Direct Debits (since it is immediate), but also to existing card payments (since the
fees are potentially far lower).

Integration or File Upload/Download?

There are two ways to connect your CRM with your Direct Debit solution – API integration or File Upload/Download.

API Integration

This method submits mandates, and payments directly through an API for you, and can also receive files (often packaged together in what are called webhooks) back into your CRM automatically. If you are thinking of going paperless, then this is by far the preferred method of integration, and it will save your staff a huge amount of time in not having to prepare and upload, then download payments and mandates files securely, and then process them in your CRM with whatever time gaps that causes in your processing.

What to look for in a DD provider API – The best, modern API’s are called REST APIs and can send/receive data in JSON format. This is by far the best API to integrate with. Older APIs which will consume more developer time are SOAP or XML based. The key thing to look for is whether there is online documentation of the API (with code samples) with versioning, that will cover mandate submissions, modulus checking, payment submissions, payment plan submissions, but also crucially that can send notifications back to you when there are changes to mandates, or payments made/failed. Ask whether you can submit payments in batches or do they need to be one by one? Can you send an ad-hoc single payment against a mandate as well as a payment plan (Netflix model) against a mandate. Does your DD Provider’s API have a simple to understand schema with unique ID’s for customers, mandates and payments? Is there a level of reporting you can do against these inside your DD provider’s system?

The best DD provider APIs always have file upload/download as a backup (just in case the direct API approach ever fails!) Also, a DD API that supports you submitting ad-hoc payments, will most likely have no charge for file submission (only for payments made) – hence it will free you up to take payments on whatever day a member may feel is best, or a designated day that is best for the organisation (like the first of the month).

What about your CRM’s API? – Firstly, are there tools inside your CRM that can push data to a DD-provider’s API, on a schedule? This may have already been written as a Direct Debit solution inside of your CRM, but if not, someone will need to write this. Also consider whether your CRM can receive packages (usually in something called JSON webhooks) coming back from a DD provider, containing payment and mandate updates. These packages will need to be unpacked and processed against membership subscriptions in your CRM.

Hazards of API integration – Things are likely to happen automatically without you eye-balling them. Make sure you have the requisite dashboards showing mandate creations, change and failures, as well as payment creation, changes and failures so you know what actions to take.

File Upload/Download

This is the old-school way of pushing payments out of your CRM. Basically once or twice a month, your staff need to create a file for new or changed mandates and new payments, export them and then upload them securely to your BACS provider. About two weeks later they need to download a file of all failed and changed mandates and successful and failed payments from BACS and then upload them to the CRM system and process them. Hugely time consuming!! Also, the BACS files are full of complex codes which need to be translated into plain English before anyone can understand them.

Hazards of file submission – Time, time, time. It takes a lot of staff time to create and upload, download, or process files. It also takes a lot of waiting time before you know whether your payments have been taken or failed. In today’s fast-paced world, time is extra precious and is key in managing member service expectations. Also, with file submission, you will likely be limited to two or four collections in a month when you do the file submissions (most APIs allow you to take your DDs whenever it suits you).

Testing and Sandboxes

Testing Direct Debits is always notoriously difficult, but there are a few things that can make this considerably easier:-

Sandbox – does your DD provider provide a free sandbox that you can hook your CRM system up to and test out various scenarios in the CRM that will result in mandate and payment creations and cancellations?
Testing actions in the DD Provider – does it provide test file creation or test webhooks creations that emulate actions like a payment succeeding or failing or a mandate being cancelled from the side of the member’s bank. Can these be pushed easily to your CRM and their progress tracked?
Bulk-testing – the place where Direct debits tend to fall over is when we are doing bulk processing. How easy is it to create a batch of 1 000 test mandates (with test bank account details) in a sandbox? How easy is it to test payments against all these mandates at once and see the reaction in your CRM system and whether it can cope with the response?

Migration

If you want the benefits of a new Direct Debit solution, you are most likely going to need to migrate from your current system. The first thing to ask here is how easy is the process? If you already have a SUN number, you may be able to keep it, but you may require a new SUN, particularly if you are moving to a bureau and are going to piggy-back of their SUN. In this case, you need to get a bulk-change-deed in place which legally allows you to move from one system to another. This process could take you 6-12 weeks.

Next you are going to want to be able to download your mandate details (customer ID, bank account and sort code) from your current CRM or DD supplier in a csv format, so you can upload it to the new system. Check whether your new DD provider can give you an excel template to populate to make this task easier. This will need to happen on the bulk change date stipulated in the abovementioned deed. This process should be fairly straightforward.

Check that your can then download the new mandate IDs (not the bank details, you never want to touch those ever again for data protection reasons), along with the legacy contact or member ID. This last past is crucial to be able to match up the mandate IDs to contacts in the new CRM. The other big factor to consider in migration is part paid invoices (if members are paying for an annual membership in monthly instalments and are part way through paying at the time of migration. This is the single biggest headache item in migrations, as you will need to have a schedule of all outstanding payments per member and will likely need to upload them manually into the new DD system. Ensure the new system can manage a manual file upload with a schedule of remaining payments if needs be.

Recurring Plans vs Ad-hoc Payments

These are the two main ways of providing payment information to your Direct Debit solution provider. The first, or what is often termed the “Netflix” model, means that you tell the supplier to start taking a set amount each month (or quarter etc..) until you tell them to stop. This type of model suits charities or the simplest membership organisations.It means that the DD provider is on charge of stipulating what amount comes out each month, and the CRM system “reacts” to these successful payments via either a file download/upload, or an API call/webhook.

For most membership organisations, amounts are likely to vary quite often – month by month or year by year because of membership rate changes, temporary halts on memberships or adding new services onto a payment(s), or, if a member misses a single payment and wants to pay double next month. In these scenarios, what we want is for the CRM system to be the master in determining a schedule of payments for each member. What will be sent across to the DD provider each month will be a list of ad-hoc payments of varying amounts against each mandate.

In our experience, we always want the CRM to be the master for telling us what past, current and future payments will be coming out of the system. It is by far the less complex route to go for membership associations, and ensure forecasting and analysis with the CRM reporting tools can give you accurate insights. Doing only the Netflix model will mean starting and stopping plans so frequently that the data management will become a nightmare quite quickly.

It is therefore vitally important that your DD provider of choice can do the latter Ad-Hoc model but you may also want it to do the Netflix model optionally.

Reducing failures and their cost

Direct Debit Failures cost organisations money, and because Direct Debit is not an immediate payment method, the longer the wait to receive notification of payment, the greater the financial implications can be – particularly if you are providing member services during this wait.

Some Direct Debit providers have cut through the traditional red tape of the DD process and shortened payment cycles to as little as 3-4 days after payment submission. If you can leverage this in your integration, you could save your organisation considerable time and funds. However, be aware that if it is a new mandate submission along with the first payment, its going to take longer (maybe 6-7 days), and you are also going to need to factor in bank holidays and weekends into your cycle as most billing cycles are based on working days.

Knowing whether a mandate is valid or not before you try to take a payment against it is crucial. If you have real time integration that notifies your CRM system as soon as a mandate’s status is changed – this is going to immediately reduce failed payments. Also, consider whether your DD provider can offer automated retries if a payment fails the first time.
This can reduce failures too.

Reporting, Insight, Automation and AI

Direct Debit solutions generate a shedload of data, and having the correct tools to gather insight on this data can give your organisation a handle on trends, spot errors before they cause damage, and help to manage bulk processes more effectively.
The first thing to get to grips with is all the complex coding of the BACS system. If your DD provider turns this into plain English for you, then reporting can become a whole lot easier.
For example an ARUDD code of 1 refers to the fact that a mandate was cancelled by the payer. It’s important to get this plain English data through the API into the CRM system, so you can put your CRMs advanced reporting tools to work creating meaningful dashboards, alerts and reports.

If you have automated processes with API pushes and pulls going on, you are going to need to visualise what’s happening in a real-time dashboard. This should look at:-

Mandate dashboards
- New ones submitted by month
- Mandate failures by month and by reason
Payment dashboards
- Payment submissions by month (year on year so that you can see this year’s trends vs last two years’ trends)
- Payment failures by reason and by date

Automated responses for failures can also be done using the automation tools in your CRM – for example – sending an automated email if a member’s payment fails because of insufficient funds that suggest you will add the amount to next months deduction. These can be done if the failure reasons are clearly written against the payments in the CRM.

Artificial intelligence is now being put onto payments by some of the more progressive Direct Debit solution providers to increase payment success rates and decrease any fraud activities. Look out for the ability to automatically retry failed payments at a time when funds are most likely to be in the members account, or the ability to predict future failures.

Yes, there’s a lot to consider regards a new Direct Debit solution provider. One of the crucial things to note is who the integrator will be. If you choose a credible partner with tons of experience for the integration, they can probably make almost anything work for you. Speak to Zentso about our decades of experience integrating CRM and Direct Debits – we are always happy to share what we have learned along the way.