Ask most people when their subscription ends and they will tell you a month. Ask them which of three dates that month is calculated from and the answer gets vague.
There are three, they are set by different systems, and they only coincide when everything goes smoothly on the same afternoon. When they do not coincide, the difference is measured in days you either have or do not have, and by the time it matters the evidence for which was which has usually been deleted.
Three dates, three different clocks
They sound like the same event described three ways. They are not.
Paid. The moment your payment was authorised. Set by your bank or the processor, recorded to the second, and visible on your statement. This is the most precisely documented of the three and the least relevant to when your service ends.
Activated. The moment a working line existed against your name — credentials issued, the account switched on. Set by the seller's system. This is the date the service is normally measured from, and it is the one least likely to be written down anywhere you can find it.
Expires. Activation plus the period you bought. Calculated rather than observed, which means it inherits any error in the date it was calculated from and carries it forward for a year.
The date you can prove is the one that does not matter. The date that runs your subscription is the one nobody sent you.
Which one your service actually runs on
The convention worth insisting on is simple: the clock starts when the service starts. Twelve months from activation, not from the payment timestamp.
The reasoning is not sentimental. Until a line exists you have nothing to use, so counting from payment charges you for a period during which the thing you bought did not exist. On a same-hour activation the distinction is academic. On an order placed at midnight and activated the next morning it is a few hours. On an order placed before a weekend and set up on Monday it starts to be worth noticing.
Some sellers do count from payment, and it is not necessarily sharp practice — it is simply the easier field to read from a payment record. It does mean you get slightly less than the period you bought, and the amount depends entirely on how long they took to activate you, which is not something you control.
So the question to ask before ordering is one sentence: is my expiry calculated from the payment or from activation? An answer that comes back immediately and specifically tells you the seller has thought about it. An answer of "same thing really" tells you something too, and it fits the pattern in reading a subscription's terms before the money moves.
Where the gap comes from
Four situations produce a gap between paid and activated, and only two of them are the seller's doing.
| Cause | Typical gap | Whose delay | Does it cost you days? |
|---|---|---|---|
| Ordinary processing | Minutes | Seller | No |
| Payment authorised but not settled | Hours to days | Bank or processor | Only if counted from payment |
| Ordered before you were ready to set up | Days | Yours | Yes, if activated at once |
| Details missing or wrong on the order | Hours to days | Shared | Usually not |
The third row is the one that catches people. Ordering on a Tuesday for a device arriving on Saturday feels organised. If the line is switched on immediately, four days of it are gone before anyone plugs anything in. The subscription was working; you were not there.
The second row is the subtler one. A payment can be approved without the money having moved, and a seller who waits for settlement before activating is not stalling — the mechanics are in a payment that is authorised but never settles. What matters is that this gap sits between paid and activated, so a service counting from payment charges you for it.
None of the four should produce a gap of more than a day in normal conditions. What a normal timeline looks like is in what actually happens in the ten minutes after you pay.
What happens to the dates at renewal
Renewal is where the three dates stop being a curiosity and start costing money.
A renewal applied to an existing line should extend from the current expiry. Pay fifteen days early and the new year begins when the old one ends: you keep the fifteen days and gain twelve months. Nothing is lost, which is why renewing before the deadline is safe.
A renewal processed as a new order does something different. A fresh line is created, activated today, expiring twelve months from today — and the fifteen remaining days on the old line are simply abandoned, along with the credentials your devices already hold. Same money, less service, plus a reconfiguration job.
The difference is entirely in whether the payment is tied to the existing account. It is the same failure described in paying for a second year, not a second account, seen from the calendar's side. Name the existing account when you renew and confirm the new expiry in writing before you assume it worked.
Renewing after expiry raises a fourth date nobody mentions: the day the line was switched off. Whether the days between that and your payment are restored, ignored or added on varies by seller, and the answer belongs in the message that confirms your renewal — a point covered in renewing early, renewing late, and what happens to the days in between.
Time zones, and the day you lose to them
An expiry is a timestamp, and a timestamp needs a zone. Most people never see which one theirs is stored in.
A line expiring at midnight on the 14th in one zone can show as the 13th or the 15th somewhere else. If you are eight hours behind the system that holds the record, an expiry that looks like it has all evening left may already have passed. The reverse also happens, which is why people occasionally find a subscription still working a day after it should have stopped.
This is harmless as long as you know. It becomes a problem when you plan around the displayed date — leaving a renewal until the last evening, and discovering the last evening was yesterday somewhere else. Ask which zone the expiry is recorded in, note it beside the date, and treat the day before as your real deadline.
The same drift explains the occasional mismatch between the date on your receipt and the date in your account. It is one clock or the other, not an error — a cousin of the confusion in what the descriptor on your statement is telling you, where a record generated by one system is read against another.
What to check, and when
Four moments, each taking under a minute.
Before you order. Ask whether the term runs from payment or activation, and order when you are actually ready to set up. If a device is arriving next week, buy next week. There is no advantage to being early and there is a measurable cost.
At activation. Ask for all three dates in one message: paid, activated, expires. Save it with the receipt. This single message is what settles any later disagreement about how many days you were owed, which is why it belongs in the paperwork worth keeping after you pay for a yearly service.
A month before expiry. Check the date rather than trusting memory, and note which zone it is in. A month is enough time to renew without pressure and enough to notice if the recorded expiry is not what you agreed.
Immediately after renewing. Confirm the new expiry is twelve months from the old one, not twelve months from today. If it is the second, the renewal was processed as a new order and it is far easier to correct in the first hour than in the second week.
When the dates are wrong
Errors do happen, and they are usually clerical rather than deliberate. What matters is that they are cheap to fix immediately and expensive to fix later.
Expiry shorter than it should be. Send the payment date, the activation date and the period you bought, and ask for the correction. With those three attached it is a two-minute job. Without them it becomes a discussion.
Expiry unchanged after a renewal. Usually means the payment has not been applied to the line yet, or has been applied to a different one. Do not pay again. Send the reference and ask which account it landed against — what to send support so a payment problem is solved in one message covers the exact contents.
Activation date later than you were told. If the delay was the seller's, the expiry should move to match. Ask for it explicitly; systems calculate from a stored field and do not adjust themselves out of politeness.
Nothing on record at all. The one that should worry you. A seller who cannot state when your line was activated and when it ends does not have a system that knows, and that is a problem long before it is a dispute.
How the three dates work here
Our convention is the one argued for above, and it is worth stating plainly so it can be held against us.
Your term runs from activation. If you pay on a Friday night and the line goes live on Saturday morning, your twelve months start Saturday. If something at our end delays activation, the expiry moves with it — you are not charged for days on which nothing was working.
All three dates go in the activation message: what you paid, when the line was switched on, and the day it ends. Ask at any point and we will resend them. Renewals extend from the existing expiry, so renewing early costs you nothing and there is no reason to leave it to the last evening.
There is no auto-renewal and no card on file, which removes the fourth date most subscriptions carry — the one where money leaves your account without you deciding. Every payment here is annual and one-time: $69, $97 or $137 for one, two or three simultaneous screens, published on the pricing page. The reasoning is in why we do not keep your card on file.
If your dates do not look right, send us the payment reference and what you think they should be on WhatsApp, Telegram or support@pay-iptv.com. Setting up on a new device does not change any of them — the setup guide covers that side.
