A payment has two sides, and each side sees a different part of it. That is not a conspiracy; it is how the system is built. But it explains almost every conversation where a customer and a business appear to be describing incompatible events.
You are looking at your banking app. You see a line, an amount, a date, a descriptor. You do not see whether an authorisation was approved, what code came back, or whether anything ever settled.
The seller sees the opposite. They have the authorisation record, the response code, the timestamps to the second — and no view of your account at all. They cannot see your statement, your balance, or whether a pending line is sitting there worrying you.
Knowing which half sits where turns a frustrating exchange into a short one, because you stop asking each party for information they were never given.
Two people, two halves, one event
Set the two views side by side and the pattern is obvious.
| Detail | You can see it | The seller can see it |
|---|---|---|
| The settled amount on your statement | Yes | No |
| A pending line reducing your balance | Yes | No |
| Whether an authorisation was approved | No | Yes |
| The response code behind a decline | No | Yes, in outline |
| The exact time an attempt arrived | Roughly | To the second |
| Whether the payment has settled | Eventually | Yes, with a date |
| Your balance, or your other payments | Yes | Never |
Read the third and fourth rows against the first. That combination produces the single most common deadlock in payments: your app shows a charge, the seller says no payment was received, and both of you are telling the truth. One is describing an authorisation, the other a settlement, and the two are different events. The mechanism is set out in a payment that is authorised but never settles.
Most payment arguments are not disagreements. They are two people describing different halves of the same transaction and assuming the other one is confused.
What actually lands on the seller's side
Worth being concrete, because the assumption tends to be either that a seller sees nothing or that they see everything. Neither is right.
An attempt, with a timestamp. Every attempt, including the failed ones. A seller can usually tell you that three attempts arrived between 19:38 and 19:47, which is often the thing that unlocks a confusing evening.
An approval or a refusal, with a code. The code is short and blunt. It distinguishes broad categories — refused by the issuer, refused by the risk layer, a verification failure, an expired card — without explaining the reasoning.
A partial card identity. Card type, last four digits, expiry month and year, and often the issuing country. Enough to match a payment to a person; not enough to be worth stealing.
Whatever you typed into the form. Name, billing address, email, phone. This is ordinary order data and it is the part most people forget they provided.
Settlement status. Whether the money has actually moved, and on what date. This is the field that separates "we have your money" from "your bank reserved some of it and then nothing happened".
What none of that includes is any view into your account. A seller cannot check your balance, cannot see your other transactions, and cannot see the pending line that is currently annoying you. If you want them to know about it, you have to tell them.
What never reaches a seller at all
The short list matters, because knowing it makes one category of fraud obvious on sight.
A seller never receives your full card number in normal processing — it is replaced with a token before it reaches the business. They never receive your security code, which is used in the verification step and then discarded rather than stored. They never receive your balance, your banking credentials, or any one-time code your bank sends you.
So any message asking you to supply those things is not a payment problem being diagnosed. There is no legitimate troubleshooting step that requires a customer to read out a security code or forward a verification message, because those values are useless to a seller and valuable to nobody except someone taking over the payment. The boundary is drawn in more detail in what a seller legitimately needs to know about you, and what they never do.
The same logic applies to the channel a request arrives on. A message that claims to be the seller and asks for anything on this list is worth verifying before answering, using the method in verifying a seller's contact channel is really theirs.
The five fields worth asking for
When something has gone wrong, these are the five things on the seller's side that will actually move the problem forward. Ask for them by name.
| Field | What it settles |
|---|---|
| Attempt timestamps | Whether your attempt reached them at all, and how many times |
| Authorisation result | Whether the money was ever approved, as opposed to merely tried |
| Response code | Whether the refusal came from your bank or from their own checks |
| Last four digits and card type | Which of your cards was used — decisive in a household |
| Settlement status and date | Whether they hold your money or your bank is holding it |
The fourth row is quietly the most useful one in a shared household, where two people and three cards can produce a payment nobody remembers making. It is the same field that resolves the ownership questions in paying from a shared or family account.
The fifth is the one to ask for before starting any formal dispute. Raising a claim on a payment that never settled creates paperwork on both sides for money that was never taken, and it is entirely avoidable with one question.
How to ask so you get a useful answer
The wording genuinely changes the reply, and not because anyone is being obstructive. Open questions invite explanations, and explanations are the one thing a seller cannot reliably give you about your bank's decision.
Instead of "why was my payment declined", ask: did an authorisation attempt on a card ending in those four digits reach you at around that time, was it approved or refused, and did the refusal come from the issuer or from your own checks?
Instead of "have you got my money", ask: does your record show a settled payment for that amount, and on what date did it settle?
Instead of "the payment failed but I've been charged", ask: can you confirm whether the attempt was authorised and then not captured, so I know whether the pending line will clear on its own?
Each of those is a question about a field in a record, answerable by reading it. Include the time, the amount, the method and the last four digits in your first message and the whole thing is usually one exchange. The general template for that first message is in what to send support so a payment problem is solved in one message.
Reading the answer you get back
The content of the reply matters. So does its shape, which is a signal in its own right.
A good answer is specific and fast. Times, an approval or refusal, a settlement status, and a clear statement of which side the problem sits on. It may also tell you something you did not want to hear — that the refusal was your bank's and there is nothing they can do — and that is still a good answer.
A poor answer is vague about their own records. Not "your bank refused it", which is a fact, but "sometimes payments fail, please try again", which avoids the question. A business that takes card payments has these records. Being unable to read them back is either disorganisation or evasion, and neither is reassuring.
A bad answer changes the subject to the payment method. If the response to a routine records question is a push toward something that cannot be reversed, the conversation has stopped being about diagnosis. That pattern is the subject of why a seller who only accepts irreversible payment is telling you something.
Keep whatever you get. A written answer with timestamps is exactly what a bank asks for later, and it is far easier to collect on the day than to reconstruct in six weeks — which is the point of the evidence a bank asks for that nobody thinks to collect at the time.
Where the seller genuinely cannot help
Some things sit outside their view entirely, and pushing harder will not produce them.
Why your issuer refused. The seller gets a category, not a reason. The reason lives with your bank, and getting it is a separate conversation covered in bank declines on a foreign digital purchase, and how to clear them.
When a pending line will disappear. Once an authorisation expires unclaimed, the timing belongs to your bank. A seller can confirm they never captured it; they cannot make it vanish from your app any faster.
How long a refund takes to appear. A seller controls when they issue it, and nothing after that. The return leg runs on the rail's timetable — the distinction in the refund that arrives as a reversal instead of a payment.
Anything about your account. Balance, limits, other transactions, why your bank did something last week. None of it is visible to them, and none of it should be.
What we will tell you
If you ask what our record shows for your payment, we read it back. The amount, the method, the timestamps, the approval or refusal, the response code as we received it, the last four digits and the card type, and whether it settled and when.
We do not hold full card numbers or security codes, because processing does not hand them over and there is no reason for us to want them. There is no card kept on file either, for the simple reason that nothing renews automatically here — the argument for that is in why we do not keep your card on file.
Send the time, the amount, the method and the last four digits to WhatsApp, Telegram or support@pay-iptv.com and you will get the matching fields back rather than a general reassurance. If our record says we never received it, that is worth knowing too, because it points you at your bank instead of leaving you retrying.
Pricing is unchanged by any of this and stated in one place — $69, $97 or $137 a year for one, two or three simultaneous screens, on the pricing page, with the routes listed on the payment methods page.
