Everybody takes screenshots. Almost nobody takes useful ones.
The typical evidence folder, assembled in a hurry after something has gone wrong, contains a photo of a green tick, a blurry picture of a phone screen taken with another phone, and a banking app summary with the balance clearly visible and nothing else that identifies anything. None of it settles a single question.
The distinction is simple and it is not about image quality. A useful screenshot contains a fact that somebody else can independently check. Everything else is decoration.
What makes a screenshot count
Four properties, and a good capture has at least three of them.
A specific amount. With the currency shown. Amounts are close to unique inside a date range, which makes them the strongest single identifier a buyer can supply.
A timestamp. Date and time, ideally from the application itself rather than from your phone’s status bar. It anchors the event to a moment somebody else can look up.
A reference or identifier. A transaction reference, an order number, a descriptor. This is what turns "please look for my payment" into a search that takes ten seconds.
Context showing where it came from. The app or the address bar, so it is clear the image is from your bank rather than from a page anybody could have made.
A screenshot of a message saying "payment successful" proves that a screen said something. A screenshot showing an amount, a time and a reference proves that a transaction exists. Only one of those is worth keeping.
The six worth taking
In rough order of usefulness.
1. The transaction detail view. Not the list — the individual payment, opened. Descriptor, exact amount and currency, exact date and time, status, and usually a reference. This is the one that ends a standoff over whether a payment exists, and it is the one to send when your payment succeeds and the seller says it did not.
2. The page before you pay. Price, term, what is included, any conditions. Take it while you are still deciding. This is the record that does not exist anywhere else, because nobody archives what a page looked like on a Tuesday, and it is the reason reading a subscription’s terms before the money moves is worth the two minutes.
3. The agreement itself, if it happened in a conversation. Where an order is placed by message rather than through a checkout, the thread is the contract. Capture the part where the plan, the price and the term are stated together, rather than relying on the app to still hold it next year. Keeping a payment trail when you order through a chat covers the rest of that.
4. The confirmation, with its headers visible. Not just the body of the message but who sent it and when. A confirmation from an address you can verify is a different object from a screenshot of some text.
5. The fault, when it is happening. If the reason you may need any of this is that the service is not working, capture the error with a visible clock. A fault documented on the day is worth vastly more than the same fault described from memory six weeks later.
6. The statement line once it posts. The settled amount, not the pending one, with the descriptor as your bank actually renders it. Useful for the same reason as the first item and for a different audience — this is what an accountant or an expense system wants.
| Screenshot | Must show | Answers the question |
|---|---|---|
| Transaction detail | Amount, time, descriptor, reference | Did the payment happen? |
| Page before paying | Price, term, inclusions | What was I promised? |
| Order conversation | Plan, price, term, dates | What did we agree? |
| Confirmation with headers | Sender address and timestamp | Who sent this, and when? |
| The fault in progress | The error, plus a visible clock | When did it stop working? |
| Posted statement line | Settled amount and descriptor | What actually left my account? |
The ones that prove nothing
Four common captures that feel like evidence and are not.
The success message on its own. A green tick and the word "complete". No amount, no time, no reference. It could belong to any transaction on earth.
The account summary. A list of transactions with your balance across the top. It shows a line but none of the fields anyone can search on, and it exposes something private in exchange for nothing.
A photo of a screen. Taken with a second device, at an angle, with glare across the half of the image that mattered. Use the device’s own capture function. Every phone has one.
A crop so tight it lost its context. An amount and nothing else. Which account, which app, which day — all gone. The crop that removed the private part also removed the proof.
Three you should never take
Some captures are not merely useless. They are a liability the moment they exist on your device.
A full card number, or the card itself. Front or back. The last four digits are what identifies a payment; the rest identifies you to anybody who obtains the image. No legitimate seller needs it, and what a seller legitimately needs to know about you draws that boundary explicitly.
A one-time code or a security prompt. Those codes exist precisely so that knowing your card details is not enough. Anyone asking you to screenshot one is asking you to hand over the last defence you have, and the layers involved are explained in the security code, the billing address and the step-up check.
A password or recovery screen. Including the ones people capture "just to remember it". Screenshots sync to cloud galleries, get shared accidentally, and outlive the device they were taken on.
A related point on where you send them. Verify the channel before attaching anything, because a convincing support account is easier to create than a convincing payment page — verifying a seller’s contact channel is really theirs takes about a minute and is worth it.
Timing beats quality
The most common failure is not a bad screenshot. It is a good screenshot taken three weeks too late.
Screens change. Prices update. Conversations get archived. Payment pages get redesigned. Almost everything worth capturing has a window measured in days, and the moment you realise you need evidence is invariably after that window has closed.
So the rule is to capture at the moment of the transaction, not at the moment of the problem. That means the page before you pay, the confirmation when it arrives, and the statement line when it posts — three captures, over about a week, none taking longer than ten seconds.
The same principle governs the fault itself. If something stops working, capture it that day with a visible clock. If you later need to establish when a service degraded, contemporaneous images are worth more than any account you can give afterwards, and this matters especially if you intend to keep using the service while a claim is open — what happens to a dispute if you keep using the service explains why.
What to crop and what to keep
Most people crop exactly backwards, removing the useful parts and leaving the private ones.
Crop out: your account balance, your account number, any part of a card number beyond the last four digits, and unrelated transactions belonging to other people in a shared account.
Keep in: the amount, the currency, the date and time, the merchant descriptor, the reference, the status, and enough of the surrounding interface to show which application the image came from.
Crop with the device’s own tool rather than annotating heavily. A black box drawn over a number is fine; a heavily edited image invites the question of what else was changed. And keep the original alongside the cropped copy, stored privately, in case a fuller version is needed later for something like the evidence a bank asks for.
Storing them so they still exist
A screenshot in a camera roll of eleven thousand images is theoretically kept and practically lost.
Make a folder per purchase, named with the date and the service. Move the captures into it the same week. Add the confirmation as a saved file rather than leaving it in an inbox, since inboxes get migrated and filtered in ways folders do not. Keep it wherever the rest of your annual paperwork lives.
Keep them for the length of the term plus a few months, because questions surface at renewal far more often than during a term. The full list of what belongs in that folder is in the paperwork worth keeping after you pay for a yearly service, and if you have already lost the original documents, asking for a receipt months later covers what can still be rebuilt.
What is worth capturing here
Specifically, for this site, there are three and they take under a minute in total.
The plan and price as shown on the pricing page at the moment you decide — $69, $97 or $137 a year for one, two or three simultaneous screens. The part of the order conversation where the plan, term and price are stated together, since there is no checkout form to generate that record for you. And the statement line once it posts, with the descriptor.
Because payment is a single annual charge with no card kept on file and nothing renewing on its own, there is no recurring charge to monitor and no second amount to reconcile — which is exactly why the small set above is sufficient. There is no long tail of transactions to track.
If you would rather have a document than a screenshot, ask for one. Send the date and amount to WhatsApp, Telegram or support@pay-iptv.com. What we will never ask you to photograph is a card, a code, or a password, and any message that does is not from us.
