A checkout page looks like a form and behaves like one. You type, you submit, it goes away. The impression is of something transient — a window that opened, took what it needed and closed.
Behind it, several systems have just decided what to keep. Some of those decisions are made by the seller, some by their payments provider, and a few by your own browser without anyone asking. The retention periods that follow are measured in years rather than sessions, and almost nobody is told which is which.
Three places your details can persist
It helps to stop thinking of "the payment page" as one thing. Three separate stores are involved and they hold very different material.
The seller's own systems. Who bought what, for how much, when, and how to contact them. Order records, email addresses, support conversations. This is the smallest of the three where card data is concerned and the largest where you as a person are concerned.
The payments provider's systems. The transaction itself, the token standing in for your card, the authorisation history and whatever risk signals were collected during the check. This is where card data actually lives, under obligations the seller does not carry — the split of responsibilities is set out in who you are actually paying when the link comes from a third-party processor.
Your own device. Autofill entries, a card saved in the browser, a wallet on the phone, cookies recording that you visited. Frequently the most revealing of the three, and the only one you can clear yourself in under a minute.
The store people worry about — the seller holding their card number — is usually the one that does not exist. The store nobody thinks about is the one sitting on the laptop they share.
The token that replaces your card number
Modern checkouts are built so the seller never receives the card number in the first place. Understanding the mechanism explains why several worries are misplaced and one or two are not.
When you submit the form, the details go to the payments provider rather than to the seller's server. What comes back to the seller is a token: an opaque string that represents your card within that one merchant relationship, plus the last four digits and the expiry for display purposes.
The token is deliberately useless elsewhere. It cannot be presented at another merchant, cannot be reverse-engineered into a card number, and has no value to anyone who takes a copy of it. That containment is the whole design.
Two consequences follow. First, a breach at a seller who tokenises properly does not expose card numbers, because there are none there to expose. Second — and this surprises people — the seller genuinely cannot tell you your own card number, look up a card you have forgotten, or move a saved card to another business. They never had it.
What is kept, and for how long
Retention is not one policy. Different items are held for different reasons and on different clocks, and the reasons are worth separating because only some of them are negotiable.
| Item | Typically held by | Typical period | Why |
|---|---|---|---|
| Full card number | Payments provider only | As long as the token lives | To honour the token |
| Last four digits and expiry | Seller | Life of the record | So you can recognise the payment |
| Security code | Nobody, after the payment | Zero | Prohibited by industry rules |
| Transaction record | Seller and provider | Several years | Tax, accounting, dispute windows |
| Billing address | Seller and provider | Life of the record | Verification and fraud checks |
| Email and contact details | Seller | While you are a customer, plus a period | Delivery and support |
| Device and session signals | Provider | Months | Fraud scoring on future payments |
The fourth row is the one that catches people out when they ask for deletion. A transaction record is not kept for the seller's convenience; it is kept because accounting rules require it and because a dispute can be raised long after the sale. On an annual subscription those windows can run well past the end of the service period, as chargebacks: what a card network will and will not reverse sets out.
The last row is the least discussed. Fraud scoring works by comparing this payment to previous ones, which means some record of previous ones has to exist. It is also the reason a payment from an unfamiliar device sometimes triggers an extra check — the mechanism behind the security code, the billing address and the step-up check.
The one thing that must never be stored
Among all of this there is exactly one absolute, and it is worth knowing because it doubles as a test of whether you are on a real payment page.
The three or four digits on the card — the security code — must not be retained after the transaction is authorised. Not by the seller, not by the provider, not encrypted, not "temporarily". The card industry's own rules prohibit it outright, and there is no compliant way to do it.
So a page offering to remember it for next time has failed in one of two ways. Either it was built by someone unaware of a rule that is not obscure, or it is not a payment page at all and is harvesting details — a scenario alongside the other tells in signs a payment page is not the seller's own.
This is also why a genuinely saved card still asks for the code on some purchases. The stored token covers the card; the code was never stored and has to be supplied again. An inconvenience that is doing exactly what it should.
The half that lives on your own device
The stores you can do something about immediately are the ones on the machine in front of you, and they are routinely the most exposed.
Browser autofill keeps names, addresses and sometimes cards, and it fills them into forms you have not inspected. It is convenient precisely because it acts before you have thought about it, which is also the risk.
Saved cards in the browser or operating system are usually encrypted and tied to your account, which is reasonable. The realistic threat is not a remote attacker but somebody with physical access to a device that is not locked.
Cookies and local storage from a checkout may persist long after the purchase, recording that you were there. Rarely sensitive on its own, occasionally revealing on a shared computer.
Wallets on a phone are the strongest of the group, because the card is tokenised at the device level and every payment needs a biometric or a passcode. That is a real security advantage rather than a marketing one, and it is part of why paying on mobile versus desktop is not a neutral choice.
The one habit worth adopting: if a device is shared with anyone, do not let it keep payment details. Everything else here is judgement; that one is not.
Saved cards and what saving really means
"Save my card for next time" describes a specific arrangement rather than a convenience toggle, and the specifics matter.
What is stored is the token, not the card. What that token permits depends entirely on what you agreed to: a one-time-use reference that still requires your involvement, or a standing authority allowing charges without you being present. Those are very different arrangements presented by the same checkbox.
The second version is what makes a subscription renew silently, and it is also what makes cancellation a thing you have to actively do rather than a thing that happens when you stop paying attention. Our reasoning for avoiding it entirely is in why we do not keep your card on file.
If you do save a card somewhere, know where the list of stored cards is and check it once a year. A card saved on a service you stopped using two years ago is a small open door, and it costs thirty seconds to close.
Asking what is held, and asking for deletion
You are entitled to ask, and in several of the markets this site serves you have a formal right to. The useful part is knowing what a good answer sounds like.
Ask three questions. What do you hold about me? For how long? What can be deleted on request? A seller with their affairs in order answers all three in plain language and distinguishes between what must be kept and what is kept by choice.
Expect a partial outcome. The transaction record stays, because retention there is mandatory. Marketing entries, saved payment references, support conversations and device signals can generally go. A seller who agrees to delete absolutely everything is either not reading the request properly or is not keeping proper records in the first place, and neither is reassuring.
One caution before requesting deletion: your own copies of the paperwork are what protect you afterwards, and a seller's record is not a substitute for them. Keep your receipts first, as argued in the paperwork worth keeping after you pay for a yearly service, and then ask.
What we hold, and what we do not
Our answer is short, mostly because the way ordering works here keeps it short. There is no on-site checkout — why there is no checkout button on this site explains the reasoning — so no page on this domain has ever collected a card number.
We hold what is needed to deliver and support a subscription: the contact detail you ordered through, the plan, the dates, and the transaction record. We do not hold card numbers, we do not keep a card on file, and there is no stored authority for a future charge — payment is one-time and annual at $69, $97 or $137 for one, two or three simultaneous screens, as published on the pricing page.
The full detail is on the privacy page, and what a seller has any business asking you in the first place is covered in what a seller legitimately needs to know about you. If you want to know exactly what is against your name, ask on WhatsApp, Telegram or support@pay-iptv.com and we will tell you, including the parts we are required to keep.
