The card number is usually the least exposed thing in the transaction. Modern payment flows are built specifically so that the merchant never sees it — and on platforms that follow that pattern, a full breach of the site would not yield a usable card database.
What the merchant does hold is everything else: the email address you signed up with, the name and postcode attached to the card, the IP addresses you connected from, and an itemised record of what you watched or bought. For most people reading this, that second set is the real risk, and it is the one least discussed.
Who actually touches your card number?
Between three and five parties, only one of which is the site you are looking at.
| Party | Role | Sees the full number? |
|---|---|---|
| The merchant (the site) | Sells the subscription, sets the price | Not if the flow is built correctly |
| Payment service provider | Renders the card form, tokenises the number | Yes — this is their function |
| Acquiring bank | Holds the merchant's account, routes the transaction | Handles it in transit |
| Card network | Routes authorisation between acquirer and issuer | Handles it in transit |
| Issuing bank | Your bank, approves or declines | Yes — it is their card |
The design goal of the whole arrangement is to keep the merchant out of that list. A processor-hosted form returns the merchant a token — a reference that can be charged again but is worthless to anyone else, because it only works for that merchant with that processor.
Two observable signs that this is what is happening: the card fields sit in an iframe served from a different domain than the page, or clicking "subscribe" sends you to a payment domain entirely. Neither is proof of good practice, but their absence — a card form posting directly to the site's own domain — is a meaningful negative signal.
What can you actually verify from outside?
Less than you would like, which is worth saying plainly rather than implying that a checklist settles it.
You cannot audit a platform's storage practices, retention periods, or internal access controls from the outside. What you can observe:
- Where the card form is served from. View the page source or use developer tools to see whether the input fields belong to a third-party frame.
- Whether a step-up authentication appears. A redirect to your bank's own verification screen means the transaction ran through 3-D Secure, which shifts fraud liability and indicates the merchant is on a mainstream processing route.
- Whether a real legal entity is named. Terms and billing pages that name a company, jurisdiction and address are a weak positive; a billing page naming nobody is a strong negative.
- Whether the privacy policy states a retention period. Vague policies are common; a policy that specifies nothing at all is a signal about how the data is treated.
- Whether cancellation is self-service. Platforms that require an email to cancel are often the same ones with poor billing hygiene generally.
What are the actual risk categories?
Separating them matters, because the defences are different and the worst risk is not the obvious one.
| Risk | What it looks like | What reduces it |
|---|---|---|
| Card number theft | Fraudulent charges on the card | Processor-hosted forms; a dedicated card number for subscriptions |
| Merchant data breach | Email, name, purchase history exposed | A dedicated email alias; minimal profile data |
| Descriptor exposure | An unexpected line on a shared statement | Knowing the descriptor before subscribing; a separate account |
| Unwanted recurring billing | Charges continuing after you thought you cancelled | Spend caps; keeping the cancellation confirmation |
| Rebilling by an aggregator | A charge from a name you do not recognise | Checking which entity the terms name as the biller |
| Phishing after signup | Emails imitating the platform's billing | Never re-entering card details from an email link |
The correlation people miss: the sites with the weakest payment hygiene are usually also the ones with the weakest data hygiene, because both reflect the same thing — whether the operator was accepted by a mainstream processor or had to build around one.
Why is recurring billing the part that goes wrong most?
Because the subscription and the card are separate objects, and cancelling one does not cancel the other.
A stored token can be charged until the merchant stops charging it. If you cancel by closing the account page but the subscription record survives, billing continues. If you instead kill the card and leave the subscription active, the charge fails but the contractual obligation may remain, and some merchants pass unpaid balances to collections.
The reliable sequence is to cancel inside the account, keep the confirmation screen or email, and only then consider retiring the card number. Verify at the next billing date rather than assuming.
What should you do after a breach is announced?
Card exposure and data exposure need different responses, and the second is usually the one that needs attention.
For the card: contact the issuer and request a replacement number. Disputed charges can generally be contested, though the window and the exact rules depend on your issuer, your card network and your country — ask them, do not assume.
For the data: change the account password and anywhere it was reused, expect targeted phishing referencing the platform by name, and treat any subsequent "security notice" email with more suspicion than usual, because breach announcements are followed by imitation ones. If the email address you used is tied to your real identity elsewhere, that link now exists in a dataset outside your control, and no action reverses it — which is the argument for using a dedicated alias before you need one.