Something has gone wrong with a payment. The money left your account and nothing arrived, or it arrived twice, or the amount was not what you expected. You open a chat and type: "I paid but I have not received anything."
That message cannot be actioned. Not because the desk is unhelpful, but because it contains no way to find your payment among the others that arrived the same day. The reply will be a question, your answer will prompt another question, and what should have taken ten minutes takes two days — nearly all of it spent waiting for the next message rather than doing anything.
This is a solvable problem and the solution is entirely on your side of the exchange. Here is what to put in the first message so there does not have to be a fourth.
Where the time actually goes
Work backwards from how a payment problem is actually resolved and the reason for the delay becomes obvious.
Somebody has to find your payment in a list. Then find the order it belongs to. Then compare what was issued against what you say you received. Then decide what to do and do it. The last two steps are quick. The first two are impossible without identifying information, and identifying information is exactly what a short message leaves out.
Each round trip also carries a time-zone cost. If the desk is eight hours ahead, a question asked at the end of their day reaches you at the start of yours and is answered while they sleep. Three rounds of questions is not three minutes of work spread over an hour — it is three sleeps.
The fix is never faster typing on the desk's side. It is a first message that makes the second one unnecessary.
The six facts
These six between them answer every question a desk would otherwise have to ask. None of them is sensitive and none takes more than a moment to find.
- The amount, exactly as it was charged. Including the currency. "About seventy dollars" and "$69.00 USD" are not the same fact, and only one of them can be matched against a record.
- The date and time, with your timezone. A desk in another part of the world is looking at a log stamped in a different zone. "14:20 on 4 August, UK time" removes an hour of ambiguity in eight characters.
- The route you paid by. Card, Apple Pay, Google Pay, PayPal or cryptocurrency. Each is recorded in a different place, and knowing which one decides where to look first.
- The payment reference. The transaction ID, the PayPal transaction number, or the transaction hash on a blockchain. This is the important one and it gets its own section below.
- The email address or username the order was placed under. Frequently different from the address you are now messaging from, and that mismatch is one of the most common reasons a desk cannot find an order that plainly exists.
- What you expected, and what actually happened. Two short sentences. Not an account of how you feel about it — a statement of the gap, which is the thing being fixed.
Why the reference does the heavy lifting
If you send only one thing, send this. Every payment route generates a unique string when money moves, and that string is the difference between a search that returns one result and a search that returns forty.
| Route | What the reference is called | Where to find it |
|---|---|---|
| Card | Transaction ID or authorisation code | The processor's confirmation email, or your banking app's detail view |
| Apple Pay / Google Pay | Transaction ID, plus the wallet's own entry | The wallet's transaction history on the device, and the card statement |
| PayPal | Transaction number, 17 characters | Activity list, or the receipt email sent at the moment of payment |
| Cryptocurrency | Transaction hash | Your wallet's history — it is also the public, permanent proof |
The crypto case deserves a note, because it is the one where people most often assume they have nothing to show. In fact you have the strongest proof of the lot: the hash points at a public record of the amount, the destination and the timestamp that anyone can verify and nobody can alter. Send it, and there is nothing left to establish about whether the money moved. Where those payments do and do not leave you exposed is set out in the piece on paying in crypto.
If no reference reached you at all, that is itself worth attention, because a payment that produces no record on either side is the problem rather than a detail of it. That case is covered in the receipt you should get, and what to do when none arrives.
A template worth copying
Paste this, fill the brackets, delete what does not apply. It takes about two minutes and it is the whole of the advice on this page in a usable form.
Payment issue — [one line: no access / charged twice / wrong amount].
Paid [amount + currency] on [date] at [time + your timezone] by [route].
Reference: [transaction ID / PayPal number / transaction hash].
Order placed under: [email address or username].
Expected: [what should have happened].
Happened: [what actually did].
Attached: [screenshot of the payment confirmation].
Note what is not in it. No apology for bothering anyone, no history of how the week has gone, no threat about what you will do if it is not fixed. A desk reading twenty messages will act on this one first, not out of politeness but because it is the only one that can be acted on at all.
Screenshots that help and screenshots that do not
One good screenshot replaces a paragraph of description and removes the chance that you transcribed a digit wrongly. Several bad ones make a thread harder to read.
A useful screenshot shows the payment confirmation with the amount, date and reference visible in the same frame. If it is an email, capture the sender and the timestamp too — the header is part of the evidence, and a cropped body proves less than people think.
A less useful one is a photograph of a screen taken with another phone, at an angle, with a reflection across the reference number. Use the device's own screenshot function. If the important part is small, crop rather than annotate.
And send images as images, not as a document containing images. Anything that has to be downloaded and opened is a step that gets postponed.
What never to put in a message
Support channels are not secure vaults, and a chat log can be read by more people than the person you are speaking to. None of the following is ever needed to resolve a payment problem.
- A full card number. The last four digits identify a card well enough for any legitimate purpose. Nobody needs the other twelve.
- The security code on the back. There is no support scenario in existence that requires it. A request for it is not a mistake, it is an attempt.
- Your banking or account password. No desk anywhere needs the password to something you own.
- A wallet seed or recovery phrase. Handing this over gives away every coin in the wallet permanently, and it is the most expensive mistake on this list by a wide margin.
- A one-time code your bank has just texted you. That code exists to prove it is you. Passing it to somebody else proves the opposite.
If a request for any of these arrives from someone claiming to be a seller's support desk, stop and verify the channel independently rather than replying. What a genuine seller does and does not ask for runs through our page on paying safely, and the shape of a request that should worry you is broken down in what a legitimate payment request looks like.
The one piece of evidence, by problem type
Different problems turn on different documents. Lead with the right one and the rest becomes confirmation rather than investigation.
| Problem | The detail that settles it |
|---|---|
| Paid, nothing received | The payment reference, plus the exact address the order was placed under |
| Charged twice | Both references, and whether either line still says pending |
| Amount larger than expected | The statement line showing the converted figure and any fee beneath it |
| Access stopped early | The end date you were given in writing, and the date it actually stopped |
| Fewer screens than paid for | The plan named on your confirmation, and what the service now allows |
| Renewal figure disputed | The price quoted at the time you were asked to renew |
The pattern is consistent: what was promised, in writing, versus what happened, with a date on both. That is the same evidence any formal route asks for later, which is why assembling it once is never wasted work even if the matter is resolved in a message.
Timing, chasing and escalation
Send the message once, properly, and then give it a working day. Payment records are not always instantaneous on the desk's side either, and a confirmation that has not yet propagated cannot be looked up faster by asking twice.
When you do chase, reply inside the existing thread. A new thread splits the history, loses the attachments and generally goes to the back of the queue, which is the opposite of the intended effect. Add new information rather than repeating the original.
If a working day passes with no substantive reply, say so plainly and give a deadline you intend to keep. Only after that does a formal route make sense — and the choice between asking, escalating and forcing is a real one, laid out in refund, chargeback or goodwill credit. If PayPal funded the payment, its own two-stage process has its own clocks, covered in what a PayPal dispute covers for digital goods.
Our own desk runs on WhatsApp, Telegram and email, all listed on the contact page, and all of them keep a written record you can go back to. There is one price list, published on the pricing page, so there is nothing to negotiate in a message — which means a payment thread here only ever has to be about facts and dates, and those are precisely the things a good first message already contains.
