Payment and identity hygiene: the account graph that links your fleet

You can get the network right and the device right and still lose a whole set of accounts in an afternoon. I have watched it happen to people who were doing the hard parts properly. Dedicated line per identity, separate profiles, careful about timezone and language and every value a fingerprint page reads back.

The thread that pulled them down was on the billing screen.

One card paying for all of it. That is the layer nobody audits, because it feels like admin rather than infrastructure, and it is the layer that quietly overrides every technical wall you paid for.

The details you hand over on purpose

The account graph is what a platform builds from the information you type in yourself. Your payment method. The phone number you set for recovery. The recovery email. The contacts you uploaded. The referral that brought the account in.

None of that is scraped or inferred. You entered it, the platform stored it, and it now knows exactly which accounts share which field.

When two accounts share enough of those fields, the platform draws a line between them in its own database. That line has nothing to do with canvas hashes or IP ranges, and no tool you install on your side can reach in and erase it.

Why it sits above the technical stack

A shared fingerprint is a technical problem, and technical problems have technical fixes. Different profile, different values, done. A shared address has the same shape of answer.

A shared card is a recorded fact.

That is the whole reason this layer beats the ones people spend money on. Your antidetect browser has no way to visit a platform’s records and separate two accounts that gave it the same recovery number. The graph sits above the entire stack and is immune to it, which is why the most careful setups still die to the most boring mistake in the operation: one detail reused across accounts that were supposed to be strangers to each other.

The shared card

The classic version, and the one that takes out the most accounts at once, is a single payment method funding everything.

You build a dozen isolated identities. Each gets its own profile, its own line, its own inbox. Then you pay for all twelve with the same card, because reconciling twelve statements is annoying and one is easy. In that moment you hand the platform a clean list of which accounts belong together.

The card is a hard identifier. The moment one of those twelve gets flagged for anything, the obvious next query is everything else sharing that payment method, and the whole set surfaces at once. Every wall you built gets bypassed by the checkout form.

Recovery numbers and recovery inboxes

A recovery phone number links accounts just as hard, and it does it quietly, because it lives on a settings screen you opened once during signup and never looked at again.

The number does not have to be used for anything. Sitting there as the recovery contact on several accounts is enough to tie them together in the platform’s records, regardless of how separate everything else is. People reuse a number without thinking about it. It is only for recovery, it never receives anything, and it ends up being the thread that connects the fleet.

Email is the same trap in a different field. A recovery address reused across accounts links them. So does a set of addresses that all obviously funnel into one inbox, or that follow a pattern anyone could read at a glance.

The purpose of a recovery contact is to prove an account belongs to you. When the same one proves that for ten accounts, it has proven all ten belong to the same person. Treat each account’s email as part of its identity rather than a shared utility.

Contacts and referrals

Then there is the social layer, which catches people who got the money and the recovery details right.

When accounts upload contacts, or share big chunks of the same address book, or all connect out to the same handful of other accounts, the overlap is visible and the inference is easy. A set of accounts that all know the same people look related because in the platform’s eyes they are. Mass identical contact overlap is one of the louder signals you can produce without noticing.

Referrals close the same loop from the other direction. If a batch of accounts all trace back to one inviter, or invite each other in a tidy ring, the origin is recorded precisely so the platform can understand where its users come from. Inviting your own accounts to each other feels efficient. It is a written confession of common ownership sitting in the referral log.

Different cards, same person

Separate cards do not finish the job on their own.

The same name, the same billing address, the same details attached to every payment across supposedly independent accounts is a link as clear as a shared card number. Platforms and their payment processors read the whole billing record. Payment separation means the identity attached to each payment holds up as distinct, not only the sixteen digits at the front.

The same name on every receipt undoes the work of using different cards.

What virtual cards actually separate

Virtual and single use cards help, and I use them. They are a real instrument for creating real separation, and treating them as a solved problem is where people go wrong.

If a stack of virtual cards all draws from one funding source, that source can still be the link, depending on what the processor and the platform can see. The visible numbers differ. The money all comes from one place, and that shared root is what a fraud system is built to find.

Real separation means looking at the whole chain rather than the last instrument in it. A dozen cards funded from one account are far less separate than they look on the dashboard.

The quiet fields

The discipline has to reach past cards and emails, because the graph is built from every identity field a platform collects.

Loyalty numbers. Saved shipping addresses. Autofill profiles that drop a phone number into a signup form you were being careful about. A rewards account attached to several identities. Each of these is a thread, and each of them hides somewhere you never think to check, which is exactly why they survive an otherwise thorough cleanup.

The links begin forming the second an account is created.

The name, the date of birth, the address, the number, the payment method entered on the first screen all go straight into the record as that account’s identity. Any of them reused becomes a link immediately, before the account has posted anything or logged in a second time. An account born sharing details with others is linked from birth, and no amount of careful behaviour afterwards unlinks what the signup form already wrote down.

This is why hygiene has to be right at the start. There is no patching it later.

The honest business version

There is a legitimate version of shared details, and it deserves saying plainly.

If your accounts are genuinely parts of one real declared business, an agency running client accounts, a company with several legitimate profiles, platforms have provisions for exactly that. Declared relationships are allowed. Hiding a legitimate business relationship is often more suspicious than stating it, because the shared details are going to be visible anyway and the only variable is whether you volunteered them.

The graph is a problem when you are presenting related accounts as strangers. When they really are related, use the platform’s own mechanism for that.

The audit, and the honest limit

Because these links live on screens you rarely open, you have to go and look on purpose.

One sheet. One row per account, one column per identity field: card, funding source, billing name, phone, recovery email, contact source, referral origin. Then read down each column and find the repeats. Everyone who builds this finds something they did not know was shared. Usually the recovery email. Sometimes the funding account behind a set of cards that looked separate.

Fix the overlaps before a ban wave finds them, and fix them one at a time rather than in a single loud afternoon of edits across the whole fleet.

Then hold the limit in view. Clean payment and identity hygiene stops the cascade. It does nothing about how any individual account behaves, and it does not excuse pushing an account harder than the platform tolerates. What it buys you is that when one account falls, it falls alone.

That is worth more than it sounds like.

The full separation checklist and the tested picks are at Multi Account Ops.

Get new guides and videos first — join the Telegram channel.