A customer bought cover on your site last night and this morning the card payment failed. Are they on risk, and what does your system do next?
6 min readUpdated 2026-08-15Target archetype: Enterprise Captive, Product Startup
0
Answer
Short answer
They are almost certainly on risk, because the contract was formed when you accepted the risk and not when the money cleared. The remedy is cancellation for non-payment, which runs forwards from a notice date rather than erasing the policy, so the system needs a pending-cancellation state and an answer for a claim inside the unpaid window.
Use policy administration as the thread through the bought cover last night payment failed explanation: name the signal, then say what changes when it moves.
Was this answer helpful?
Likely follow-ups
→A loss occurs on day four of the unpaid window and is notified on day twenty. What do you pay?
→What would make it legitimate to treat the policy as never having existed, and how would you know that applied?
→The customer pays on day twelve. Does cover resume from day twelve or continue unbroken, and who decides?
→How would you model the notice period so a change of policy wording does not require a change of code?
•Does the candidate conclude that cover incepted because a contract was formed, rather than searching for a way to treat the policy as never having existed
•Whether cancellation is described as prospective and notice-driven rather than as deletion of the policy record
•That a claim occurring inside the unpaid window is addressed explicitly rather than assumed away
•Whether premium finance is recognised as moving the default risk to a third party and changing the answer
•Does the answer say what happens to documents already issued and to any external register the policy was reported to
Bind is the moment you accepted the risk. The customer made an application on the terms you quoted, you accepted it, and a contract of insurance came into existence with an inception date and time stated in it. Nothing in that sequence is conditional on a card authorisation succeeding the following morning, and the failed payment is therefore a breach of the customer's obligation to pay rather than evidence that no cover ever existed.
That is the answer, and the reason it has to be stated first is that almost every wrong design in this area comes from the opposite instinct: treating the policy as provisional until money arrives, and quietly deleting it when the payment fails. A system built that way is asserting a legal position the insurer does not hold, and the assertion is discovered in the worst possible circumstances, which is a claim.
There are narrow exceptions and a good answer names them without overreaching. Some wordings make payment of the first premium a condition precedent to cover, in which case failure genuinely means there is no cover from the outset. Some jurisdictions and some classes allow an insurer to treat a policy as void from inception where the very first payment is dishonoured. Both are properties of the wording and the regulatory environment, not properties of the payment integration, and the system's job is to know which regime a given product sits in rather than to decide the question for itself.
Cancellation runs forwards
Assuming cover did incept, the remedy is cancellation for non-payment. That is a dated, notified, forward-looking act. The insurer gives the customer notice that cover will end on a stated date unless the premium is paid, the notice period comes from the wording and the jurisdiction, and cover persists throughout that period. At the end of it the policy is cancelled from that date, not from inception, and premium is due for the period the customer was actually on risk.
So the state model needs more than active and cancelled. It needs a pending-cancellation state that is materially different from both: the customer is covered, a claim would be paid, the notice has been served, a payment received before the effective date stops the process, and the effective date itself is a piece of data that has to be carried on the policy rather than computed on the fly by whatever screen is asking.
Loading diagram…
The transition worth arguing about is the last one. Reinstatement is a decision with two possible shapes, and the system has to be able to express both.
Reinstatement is either continuous or it is not
If the customer pays after cancellation and you agree to put the policy back, you have to decide whether cover was continuous throughout or whether there was a gap. Continuous reinstatement is simpler for the customer and worse for you, because it grants cover retrospectively over a period in which the customer knew whether anything had happened. Reinstating from the payment date is the safer position and leaves a real gap in cover, which matters far beyond your own records: it affects the customer's future declarations, and in classes where continuous cover is a legal requirement it may put them in breach for that period.
Whichever you choose, it has to be a recorded decision with dates rather than a side effect of a payment landing. A payment webhook that silently flips a cancelled policy back to active has just granted retrospective cover with nobody's authority.
The claim in the unpaid window
This is the question the scenario exists to reach, and the answer is that you pay it. Cover was in force at the date of loss, the customer's failure to pay does not retroactively remove that, and the unpaid premium becomes a debt you can set against the settlement or pursue separately. Where the loss occurs during the notice period the position is the same, because the whole point of a notice period is that cover continues through it.
What changes is what you do afterwards. A claim on a policy whose premium has never been received deserves a look, because it is a recognisable pattern, and the recognisable pattern is a reason to verify rather than a reason to refuse. The one thing the system must not do is let the payment status of the policy become an input to the coverage decision, because that is how an unfounded declinature gets made automatically and then has to be defended.
Premium finance changes who is exposed
If the customer is paying by instalments through a premium finance arrangement, a lender has usually paid you the full annual premium up front and holds a credit agreement with the customer. A failed instalment is then the lender's default, not yours, and the lender's remedy is to instruct you to cancel the policy and return the unearned premium to them. The economics, the notice obligations and the party you correspond with are all different, and a system that models a failed instalment identically whether the credit sits with you or with a lender will get the refund destination wrong. That is a real financial error rather than an inconvenience, because the money goes to the customer instead of the lender.
Everything you already told the outside world
The last part of the answer is fan-out, and it is where the engineering work actually is. By the time the payment fails you may have issued documents, sent a certificate, reported the cover to a central register in classes where one exists, notified an intermediary and accrued their commission, and passed the risk into the aggregate you cede to reinsurers. Each of those has to be revisited when the policy is cancelled, and none of them can be revisited by editing a row.
Documents cannot be recalled, so the model has to be able to reproduce the document that was issued while also holding the fact that the policy it described has since been cancelled from a later date. Registers have to be updated with the end date rather than have the entry removed, because an entry that vanishes is indistinguishable from one that was never made. Commission accrued on a premium never received has to be clawed back through the same transaction stream that granted it, not adjusted by hand. The discipline is the same one backdated endorsements demand: append a dated transaction that changes the policy from a point in time, and never overwrite the version that somebody outside your system has already acted on.
Payment and cover are two separate facts on two separate timelines, and any design that couples them has decided, silently, that a failed card authorisation can retrospectively remove a customer's insurance.