Playbook, fintech app
The general causes of a decline, without describing this particular one
Payment questions divide cleanly into two piles that feel like one pile to the person asking. Timings, cut offs, corridor speeds and the published list of common decline reasons are fixed terms, sitting on your own pages, answerable in a sentence. The transfer this customer sent at four o'clock yesterday is not, and the distance between those two things is where the trouble is.
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.
- Some declines come from the card issuer rather than from you, which means even your own team cannot always state the reason, let alone a widget.
- A decline is occasionally a control rather than a fault, which makes an exhaustive list of causes something you deliberately do not publish.
- Timing questions are answerable to the hour from a cut off table, and they are a large share of the volume that currently reaches staff.
- Money is in flight, so a wrong reassurance can produce a duplicate payment, which is a worse outcome than the original problem.
How it arrives
- why was my payment declined
- i sent a transfer three hours ago and it has not arrived
- my card keeps getting rejected on online purchases
- what time is the cut off for a same day transfer
- the money has left my account but the recipient has not got it
- can a payment be held for checks
What has to be indexed for this to work
| Payment timings and cut off times by corridor | When a transfer sent at a given hour actually lands, what a weekend or a public holiday does to it, and which routes are slower. High volume, entirely published, and currently answered by staff reading the same table the customer could have read. |
|---|---|
| The published list of common decline reasons | The general ones you are comfortable stating: insufficient funds, an expired card, a mismatch on the billing address, a limit reached. Published generally rather than diagnostically, and never extended into the controls you do not describe publicly. |
| The limits table | Daily and monthly limits by account type, per transaction caps, and how a limit resets. A surprising share of declines are limits, and this is the one cause a customer can check for themselves in ten seconds. |
| How to trace a sent payment | What information is needed, who handles it, and the realistic timescale. Money that has left and not arrived is the most distressing version of this question and it needs a named route rather than a general contact page. |
The reply
I cannot see any payment or account, so I cannot tell you what happened to that specific transfer. The published cut off for same day transfers in that corridor is two in the afternoon on a working day, and anything after that is processed the next working day, with weekends and public holidays not counted. Payments can also be held while routine checks complete. If it has left your account and not arrived, that needs tracing by a person, so leave your name, the email on the account and the date and amount, and the team will follow it up.
It answers the part that is genuinely knowable with a specific time rather than a vague description, which is what closes most of these conversations. It mentions holds as a general possibility without inviting a discussion of what triggers one. Asking for date and amount rather than for a full description means the trace starts with what the team needs, and it never suggests resending, which is the advice that turns one problem into two.
Where it stops
The trigger. The question concerns a particular payment, or money has left an account and not arrived.
A specific payment has to be looked at by somebody with access to the account, which I do not have. Leave your name, the email registered to the account, and the date and amount of the payment, and it will go to the team who can trace it. Please do not send it again in the meantime.
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
- Why this particular payment was declined or held.
- That a payment will arrive by a given time, or that it is on its way.
- The criteria that cause a payment to be held for checks.
- That resending a payment which may still be in flight is a reasonable thing to do.
Questions
- Can it tell somebody whether their transfer went through?
- No, and this is the case where the temptation is strongest, because the customer is distressed and the answer feels like it should be simple. It has no view of any transaction. What it can do is give the published timing so the customer knows whether it is even late yet, which resolves a good number of these.
- Our decline reasons are quite detailed internally. Should we index them?
- Index the general ones you already publish and stop there. Internal decline taxonomies frequently include control logic, and indexed material becomes answers, so publishing them through a chat box publishes them to everybody who thinks to ask.
- What is the single highest value document here?
- The cut off table. It is precise, it is stable, it answers a question asked hundreds of times a week, and almost every firm has one written down somewhere that customers cannot easily find.
Keep reading
- Everything for a fintech appFees, limits and identity checks are safe ground. Balances, transactions and anything reading as a personal recommendation are not.
- 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.
- Explaining the recovery route without becoming any part of itReset questions look trivial until you notice the asker is unverified. What chat explains, and every step it must never perform.
- A complaint starts a clock, so it has to be recorded rather than absorbedA complaint to a regulated firm follows a defined procedure with deadlines. The assistant quotes it and makes sure the message is logged.
- The one handover in this set where a contact form is the wrong mechanismSomebody watching money leave an account cannot wait on an email reply. Putting the number in the refusal text rather than composing it.
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.