Introduction - recurring payment mandates

Ordo-hosted (white-labelled) vs Client hosted payer experience

Ordo's 'Payment as a Service' offering delivers a turn-key solution for Open Banking payments. Our highly secure service, designed and built by payments experts, provides an array of frictionless payments solutions that are easier than ever for you and your customers to use, and are more cost effective than traditional payment methods

Ordo provides two options for integration allowing you as a business to choose the one that suits your use case best. Our hosted and white-labelled authorisation journey means that Ordo handles the user experience (UX) through a series of customisable screens, before redirecting your customer to their Bank, whereas our client hosted authorisation journey allows you the merchant to maintain your own UI and UX whist still taking advantage of Ordo's Open Banking connectivity and authorisation orchestration.

For more information on our two recurring payment mandate products, please review our Ordo and Client hosted solutions.

About recurring payment mandates

Recurring Payment Mandates enable you to collect any customer payment on a repeating basis for fixed or variable amounts. Examples for this includes:

  • Fixed recurring payments, such as streaming subscriptions or rental payments
  • Regular, but differing amount, payments, such as utility bills or loan repayments
  • Ad-hoc payments, such as automated top-up of accounts when balances are low
  • One-click style checkouts, like paying for on-demand food delivery or ride-hailing services

You can set up a mandate with your customers that allows you to collect payments on a regular basis as long as it is in line with the parameters that has been agreed with both parties. There's no need for the customer to provide additional authorisation for each payment, which gives you and the customer more transparency, flexibility and security than the current services like Direct Debit, Standing Orders etc.

Types of recurring payment mandate

TypeDescription
SweepingEnables the transfer of money between two accounts belonging to the same person, also referred to as 'me-to-me' payments. Typical use-cases are for customers paying into their own savings account, making a loan repayment, or topping up a pre-paid card balance.
Non-Sweeping*Enables payment to third-parties, also referred to as 'me-to-business' payments. Typical use-cases are for 1-click checkout at an eCommerce site you use regularly or paying a utility bill.

*VRP non-sweeping is not currently available as the banks do not currently offer the solution

Operating in the background, our Recurring Payment Mandate API is invisible to the end user and gives you complete control of your payments experience.

Creating a recurring payment mandate

To create a mandate, you need to provide Ordo with the parameters you want your customer to sign-up to. You also need to say whether the mandate is for a sweeping or non-sweeping use-case, see above for the different types of mandates.

Parameters

There are a number of parameters that you can choose to include within the mandate:

  • Maximum transaction amount; this is the maximum amount that you can collect from your customer in a single transaction
  • Start date; when you want the mandate to start (this must be a future date)
  • Expiry date; when you want the mandate to end (this can be open-ended)
  • Maximum period limit; this is the total amount that you can collect from your customer in a given period; you must choose at least one or more of daily, weekly, fortnightly, monthly, annually, depending on your use-case.

🚧

Note:

The details of a mandate cannot be changed after the mandate is created. For this reason, you need to make sure that all the parameters are correct at the time of creation. If they are incorrect, or over time need to be amended, you would need to create a new mandate with your customer and cancel the existing one.

Ordo Controls

Ordo performs checks on each transaction initiated under a mandate. This is to ensure that an individual transaction or period limit is not breached by the merchant or by a payer who might be initiating a transaction.

The ASPSP will also perform checks on each transaction where the VRP mandate is authorised

🚧

Note:

Both the Ordo and ASPSP checks mean that a ‘guarantee’ or liability model like that used with Direct Debit is not needed, so merchant can treat funds received as irrevocable.

Refunds

If you anticipate having to offer refunds, then you can set ReadRefundAccount to ‘True’ within the Create Mandate API endpoint.

The mandate must be authorised AND the bank involved support the sharing of refund data for the data to be made available to Ordo. Once the bank has shared the Payer account details with Ordo, Ordo will notify the merchant that the Payer account details have been captured. Ordo then store the payer’s account details against the mandate ID and the Merchant can retrieve data to make a push payment.

Mandate Creation - validFromDate

This API field can be used by a merchant to offer a future start date for the mandate. This could allow an end customer the option choose a future date that suits their regular income whilst in the merchant space, and then consenting at point of engagement.

🚧

Note

If the validFromDate has a date value that is present (current day) or in the past, then the date that the mandate is consented to at the ASPSP utilised.

The validFrom date can be used with both Consent and Calendar Period alignments.

Period Alignment - Consent vs Calendar

This API field specifies whether the recurring payment mandate value limits are calculated from the date/time of consent authorisation, a future ‘validFromDate’ as determined by the merchant, or aligns with the calendar for that period:

  • Week: 1st day of period will always be Monday
  • Fortnight: Not available for Calendar option
  • Month: 1st day of period will always be the first of the month
  • Year: 1st day of period will always be First January

As the ISO calendar does not support or provide any guidance on when a fortnight should start, hence for a PeriodType of Fortnight the PeriodAlignment must be Consent.

📘

Example: If the mandate parameters are period type is ‘month’, period alignment is ‘calendar’ and amount is ‘£30’

PeriodStartEndApplicable Limit
115-Jun-2330-Jun-2315.00 GBP
201-Jul-2331-Jul-2330.00 GBP
301-Aug-2331-Aug-2330.00 GBB

📘

Example: If the mandate parameters are period type is ‘month’, period alignment is ‘consent’ and amount is ‘£30’

PeriodStartEndApplicable Limit
115-Jun-2314-Jul-2330.00 GBP
215-Jul-2314-Aug-2330.00 GBP
315-Aug-2314-Sep-2330.00 GBP