Playbook, healthtech app
The card failed, and something behind it has a date on it
A failed payment on most products costs somebody a few days of a tool. Here it can interrupt a booked consultation, a review that has to happen before a repeat arrangement continues, or a device that quietly stops sending. The person writing rarely connects the declined card to any of that, which is why the useful answer is a timetable rather than reassurance.
Why this is not the general answer
The handling pattern for failed payments holds across every trade. What follows is the part that does not.
- What lapses is not only access to an app, it is the arrangement underneath it, so the retry schedule has to be published next to what stops on each date rather than on its own.
- A review or a booked consultation can sit behind an active subscription, which turns an unresolved payment into something with a clinical deadline attached rather than a commercial one.
- Where an employer or an insurer funds the access, the failure is at their end and the person reading the notice can do nothing whatever about it, so the answer has to say whose problem it is.
- Reading anybody's own record back to them is out of the question, so the reply has to be useful without saying what the person has booked or when their next review falls.
How it arrives
- my payment failed will i lose my consultation booking
- how long before my access stops after a declined card
- my repeat is due next week and the subscription has lapsed
- my company pays for this and it says payment failed
- i updated the card but nothing has changed
- can you take the payment again now
What has to be indexed for this to work
| The retry schedule, with what stops on each date | Every attempt, every notice, and against each one the thing that stops working. A timetable published on its own tells somebody when they will be cut off but not what they are about to lose. |
|---|---|
| What keeps running while a payment is unresolved | Whether a person can still reach their own record, whether a booked consultation stands, whether reminders continue. This is the anxious half of the question and it is answerable entirely from policy. |
| Who fixes a failed payment under each arrangement | The subscriber, the employer's finance contact, or the insurer. Say which, because somebody staring at a notice about an account they do not hold will otherwise spend a week trying to pay it. |
| The route for anything time critical while access is interrupted | Written by your clinical people and pointed at plainly. Somebody with a review due and a lapsed subscription needs a route that does not depend on the billing being sorted out first. |
The reply
When a payment fails we retry on the schedule in our billing terms, and against each date that page says what stops working, which is the part worth reading [1]. If your access is funded by an employer or an insurer, the payment sits with them and there is a contact route for that rather than a card to update [2]. I cannot see a payment, retry one, or tell you what you have booked. Leave your name, an email and roughly when the charge was attempted and the team will pick it up. If you are due a review, or you are running low on something you take regularly, do not wait for the billing to be sorted out: contact your own doctor or the urgent help route on this site.
It sends the reader to the schedule for what stops rather than for when, because that is the fact which changes their afternoon. The funded case is separated early, since those people cannot act on card advice at all. The last sentence matters most: it lifts a clinical deadline off a billing timeline without asking anybody to explain what they take.
Where it stops
The trigger. The visitor asks for a payment to be retried or access restored, says the card was already updated, or mentions a consultation, a review or a medicine affected by the lapse.
I cannot retry a payment, restore access or see what is booked. Leave your name, an email and roughly when the charge was attempted, and it goes to the team today. If anything about your medicines or your health cannot wait on that, please use the urgent help route on this site now.
It stops answering before it guesses, says who will pick it up, and asks for the one thing that makes a reply possible. Nothing about it reads as a dead end.
Never say this here
Out of bounds
- Never say a payment has succeeded, been retried, or that access has been restored.
- Never tell somebody what they have booked, when a review falls due, or what is on their record, in order to explain what a lapse affects.
- Never say a clinical arrangement carries on while a payment is unresolved unless your own material says exactly that.
- Never explain why a card was declined, since that sits with the card issuer and is invisible from here.
Questions
- Is publishing what stops on each date risky?
- The opposite. Somebody who can see that a booked consultation stands until a named day stops panicking, and somebody who can see that it does not acts before it. What you must not publish is a more generous timetable than the one you actually run.
- Can it tell somebody whether their appointment survives the lapse?
- It can quote the rule. It cannot tell them about their appointment, because it has no view of any booking and will not discuss an individual's care, and those are two separate reasons that both apply.
- What should happen when a lapse has a medicine behind it?
- It stops being a billing message. The reply should point at the clinical route in the same breath as the billing one, because a payment resolved on Friday is no use to somebody who runs out on Wednesday.
Keep reading
- Everything for a healthtech appHealth data is a special category and clinical claims carry device rules. What a healthtech assistant answers for patients, and for buyers.
- Handling failed payments in generalThe reason usually sits with the card issuer and is invisible to you. The useless reply, the useful one, and why card details never belong in a chat.
- The one question where a fluent answer is the wrong oneAn outage with a booked slot behind it. Why the assistant cannot see the service, and the route that must never run through the thing that broke.
- It is a support question until somebody describes how they feelTwo ordinary faults on a health product, and the line where a message stops being technical the moment a symptom turns up in it.
- Most of what blocks a new account has nothing to do with the appEligibility by country and by age, the access code from a sponsor, and the questions asked at sign up. What a first afternoon really runs into.
Try it on your own material
Upload a document or point it at your site, paste one line of HTML, then ask it something only your business could answer.