If two e-commerce accounts log in from the same public IP, are they automatically linked? This guide explains how NAT, CG-NAT, proxies, and the broader account association graph work, and lays out a practical playbook for keeping environments, networks, identities, and activity logs explainable across a team.
In cross-border e-commerce, "IP association" usually means that a platform has observed two or more accounts accessing its services from the same — or related — public IP address, and is now combining that network signal with identity, device, payment, store, and behavioral data to decide whether the accounts belong to the same person or are being run together.
First, a common misconception: the same IP does not mean the same person. A home, an office, a hotel, a school, and a mobile carrier can all put many devices behind one public IP. Platforms also do not publish their full risk models, so no tool can guarantee that "changing the IP" will make the association disappear. The reliable approach is to keep your account count and business relationships inside the platform's rules, and to make sure that identity, permissions, networks, and activity records are all explainable.
Why an IP Becomes an Association Signal
When a website receives a request, it normally sees the source public IP. The platform can use it to roughly locate a network region, flag unusual logins, throttle traffic, defend against attacks, and investigate fraud. When multiple accounts log in around the same time, from similar devices, with similar behavior, and from the same IP, the platform treats it as one of the correlation signals in its graph.
A public IP is rarely tied to a single device. Cloudflare's technical note on multi-user IP addresses explains that a home or office router can share one public IP across many devices through NAT, and that carrier-grade NAT (CG-NAT) can map hundreds or even thousands of subscribers behind a single address or a small pool of addresses. Any system that relies on IP alone to tell users apart will misfire on shared networks.
A more accurate framing: the IP is a node in the association graph, not the final verdict.
What Else the Platform Looks at Beyond the IP
Identity and Contact Information
Repeated company names, legal representatives, personal identities, addresses, phone numbers, emails, tax IDs, and ultimate beneficial owners usually say more about a business relationship than any single IP.
Payment and Financial Information
Credit cards, bank accounts, payout accounts, billing addresses, tax numbers, and money flows build strong links. Letting different accounts share payment instruments or transact with each other can also trigger fraud or market-manipulation investigations.
Device and Browser State
Cookies, local storage, device identifiers, browser fingerprints, operating systems, fonts, screen sizes, and extensions can all help a platform tell whether sessions are coming from the same physical setup, or a very similar one.
Login and Member Relationships
When the same employee logs into multiple stores, when an agency runs several clients, or when accounts are authorized to share assets with each other, those connections are easy to read. The question is not whether the link exists, but whether the platform allows it and the team has reported it honestly.
Catalog, Content, and Fulfillment
Identical product images, copy, stock, warehouses, return addresses, tracking numbers, customer-service templates, and unusual order patterns often reveal co-ownership more directly than any IP ever could.
Behavioral Patterns
Logging on and off in lockstep, performing actions in a fixed sequence, running the same automation script, buying from or reviewing each other, or jumping to another account the moment one gets restricted — these are read as evasion or coordinated behavior.
Scenarios That Frequently Get Flagged as IP Association
Multiple Accounts Sharing an Office Network Long-Term
If the accounts truly belong to the same company and the platform allows that setup, the shared network is not automatically a violation, but the team should rely on the platform's official member roles and keep a written record of the business relationship. If the accounts are supposed to be unrelated but share networks, payments, and devices, the explanation gets much harder to defend once it is questioned.
Public Wi-Fi and Mobile Networks
Cafés, airports, and carrier-grade NAT all pile many users onto a shared public IP. A one-off overlap is not proof of the same operator, but these networks are also less stable and less secure, which can trigger extra login checks or even account takeovers.
Free or Rapidly Rotating Proxies
Open proxies are often abused by large numbers of unknown users. The IPs are usually low-trust, the geolocation drifts, the connections are unstable, and the traffic can be intercepted. Switching countries or networks aggressively in a short window makes abnormal logins more likely.
Remote Team Members Sharing One Master Password
When team members take turns logging into the same master account from different countries, the platform sees a device, location, and time pattern that keeps jumping around. The team also cannot trace who did what, and they cannot revoke access quickly when someone leaves.
Continuing Operations from a Different Account After One Was Restricted
Most platforms ban the use of new or existing accounts to bypass restrictions. eBay's multiple accounts policy lets a user have multiple accounts for buying, selling, or running different product lines, but explicitly forbids creating or using other accounts to dodge limits; when one account is restricted, similar limits can extend to associated accounts.
What Can Happen When Accounts Get Associated
- Frequent CAPTCHA prompts, device verification, or identity / business re-verification.
- Lower limits on listings, purchases, ads, or withdrawals.
- Listings removed, traffic throttled, or the account moved into a manual review queue.
- Payments paused or fund holds extended.
- A penalty on one account spreading to its associated accounts.
- In the worst case, a feature limitation, a suspension, or a permanent closure.
eBay's account restrictions page lists reasons such as unresolved fees or buyer issues, policy violations, inability to verify the account holder, and suspected third-party access; it also notes that a seller's payouts can stay on hold until the restriction is cleared.
An official Amazon seller-forums announcement reminds sellers to run multiple selling accounts only when there is a legitimate business need, and to keep every account in good standing; an action taken against one account can also affect the others. The announcement gives examples of legitimate needs such as different brands, products made for different companies, or platform programs that require a separate account.
How to Make IP Association Risks Explainable and Compliant
1. Confirm Whether the Platform Allows Multiple Accounts in the First Place
Before creating an account, read the Seller Code, the Multiple Accounts Policy, the team-permissions rules, and the regional eligibility. When a legitimate business need exists, keep the supporting documents — company registration, brand ownership, contracts, and org charts. If a platform only allows one account per person, do not create more with technical workarounds.
2. Prefer Official Sub-Accounts and Team Roles
Employees, agencies, and service providers should each have their own member identity instead of sharing the master-account password. Grant listing, order, advertising, or reporting permissions by job scope, and turn on two-factor authentication.
3. Keep Identity Information Real and Relationships Explainable
Company, address, phone, tax, payout, and beneficial-owner details should be consistent. When related companies actually share shareholders, warehouses, or service providers, that should be declared through contracts and the platform's permitted authorization mechanisms, not disguised as if the entities were unrelated.
4. Use Stable, Trustworthy Business Networks
Office staff should connect through normal corporate, home, or mobile networks. When a proxy is genuinely required, choose a service with a lawful source, correct region, stable connections, and a use case limited to authorized business activity. Avoid free proxies, datacenter exits that are widely abused, and IPs that rotate aggressively on a timer.
"Stable" does not mean the IP has to stay frozen forever. Employees travel, carriers switch infrastructure, and incidents force migrations. The point is that the changes line up with real business activity, and that login notifications and incident notes are kept.
5. Tie Each Account to a Named Owner
For every account, record the legal entity, marketplace, purpose, primary admin, usual region, device, network, payment method, and recovery procedure. Cross-account logins should not happen without approval, and access should be revoked the day an employee leaves or a contract ends.
6. Separate Browser State to Reduce Operational Mistakes
Cookies, local storage, and extensions for different clients or stores should live in separate environments, so that nobody opens the wrong dashboard, sends a message to the wrong audience, or copies one store's assets into another. The purpose of separation is operational accuracy and clear data boundaries, not hiding who is really behind the account.
7. Keep Catalog and Fulfillment Independent and Explainable
When several legitimate stores share a warehouse, customer-service operation, or logistics partner, confirm the platform allows it and keep the service contracts on file. Do not buy from each other, do not trade fake reviews, do not copy infringing images, and do not move orders and stock to another account after one has been restricted.
8. Keep an Eye on Login Activity and Security Alerts
Review the platform's recent activity, devices, and security events on a regular cadence. Google's note on last account activity shows that the system records access times, IPs, and approximate locations, and reminds users that mobile carriers and third-party apps can surface different addresses; on spotting an unknown login, change the password, revoke active sessions, and review recovery options immediately.
When You Already Have Multiple Accounts, Brands, and Regions: How to Keep Environments Explainable
Once the operation is no longer "one store, two people", the steps above all need to run at the same time across multiple brands, regions, and team members. Spreadsheets, shared passwords, and after-the-fact chat logs are almost guaranteed to miss something.
That is the point at which accounts, browser environments, proxies, named owners, and activity records are best managed in one workspace. Take PurpleMark as an example:
- Spin up a dedicated browser environment for each authorized business account, with its own cookies, proxy, language, time zone, geolocation, and browser parameters, so team members no longer open the wrong dashboard or carry one store's cache into another.
- Bind each environment to a specific proxy and show the outbound IP, then open an IP-check page in the environment before the first login to confirm the exit matches the real business region, and log the old IP, the new IP, the reason, the date, and the check result every time a proxy changes.
- Group environments by brand, region, client, or business line, write the responsible owner, the bound account, and a short note in the group description, and use sharing, transfer, or permission revocation to hand environments over when someone joins, leaves, or changes roles.
- Turn on activity logs so that logins, parameter changes, sharing, transfers, and deletions are traceable by member and timestamp; when an association is suspected, the team can start from the log, find the root-cause account, and then remediate per the platform's requirements.
This step is about "how do we run the environments, who is on them, and what changed", and it does not replace platform rules, real identity information, or a legitimate business reason.
What to Do When You Suspect a Mistaken Association
Stop the Situation from Spreading
Do not keep switching IPs, do not register new accounts, and do not keep logging in. Freeze cross-account operations and save the platform's notices, the timestamps, the devices, the network details, and the member records.
Find the Root-Cause Account
Check for old accounts, global stores, service-provider logins, departed employees, shared payment methods, common warehouses, or unverified marketplaces. A forgotten account is often the start of the association chain.
Address Each Item in the Notice
Resolve the original violation, debt, identity, or fulfillment issue first, and only then handle the affected accounts. Screenshots that show "different IPs" usually do not carry the conversation, because the platform can rely on other evidence.
Prepare Materials That the Platform Can Verify
Useful materials include company registration, brand ownership, shareholding structure, contracts, office address, member list, payout accounts, warehouse agreements, login logs, and a clear network description. When the shared IP is caused by office NAT, carrier-grade NAT, or an outsourced service provider, explain the time window and the business context.
Use Only the Official Appeal Channels
Submit through Seller Central, platform messages, or the help center. Be skeptical of any "appeal service" that asks for remote control, verification codes, or private payment.
FAQ
If two accounts log in from the same IP, will they both get banned?
Not necessarily. NAT and CG-NAT mean many users share public IPs, and the platform typically weighs identity, device, payment, behavior, and fulfillment together. However, if the platform forbids multiple accounts, or if there is evidence of evasion, a shared IP becomes a meaningful piece of the risk picture.
Is a different proxy per account enough to stay safe?
No. A proxy only changes part of the network egress, and it does not change identity, payment, catalog, device, behavior, or business relationships. Low-quality proxies also bring their own reputation, geolocation, and account-takeover risks.
Family members run different stores. What should they do?
Confirm the platform's policy, use real identities and separate accounts with official permissions, and keep evidence for the entity, catalog, payment, and fulfillment. Do not log in to each other's accounts, do not buy from or review each other, and do not use the other person's account to bypass a restriction.
Can I just close the old account after the association?
It is not recommended. Deleting evidence or avoiding the process can backfire during an appeal. Resolve the original issue on the account first, because closing it does not erase the historical link.
Summary
IP association is not "one address equals one person"; it is the platform stitching identity, device, payment, catalog, fulfillment, and behavior into an account-relationship graph with the network as one of the inputs. Shared office or carrier IPs are normal, but non-compliant multi-account setups, password sharing, low-quality proxies, and active evasion do turn association into a real consequence.
The core of risk reduction is compliance that can be explained: only create the accounts the platform allows, use official team roles, keep identity information real, choose stable networks, separate browser state, record member activity, and address the root-cause account first when a restriction arrives. Managing environments and proxies well cuts down on mix-ups and mistakes, and makes it possible to look up, at any time, who is on which network, what was changed, and whether the action is compliant.
