Playbook, fintech app
The money is coming back from somebody the customer has not written to
Almost no refund on a card account is the app's to give. A merchant has agreed to return money and has not sent it, or has sent it and it has not landed, or has refused and the customer now wants a dispute raised, which is a separate process with deadlines set by the card scheme rather than by the firm. Three different mechanics arrive in one message, and the assistant can explain all three while being able to move none of them.
Why this is not the general answer
The handling pattern for refund requests holds across every trade. What follows is the part that does not.
- The money usually comes back from a merchant rather than from you, so the timing is theirs, and an answer implying the app is holding it up starts an argument aimed at the wrong company.
- A pending authorisation and a settled transaction behave differently when something is reversed, and a customer watching an amount sit there for days is usually looking at the first while being told about the second.
- A dispute through the card scheme has its own deadlines, and missing one can end the option entirely, which makes the date of the transaction the most useful thing the assistant can ask for.
- The card may be issued by another firm, which means the dispute route belongs to that arrangement rather than to the app the customer is typing into, and the answer has to say so without sounding like a deflection.
How it arrives
- the shop says they refunded me but nothing has arrived
- how many days before a refund lands back on my card
- can i dispute a payment where the amount was wrong
- i was charged twice by the same shop
- the payment still says pending can i get it cancelled
- how long do i have to raise a chargeback
What has to be indexed for this to work
| Refund timings, written from the merchant's action rather than yours | How long a refund typically takes to appear once a merchant has actually sent it, and the fact that the clock starts with them. Customers count from the day the shop said yes, and the gap between those two dates is most of the volume here. |
|---|---|
| Pending and settled, explained side by side | What a pending authorisation is, how long one can sit, what happens when a merchant does not complete it, and why a reversal on a pending amount looks different from one on a settled payment. This is the single most misread thing on a card statement. |
| The dispute route and its deadlines | How a customer raises a dispute, what evidence is needed, the time limit that applies and who runs the process. Publish the limit prominently, because it is the one piece of information that stops being useful after a date. |
| Which firm handles a card dispute | If the card is issued by another company, say which entity handles disputes and how a customer reaches it. Being vague to avoid the complexity means somebody spends a week writing to the wrong place. |
The reply
A refund is sent by the merchant rather than by us, so the timing runs from when they actually processed it, which is often later than the day they told you [1]. If the payment is still showing as pending, that is an authorisation rather than a completed transaction and it behaves differently from a settled one, which the payments page explains [2]. Where a merchant will not put something right, there is a dispute route with a time limit attached, so the date of the transaction matters. I cannot see any payment, cancel one, or return money. Leave your name, the email on the account, the date and the amount, and the team will look at it.
It puts the merchant in the frame immediately, because a customer who thinks the app is sitting on their money is about to complain to the wrong party. The pending explanation is offered rather than waited for, since a large share of these are that and nothing more. Naming the time limit without stating one keeps the urgency accurate without inventing a number.
Where it stops
The trigger. Any request to reverse, cancel or return a payment, any claim of a duplicate charge, and anything the customer wants raised as a dispute.
Raising a dispute or looking at a specific payment needs somebody with access to the account, and there is a time limit involved, so it is worth doing now. Leave your name, the email on the account, the date and the amount, and it will go to the team today.
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 refund has been issued, received, or is on its way.
- Never say whether a dispute will succeed, or how likely it is to.
- Never state a dispute time limit that is not in your own published material.
- Never suggest paying again while a payment is pending or a reversal may be in progress.
Questions
- Can it tell somebody whether a refund has arrived?
- No. It has no view of any transaction and should not reason towards an answer that sounds like it does. What it can do is explain that the merchant sends it and that the clock starts there, which resolves a fair number of these before anybody needs to open an account.
- Is it safe to publish the dispute time limit?
- It is unsafe not to. A customer who finds out about a deadline after it has passed has lost something real, and the firm that could have told them in a sentence was the one they were already talking to. Publish the limit and the route on the same page.
- Customers describe disputes as fraud. Does that change the handling?
- Yes, immediately. A dispute about goods that never arrived is one process, and a payment the customer says they never made is the fraud route with a telephone number in the first reply. The trigger should be generous, because the two arrive in very similar words.
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 refund requests in generalA refund question is really about eligibility and timing. What to index, what the reply may promise, and where it has to reach a person.
- The customer is standing at a checkout, not sitting at a deskWhen payments fail everywhere at once the cause may sit upstream. What to say when the app cannot see the rail or name whose it is.
- Onboarding here is a check somebody else runs, not a configurationAccepted documents, what a proof of address must show, and why a rejected photo is most of onboarding on a regulated money app.
- A frozen screen is support, a frozen payment is something else entirelyCrashes, camera steps and reinstalls are answerable. The moment a payment is involved it stops being a troubleshooting question.
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.