Functional Requirements

Question

Explanation

1.

Does your service allow us to take payer details

electronically?

It's important that details can be created electronically, and not just via paper.

2.

Does your service allow us to create payments electronically?

It's important that payments can be created electronically.

3.

Describe how the customer flow would work and specify whether you provide a whitelabel option and/or a hosted option for online payment pages.

You should know how the customer flow works from end-to-end. This will be any of the below three options; which one you prefer depends on how much control you require over the customer experience.

1. A 'hosted' option - Like Paypal, the customer is redirected to the payment provider's site and then ends up back at your site.
2. A 'whitelabel' option - The customer stays on your site the whole time, allowing your brand to be front and centre.
3. A mixture - e.g. an iFrame that stays on your site, but is actually a 'window' to the payment provider's site.

4.

Who stores the bank details collected from the customer?

You ideally don't want to store bank details yourself for security reasons.

5.

Describe how the service provides information on the status of mandates, payments etc.

Providers will either send you files with reports (a more manual option) or send them to you via their API in the form of 'webhooks' which allows full automation to take place. If you want full automation, you should look for the latter.

6.

Describe the flow if a payment fails.

How will you be  informed of a payment failure? You want to know whether this requires a manual process or is fully automated, and you should ensure that nothing can go wrong with a customer e.g. a payment fails 'silently'. A fully automated solution is preferable as it minimises human error.

7.

Does your service allow sign-ups (a) online (b) by phone (c) in person?

Depending on your requirements, you may need to sign up customers through multiple channels. Some providers don't support all of these.

8.

How long does a payment take from creation to being taken from the customer's account to being paid out to us? Describe in as much detail as possible.

This information allows you to plan out billing cycles i.e. if you want the customer to be charged on day X, on what day do you need to send a payment request to the provider? You may also have requirements around timings.

9.

How soon are we notified of any failures that occur? Is this in real-time or batched? How are we notified?

How will you be  informed of a payment failure? You want to know whether this requires a manual process or is fully automated, and you should ensure that nothing can go wrong with a customer e.g. a payment fails 'silently'. A fully automated solution is preferable as it minimises human error.

10.

Do you manage the interactions with direct debit schemes on our behalf?

Some providers provide lightweight software that still requires you to deal with schemes yourself, including complicated report processing and submission protocols. Other providers will abstract this away using an API or file submission processes. Generally speaking, you are better off saving time on payment processing by letting the provider take care of this for you.

11.

What happens if the customer cancels the mandate with their bank? How are we informed?

You should make sure the provider will inform you automatically if the customer cancels a mandate, so you can take appropriate action.

12.

Do you provide a UI dashboard for use by our reps?

Your reps may need a dashboard e.g. to customise reports, to check the payment status for a particular customer or to refund a payment. Ideally, they should be able to do this through an online UI for convenience. Alternatively, they should be able to do this through a CRM or billing management solution such as Zuora or Salesforce.

13.

Does the dashboard allow us to filter by payment date & payment status?

You should be able to get a list of failed payments within a particular date, for example. Among other things, this helps with reporting.

14.

Does the dashboard allow export of relevant data? Explain in detail.

For reporting and for customer service purposes.

15.

Does the dashboard report on money due vs. money paid out?

This is for financial reconciliation, i.e. so that you know where your money is at all times and how much you're due.

16.

Can we search for specific customers using the dashboard?

17.

Does the dashboard show the payment timeline for a specific payment? i.e. date submitted, date collected, date paid out etc.

So that you know what the next action on a payment is and when you will be paid.

18.

Does your service support refunds? Can these be done via the dashboard? Can they be done via an API?

The service should ideally support refunds so that you don't have to develop a separate system for these.

19.

Does your service support partial refunds?

In case the customer was overcharged, for example, and you don't want to refund the whole payment.

20.

What validation do you perform of bank account details?

Look for modulus checking, which checks that a bank account and sort code number could be valid. You want these to be done instantly so that any errors are caught in the sign-up form, making for the best customer experience.

21.

Do you support variable payments? One-off payments? Recurring subscription payments?

The service should support as many cadences and configurations of payment as possible

22.

How do we retry a payment?

You may need to retry a payment if it fails, e.g. because the customer didn't have enough money in their account at the time.

23.

Is your software integrated with any accounting platforms? Specify three.

You want a service that is integrated with software providers, both because it increases convenience and saves you time (e.g. a Zuora integration) and because it signals that the provider has an API that is easy to integrate against, which saves you development time down the road.

24.

What happens if we want to change provider? Is this supported?

Many providers don't help you switch provider.  Ideally they should help you move off the platform if need be - which is easy with Direct Debits, since they can be transferred between banks without the customer having to do anything.

25.

What steps do you take to minimise payment failures?

The best providers have lower failure rates because of their experience and specialism. They should be able to give you specifics on how they minimise failures e.g. by optimising submission cycles, gracefully dealing with common bank errors, etc.

26.

Does your system enable upgrades/downgrades of subscriptions without additional customer input?

For the best customer experience, you want the ability to change payment amounts without requiring any more input from the customer.

27.

Who handles notifications for customers? How does this work in terms of the flow?

Depending on how you want the branding to work, you should look for a provider that's flexible here, i.e. helps you set up your own emails to notify customers of payments, or provides an option where the provider does it for you.