A failed payment on the first of the month
Many of your customers pay monthly by card or direct debit. Each month some payments fail: expired cards, insufficient funds, a cancelled mandate. Your payment provider records the failure. Your policy administration system does not know about it unless someone tells it.
Someone in operations downloads the failures, checks each against the policy, emails or texts the customer, and makes a note. A week later they check again. Some customers pay, some do not, some have moved to another insurer. Policies that should have followed your cancellation process are still showing as live. Others were cancelled when the customer had actually paid.
Why failed instalments slip through
Monthly payment is an important feature for customers, and it creates a stream of small operational events that were never designed for.
- Payment failures are in the payment provider, not in the policy system.
- Retries happen on the provider's default schedule, not yours.
- Customer messages are sent by hand, or not at all.
- Cancellation steps, such as notices and dates, are tracked manually.
- Customers who update their card have no easy way to pay the missed amount.
What notice you give, and when cover ends if payment is not made, is set by your policy wording, your agreements and your advisers. The flow follows those rules.
Customers without cover, or cover without payment
If failures are not followed up, you may be providing cover without receiving premium, which your capacity provider will not like. If they are followed up clumsily, customers who meant to pay lose cover or get confusing messages, which leads to complaints. Operations spend hours on a monthly routine that could run itself.
A failed instalment flow
What we build connects your payment provider, your policy system and your messages.
- Payment failure events from your provider, such as Stripe or GoCardless, are picked up as they happen and linked to the policy.
- The customer gets a message straight away with a secure link to update their card or pay the missed amount.
- Retries run on the schedule you set, which can differ by failure reason.
- The policy's payment status is updated in your policy administration system, so everyone sees it.
- If payment is still missing at the points your rules set, notices go out from your templates and dates are tracked.
- If the cancellation date is reached, the cancellation is processed through the policy system's API and the final notice is sent.
- A dashboard shows failures in progress, recovered, and cancelled, and support can see each case from the helpdesk.
| Day in the sequence | What happens | Set by |
|---|---|---|
| Failure | Customer message with pay link | Your template |
| Retry points | Payment retried automatically | Your schedule |
| Notice point | Formal notice sent, date recorded | Your wording and advisers |
| Cancellation date | Policy cancelled via API, final notice | Your wording and advisers |
| Paid at any point | Sequence stops, policy status restored | Automatic |
What the first of the month looks like now
Failures turn into messages and retries without anyone opening a spreadsheet. Most customers fix their card from the link. The few who do not follow your process exactly as written, with every notice and date recorded. Operations look at exceptions, such as a customer who says they paid by another method.
Is this how failed payments work for you?
- Payment failures are downloaded and checked by hand.
- Customer messages about missed payments are ad hoc.
- The policy system does not know a payment failed.
- Cancellations for non-payment are tracked in a spreadsheet.
- Customers cannot easily pay a missed instalment themselves.