Billing overview

How Root handles billing

Overview

Root natively supports billing and premium collections, making it easy to start selling insurance. The platform's billing engine handles the entire billing lifecycle, from calculating the amount due on a policy, raising the premium, generating payments, and updating the policy balance based on the payment result.

The platform has built-in support for premium collections via debit orders or bank cards, and EFTs for ad hoc payments. Root also supports external payment methods for actioning collections using your own customer account system or a third party payments provider.

We also support a range of customisable billing and payment notifications to keep customers informed of payment related events (including failed payments), and any changes to their policy status.

In the event of failed payments, the platform will automatically lapse policies (or mark them as "not taken up") according to the lapse rules that you can configure on a product-by-product basis. You can read more about how to configure lapse rules for your product in the general product settings guide.

Root enables you to customise a range of billing settings for each individual product, such as the billing frequency (monthly or yearly), and the number of times that failed payments are retried. These settings are covered in the billing settings guide.

To find out more about the broader set of billing configurations available on Root, and how to set up different payment method types (including external payment methods), please get in touch with us.

Billing lifecycle

The Root billing lifecycle is summarised below at a high level. These steps are generally completed at a daily interval.

  • Raise premiums - The platform determines which policies are due to be billed based on their billing day, and debits the policy ledger with the amount due. Root supports both monthly billing (policyholder can choose on which day of the month to be billed) and yearly billing (policyholder can choose the day of the month and the month of the year to be billed).
  • Create payments - The platform will create payments (collections) to be actioned. The type of payments created for any given policy will depend on the outstanding balance, the policy's payment history and the payment method linked to the policy. Since debit order payments typically take a number of days to process, they are usually created in advance of the payment date. Examples of different types of payments include:
    • Recurring payments - A policy's monthly or yearly premium that has most recently been raised.
    • Arrears payments - Outstanding payments that were missed prior to the current billing period.
    • Pro rata payments - Platform creates one-off pro rata payments when the policy's billing day does not match the policy start date.
    • Ad hoc payments - Dashboard users (agents) can create ad hoc collection requests for policies.
  • Review payments - Before payments are submitted for collection, they are reviewed internally, and a number of checks are performed to ensure that policies are billed the correct amount.
  • Submit payments - Payments are submitted to be actioned by a payments provider, which will depend on the type of payment method linked to the policy.
    • Debit orders - For native Root debit orders, Root will submit the payments to Nedbank to be actioned, taking into account the required process times for different types of debit orders.
    • Card payments - For card payments, Root submits payments to be processed on the same day.
    • External payments - External payments are submitted according to the requirements of the specific payment integration.
  • Process payment responses - Depending on the payments provider, Root receives the responses via a callback endpoint or a flat file. The platform will update the payment status and, in case of a successful payment, add a corresponding credit entry to the policy ledger.

📘

Payments are assumed to have been successful after five days

Since banks typically do not send notifications for successful collections, the platform assumes that a payment was successful if it does not receive a payment failure notification within five days.

If a failed payment notification is received more than five days after the submission date, the platform will create a corresponding payment reversal, and debit the policy ledger with the outstanding amount.

Payment methods

Root supports four payment method types: native Root debit orders, cards, electronic funds transfers (EFTs) and external payment methods.

See the issuing policies guide for more details on how to add a payment method and assign it to an application or policy, or go directly to the API reference for creating a payment method or assigning a payment method to a policy.

Root debit orders

Root offers debit order payments as part of our out-of-the-box billing solution. We use Nedbank for debit orders and fully own the process, from submitting debit order payment batches to the bank within the prescribed cut-off times, to processing the payment results.

Debit order collections can be divided into two types:

  • EFT collections: Normal collections actioned by the bank as an EFT. No special mandates are required, and the bank does not track collections on the policyholders bank account.
  • DebiCheck collections: The customer has electronically mandated (confirmed) the debit order via the DebiCheck process.

For Root debit orders, you can choose one of the following collection strategies (each of which attracts a different set of costs):

StrategyCollection typeDescription
Same-dayEFTOn the payment date, Root generates same-day payments and submits them to the bank to be actioned on the payment date.
DebiCheckDebiCheckRequires the policyholder to have approved a DebiCheck mandate.

Root submits the payment three days before the payment date, and the bank strikes the policyholder's bank account two days before the payment date. If the collection is unsuccessful, the bank will automatically action the collection again the following process day, up to a maximum of five collection attempts.
Best effortHybridTwo days before the payment date, Root generates two-day payments and submits them to the bank to be actioned on the payment date.

For policies that are in arrears, the platform will generate DebiCheck collections for both the premium and arrears amounts (provided that the customer has approved a DebiCheck mandate).

Root also offers bank account verification (BANV/AVS) as an optional feature. If this feature is enabled, the following checks need to all pass for the payment method to be verified:

  • Account exists
  • ID number or company registration match
  • Account is open
  • Account accepts debits

Cards

Root enables policyholders to use credit and debit cards to pay their premiums. For card payment methods, Root uses Peach Payments as the provider. Payments are submitted to be processed on the payment date.

The following credit and debit cards are accepted (among others):

  • VISA
  • MasterCard
  • Maestro
  • AmericanExpress

EFTs

This payment method type allows policyholders to make ad hoc EFT (electronic funds transfer) payments. This is useful, for example, if an automated collection fails and the customer wants to settle their account by making an ad hoc bank transfer.

External payment methods

This payment method type allows you to add payment methods with an external account number. This is useful, for example, if you will be using an external payments provider or your own customer accounts system to process payments. By opting to use external payment methods, you gain increased flexibility in determining your own collection strategy.

If enabled, you need to select whether the Root platform will generate payments as part of the billing lifecycle, which will then be processed by the external payments system. Alternatively, the external payment system could generate the payments itself and simply send the updated policy balances to Root.

Payment coupons

Payment coupons allow you to credit a policy ledger for scenarios such as reward programs or scheduling payment holidays for policies. There are two types of payment coupons supported, namely payment holidays and ad hoc payments.

See the section on payment coupons for more details.