The payment went through. Your bank says so, the amount is on the statement, and the confirmation screen said what confirmation screens say.
There is no account. No credentials arrived, nothing is provisioned, and when you ask, the seller cannot find an order matching your name. Both sides are looking at accurate records and reaching opposite conclusions.
Two systems, one assumption
The assumption buried in almost every purchase is that paying and receiving are one event. They are not. They are two systems, and a message passes between them.
System one takes the money. It talks to the card networks or the wallet provider, gets an authorisation, and reports success. That report is honest and complete — as far as it goes, which is only as far as the money.
System two creates the thing you bought. It needs to be told that a payment happened, for which plan, under which identity. That instruction is a separate message, and separate messages can be lost, rejected, duplicated, or never sent at all.
When the handoff fails, you get precisely this situation: a real payment and a non-existent account. It is not evidence of dishonesty. It is the most ordinary integration failure there is, and it is why what actually happens in the ten minutes after you pay is a sequence rather than a single moment.
A cleared payment does not create an account. It authorises one to be created. Everything in this failure lives in the gap between those two sentences.
The five places it breaks
Knowing which one you are in changes what you should send and how fast it gets fixed.
| Where it broke | What you see | What resolves it |
|---|---|---|
| Handoff message lost | Charge posted, no confirmation, no credentials | Seller matches the payment and provisions manually |
| Order created under a different identity | Charge posted, confirmation to an address you do not check | Search on the amount and time, not the name |
| Authorisation never captured | Amount pending, then it disappears | Nothing to fix — pay again once, deliberately |
| Provisioning queue stalled | Confirmation arrived, credentials did not | A person pushes it through, usually in minutes |
| Payment reached a third party only | Charge shows an unfamiliar descriptor | Establish who actually received it |
That last row is worth pausing on. If the descriptor on your statement bears no relation to who you thought you were buying from, you may have paid a processor rather than the seller, which is ordinary — or you may have paid someone else entirely, which is not. Who you are actually paying when a payment link comes from a third party covers the difference, and signs a payment page is not the seller's own covers how to spot it before it happens.
Pending or posted, and why not to retry
Before assuming anything, look at the state of the charge. It takes ten seconds and it decides which problem you actually have.
Posted. The money has moved. The seller has it, or their processor does. There is a real transaction to find and the fix is to help them find it.
Pending. The money has not moved. An authorisation is being held against your balance and may never be taken at all. If it expires uncaptured, nothing was ever paid and nothing was ever owed — which feels like a failure and is actually a clean slate. A payment that is authorised but never settles explains where the money sits in the meantime.
The distinction matters because the advice inverts. On a posted charge, do not pay again. On a pending amount that expires without settling, paying again is exactly the right move — once, deliberately, after it has cleared away.
Which brings us to the retry. The instinct when nothing arrives is to assume the payment did not take and try once more. On a posted charge that is the wrong instinct, and it reliably makes things worse.
A second payment does nothing to repair the first. The original charge is still there, still unmatched to an order, and now there is a second charge that also has to be resolved — usually by a refund that takes days to arrive and arrives by a route you did not choose. You have converted one problem into two, and the second one is slower than the first.
It also muddies the record. Two amounts of the same size, minutes apart, from the same account, is exactly the pattern that makes a seller's reconciliation harder rather than easier. The cost of paying twice covers how those get unwound, and why a payment can succeed on one device and fail on another covers the related habit of retrying somewhere else, which produces the same tangle.
Three things mistaken for this
Before concluding that nothing was created, rule out the three situations that look identical from where you are standing and are not this problem at all. Between them they account for a large share of the messages that begin "I paid and got nothing".
The credentials arrived and you have not seen them. Delivery goes to whatever identity the order was placed under, which is not necessarily the one you check. An address typed quickly with a transposed character, a number entered without a country code, a message filtered into a folder you have never opened. Search the inbox for the amount rather than the seller name, since the figure is far more distinctive than the brand and is more likely to have survived whatever the filter did.
The account exists and the device has not been set up. Provisioning and playback are separate again. Credentials can be live while nothing on the television has been told about them, and the symptom — a screen that shows nothing — is the same either way. If you have received anything at all that looks like login details, the problem is downstream of this article rather than in it.
The service was bought to start later. Where a term is deliberately dated forward, the payment lands now and the access begins on a date that has not arrived. It behaves exactly like a failure until you check the start date. Paying for a service that starts later than you buy it covers what should be visible in the meantime, which is a confirmation carrying both dates rather than silence.
Each of those takes under a minute to eliminate, and eliminating them makes the message you send next considerably more useful. "Nothing arrived" invites a round of questions you have already answered; "nothing arrived, the confirmation is not in any folder, and the start date was immediate" does not.
The message that fixes it fastest
Most of these are resolved in one exchange when the first message contains the right facts, and in six exchanges when it does not.
Send four things. The exact amount with its currency. The date and time to the minute. The merchant descriptor as your statement renders it. And the contact identity you ordered under — the phone number or address, whichever was used.
Those four turn an unfindable order into a database lookup. An amount and a timestamp are close to unique within any given day, which is why they work even when the name does not match anything. What to send support so a payment problem is solved in one message sets out the full template.
What not to send: a full card number, a security code, a one-time passcode, or a photograph of the card. None of them helps locate a payment, and no legitimate support desk will ask for one. If a request moves in that direction, the request is the problem.
How long to give it
Digital provisioning is a same-day business, so the timeline is short.
Within the hour. Check the pending or posted state, check the address and spam folder for a confirmation that went somewhere unexpected, and check whether credentials arrived under a different identity than you expected.
Same day. Message the seller with the four facts. Most cases end here, because once the payment is located the provisioning takes a couple of minutes.
Next day. If the answer was vague or absent, set a deadline in writing. State the amount, the date, what has not arrived, what you want and by when. This is not escalation; it is putting a checkable fact on the record while everything is still fresh.
Within a week. If it is still unresolved, start the process on your payment rail. Waiting longer costs you nothing today and costs you the claim window eventually.
If nothing comes back
Non-delivery is the strongest ground a buyer can stand on, and it is worth stating your case as exactly that rather than as a general complaint.
The question "was anything delivered" has a yes or no answer, which is why claims of this shape are decided quickly. Quality complaints are arguments about degree; this is not one. Keep the case narrow: payment proof, the absence of any credentials, and the messages you sent that were not answered.
The evidence a bank asks for lists what belongs in the bundle, and what a card network will and will not reverse covers the deadlines. Both are worth reading before you need them rather than after.
How it works on this site
The failure described above is mostly a failure of automation, and there is less automation here to fail.
There is no checkout form that takes money and then messages a provisioning system in the hope that it is listening. Orders are placed in a conversation, which means a person is already on the other side of it before any money moves — why there is no checkout button on this site explains the reasoning, and one of the side effects is that a payment cannot become detached from an order that a human being was never aware of.
The plans are $69, $97 and $137 a year for one, two or three simultaneous screens, listed on the pricing page. One payment, no card kept on file, nothing renewing on its own — so there is one transaction to match rather than a chain of them, and the days between paying and the service starting are accounted for rather than lost, which is the subject of the three dates on every subscription.
If you have paid and nothing has arrived, send the amount, the exact time and the descriptor to WhatsApp, Telegram or support@pay-iptv.com. Do not pay again first. If the money reached us we will find it with those three facts, and if it did not, that is worth knowing before anything else happens.
