Multiple Amazon Buyer Accounts for Online Arbitrage (2026)

Every online arbitrage sourcer hits the same wall on the same kind of day. A deal list drops at 6am, the spread is real — buy at $11.40, sell at $29.99, rank says it moves four hundred units a month — and the listing quietly says Limit 3 per customer. You need forty. Or the cashback portal pays once per household. Or two VAs are sourcing simultaneously from the same office IP and the second one's card declines for "unusual activity" halfway through a $2,300 cart.

So people open more accounts. And somewhere between account four and account nine, it goes sideways: a closure email at 2am, a $600 gift card balance frozen, a payment instrument flagged across every account it ever touched, and — if they were careless about which machine they used — a seller account sitting in related-account review while inventory ages in a warehouse.

This guide covers the whole problem, not just the browser half. The browser half is the part everybody obsesses over and the part that fails least often. What actually closes buyer accounts is almost never a canvas hash.

Let's be straight about the rules first

Amazon's Conditions of Use don't contain a single crisp sentence saying "one buyer account per human" the way the seller policies spell out the multiple-account rule. What they do contain is broad discretion: Amazon may refuse service, terminate accounts, cancel orders, and remove content at its own judgement, and you're responsible for everything that happens under your account and for keeping your account information accurate.

In practice, enforcement behaves as though a one-account rule exists the moment multiple accounts are used to defeat a per-customer limit, stack a one-per-customer promotion, or re-trial Prime. That is the honest position. Running ten accounts to buy forty units of a three-per-customer item is a terms violation, and the downside isn't theoretical:

• account closure with no appeal path on the buyer side (buyer support is far less structured than Seller Performance)
• forfeiture of gift card balances and Prime time remaining
• cancellation of in-flight orders, sometimes after you've already promised the units to a customer
• payment instruments and addresses marked, so the next account you open dies in a week
• linkage to your seller account, which is the expensive one

No software removes that risk. An antidetect browser changes what a website can observe; it does not change what the terms permit. Anyone selling you the opposite is selling you a bad outcome on a delay. Read the rest of this with that on the table, and decide accordingly.

There's also a category of multi-account use that is entirely ordinary and that most guides skip past, which we'll get to: separate marketplaces, separate legal entities, separate purchasing users under an organisation, and simply keeping a business sourcing history out of a personal recommendation feed.

Why online arbitrage collides with one-account-per-person

OA is a volume game on thin, perishable margins. The constraints that push sourcers toward multiple accounts are structural, not moral:

Per-ASIN quantity caps. Amazon caps units per customer on promotional pricing, lightning deals, and a lot of consumables. The cap is often 1–5. A deal worth chasing is rarely worth chasing three units at a time.

One-clip coupons and promo codes. Digital coupons clip per account. So do most "save 20% when you buy 2" style promos, subscribe-and-save discount tiers and first-order codes on the retailer side.

Cashback and portal stacking. Rakuten, TopCashback and card-linked offers are per member, and a shared household often counts once.

Recommendation pollution. This one is underrated and completely benign. If you source 300 SKUs a month through your personal account, your recommendations, your Subscribe & Save suggestions and your family's shared browsing become garbage. Splitting business buying from personal buying is a filing decision, not an evasion.

Parallel operators. Two or three VAs sourcing at once cannot share one login without stepping on carts, triggering concurrent-session heuristics and generating exactly the pattern fraud models are built to spot.

Regional marketplaces. amazon.com, amazon.co.uk, amazon.de and amazon.co.jp are not one account in any practical sense, and browsing a European marketplace through a US residential IP with a US locale produces a mismatched, half-broken experience — wrong currency defaults, wrong delivery estimates, occasional interstitials.

Non-Amazon suppliers. Most OA buying isn't even on Amazon. It's Walmart, Target, Home Depot, Lowe's, Zoro, Wayfair, Costco, Kohl's, Bed Bath, Sam's Club. Those sites run the same linkage machinery, and several of them are more aggressive about cancelling reseller-looking orders than Amazon is.

How Amazon links accounts: the six layers

If you only understand one thing from this article, make it this: linkage is a graph problem across six independent layers, and the browser only touches two of them. People fail on layer one and blame layer three.

1. Account-graph identifiers (the strongest, and un-spoofable)

Payment instruments (issuer BIN + last four + cardholder name), shipping and billing addresses, phone numbers, recovery emails, 2SV numbers, and gift card claim codes. These are first-class fields in Amazon's own database. There is no browser setting on earth that hides the fact that six accounts all ship to Suite 214, 3400 Industrial Parkway, and all pay with cards ending 4417.

In my experience this is where 80% of OA multi-account closures originate. Everyone reuses the prep centre address, because the whole business model depends on that prep centre.

2. Cookies and site storage

Amazon's ubid-main, session-id, session-token, at-main and friends, plus localStorage, IndexedDB, service worker caches and the HTTP cache itself. Any of these surviving between two accounts is a direct, unambiguous join. If you want the mechanics of how long-lived identifiers actually work, MDN's HTTP cookies reference is the clearest non-marketing explanation there is.

This is the layer that ordinary Chrome profiles do solve. It's also the layer people assume is the whole game.

3. Device fingerprint

Canvas and WebGL rendering output, the GPU vendor/renderer strings, AudioContext characteristics, installed font enumeration, screen metrics and device pixel ratio, navigator.hardwareConcurrency and deviceMemory, timezone, language list, User-Agent Client Hints, media device counts, and a dozen smaller signals. Amazon runs a substantial device-fingerprinting script through checkout and login. So does every other large retailer, usually via a third-party fraud vendor.

Run EFF's Cover Your Tracks on your normal browser once. The number it gives you — how many browsers in their sample share your exact configuration — is roughly the number a retailer's fraud model is working with too. If it says "unique among 300,000", every account you log into from that machine is one hop apart.

The deeper mechanics of this layer, and what actually changes when you spoof it, are covered in how websites detect multiple accounts on the same device.

4. Network

IP address, ASN, IP reputation and abuse history, IPv6 prefix, DNS resolver, TLS/JA3 characteristics. Datacenter ASNs are classified instantly and cheaply — every major CDN sells that as a product. A residential IP shared by four of your accounts is barely better than one datacenter IP shared by four.

5. Behaviour and timing

Order cadence, basket composition, the moment of purchase. Six accounts that each bought the same three ASINs between 06:12 and 06:19 the morning a deal list dropped are a cluster no fingerprint work can hide. Same for identical review-and-return patterns, identical Prime signup dates, identical browsing depth before checkout.

6. Cross-device bleed

The phone. Someone logs three accounts into the Amazon app on one handset to check delivery, and the app's device identifier stitches them together permanently. Same for a shared home Wi-Fi, a shared smart TV, or an Alexa device.

The honest summary: layers 2 and 3 are what an antidetect browser fixes. Layers 1, 5 and 6 are policy and discipline. Layer 4 is a proxy budget. A perfect browser stack with a shared card is a slower failure, not a prevented one.

Use the legitimate structures before the technical ones

A surprising number of OA operations reach for multi-accounting when a supported structure would have done the job with none of the risk.

Amazon Business with multiple requisitioners

Amazon Business lets one organisation add multiple purchasing users under a single account, each with their own login, their own approval workflow and their own payment method. You get quantity discounts, business-only pricing, tax exemption handling and consolidated invoicing — the invoices being the part that matters most, since they're actual supplier invoices with your business details on them.

For a team of three VAs sourcing on your behalf, this is the correct answer roughly 100% of the time. It solves the concurrency problem, it's auditable, and it doesn't put your seller account near a linkage review.

Genuinely separate legal entities

Serious multi-entity OA operations aren't running "alt accounts." They're running separate LLCs with their own EIN, their own business bank account, their own card issued to that entity, their own registered address, and — critically — their own human operator who is actually a director or employee of that entity. That's a defensible structure. It's also expensive and slow, which is exactly why it's rare.

Regional marketplace accounts

Buying on amazon.co.uk from the US, or on amazon.de as a UK-based sourcer, involves separate customer accounts on separate marketplaces. This is normal. What's not normal is doing it from a single browser with a single US IP, which produces a device profile that says one thing and a locale that says another.

Household and family

Amazon Household exists and is narrow: two adults, shared benefits, shared payment visibility. It's genuinely useful for personal life and almost useless for arbitrage volume. Mentioned only so you don't waste a week on it.

The isolation stack, built properly

If you've concluded a separated-profile setup is right for your operation, here's how to build it so the technical layer stops being the weak point.

One profile, one identity, forever

A profile isn't a browser window. A profile is a bundle:

• its own user data directory — cookies, localStorage, IndexedDB, service workers, cache, saved passwords, extension state, all on disk, never shared
• its own fingerprint — canvas, WebGL, audio, fonts, screen, navigator, UA-CH, timezone, languages, generated once and stable for the life of that identity
• its own proxy — one exit IP, consistently
• its own metadata — which card, which address, which email, which phone, when it was warmed, what it's bought

That last item is the one people skip and later regret. A spreadsheet works until identity twelve; after that you want the notes attached to the profile itself.

The critical rule is the boring one: a profile is bound to one identity permanently. Not "mostly." One login of account B inside profile A creates a cookie-level join that never expires, and it's typically done at 11pm by someone who "just needed to check a tracking number."

Why Chrome's built-in profiles are not this

Chrome's people-switcher separates cookies and nothing else. Same canvas hash, same WebGL renderer string, same font list, same screen geometry, same IP, same install. To a fraud model, two Chrome profiles are one device with two cookie jars — which is precisely the signature it's designed to catch. Incognito is worse: it separates storage and discards it, so every session looks like a brand-new device from an established IP, which is its own kind of weird.

Fingerprint consistency beats fingerprint randomness

This is the single most common technical mistake. People assume the goal is to look different. The goal is to look ordinary and internally consistent.

A fingerprint claiming macOS in the User-Agent while reporting Win32 in navigator.platform, a Direct3D11 ANGLE renderer string, Europe/London as the timezone, and connecting from a residential IP in Ohio isn't anonymous. It's a screaming anomaly — and anomaly is the exact thing the model scores on. The real machines it's compared against are boringly self-consistent: a Windows 11 laptop with an Intel iGPU, 8 threads, 1920×1080 at 100% scale, en-US, America/New_York, and a font list that looks like a stock Windows install plus Office.

Two things follow. First, generate a whole coherent device, not a pile of independent random values. Second, aim for the fat part of the distribution — a common GPU, a common resolution, a common OS version. The full reasoning, plus what to change and what to leave alone, is in how to change your browser fingerprint.

There's also a question of where the spoof happens. Fingerprints applied by injected JavaScript leave artifacts: patched functions whose toString() doesn't match native code, overrides that don't reach Web Workers or nested iframes, timing differences on property access. Fingerprints applied inside the browser engine itself have none of those tells, because there's nothing injected to detect. Dual Login takes the second approach — the fingerprint is read natively by the engine at startup, so a page sees a device, not a device with a costume on.

Proxies: one identity, one exit, matched geography

Rules that hold up:

• Residential or mobile per identity. Datacenter IPs are classified by ASN in milliseconds and are the fastest way to make a well-built profile look fake.
• Sticky sessions. An IP that rotates mid-checkout looks like session hijacking. Hold the exit for the whole session, ideally for the whole life of the identity.
• Match the geography to the story. Exit IP city → account's default address region → timezone → language list. If the account ships to Dallas, don't browse it from Warsaw.
• Never share an exit across identities. One IP, one account. This is the line item people cut, and it's the one that reconstructs the whole cluster.
• Be suspicious of cheap residential pools. Some are built from consent-dubious SDKs and are already on abuse lists. A $0.50/GB pool that's been used for credential stuffing is worse than no proxy.

Selection criteria, pool types and the sticky-vs-rotating trade-off are worked through in the antidetect browser with residential proxies playbook.

The layer software cannot fix

Say it again, because it's where the money is lost:

The three "yes" rows in the software column are real and worth paying for. They are also three rows out of nine.

Isolation approaches compared

The VM row deserves a note, because "just use VMs" is common advice. VMs give you real OS-level separation, which is genuinely strong — but virtualised GPUs produce recognisable renderer strings, the guest OS installs share a suspiciously identical font set, and you still need one proxy per VM. You pay ten times the RAM for a fingerprint that's often more identifiable than a well-built spoofed one.

The operational playbook

Warming

A fresh account that places a $1,400 order for forty units of one ASIN on day one is a fraud alert with a delivery address attached. Give each identity 7–14 days of ordinary behaviour first: browse categories that make sense for the persona, add things to a wishlist, buy something small and cheap, let a delivery complete successfully, leave the account idle for a couple of days. Successful low-value orders are the strongest positive signal a buyer account can accumulate.

Cadence and ladders

Ramp order values instead of stepping onto them. $20, then $60, then $200, then $500. Mix baskets — a sourcing order that also contains a phone case and a bag of coffee reads like a person. Stagger across identities: if a deal list drops and you're buying across six accounts, spread the purchases across 12–36 hours rather than nine minutes. The timing cluster is free evidence you don't have to give away.

Session discipline

One profile, one identity, no exceptions. Don't paste session cookies between profiles. Don't log a sourcing account into the phone app. Don't check a tracking number from your personal browser because the profile manager was closed. If a VA needs access, give them the profile, not the credentials.

Returns are the tripwire

Buyer-account closures for returns abuse are far more common than closures for multi-accounting, and OA operations generate returns naturally — wrong variation, damaged in transit, deal wasn't what the list said. Keep the return rate low and the reasons accurate. An account with a 30% return rate closes on its own merits, and then everything attached to it gets a second look.

Gift cards and balances

Don't park value in an account you might lose. A closed account keeps its gift card balance, and there is effectively no recovery route. Treat balances as inventory sitting in a warehouse you don't own the lease to.

Records

For every identity, log: profile name, email, phone, card issuer and last four, billing address, shipping address, proxy endpoint and region, creation date, warming completion date, last login, marketplace, and which VA operates it. When something goes wrong you need to know within thirty seconds what else shares a component with the account that died. Per-profile notes, tags and group filters inside the profile manager beat a spreadsheet, because the record lives where the work happens.

Where the buyer side touches the seller side

This is the expensive part, and it's the reason to take the browser layer seriously even if you think buyer accounts are low-stakes.

Amazon's related-account machinery doesn't distinguish neatly between buying and selling identities. A device, a card, an address or an IP shared between a closed buyer account and your Seller Central login is exactly the kind of edge that surfaces in a related-account review. Losing a $200 buyer account is annoying. Losing a seller account with $40k of inventory in FBA is a business event.

So: Seller Central gets its own profile, its own proxy, and its own everything. Never log into Seller Central from a sourcing profile, not once, not to check a case. Never use the business card that pays your Amazon fees to buy inventory on a sourcing account. If you're doing anything at scale on the selling side, the companion piece — how to avoid account bans on Amazon Seller — covers the seller-side linkage rules in detail.

One more genuinely useful OA fact while we're here: Amazon retail invoices are not accepted for ungating. Category and brand approval wants an invoice from a supplier or authorised distributor, on business letterhead, with your business name and address, dated within the last 90 days, for a meaningful quantity. An order confirmation from amazon.com is not that, no matter how many accounts you bought it across. If ungating is the goal, more buyer accounts is the wrong tool entirely.

The rest of the sourcing stack

OA rarely lives on Amazon alone, and the same isolation stack pays for itself across the whole supplier list.

Retailer accounts. Walmart, Target, Home Depot and Lowe's all cancel reseller-looking orders, and several of them do it by device and IP cluster rather than by name. Running each retailer identity in its own profile keeps a cancellation at one retailer from teaching the next one about you.

eBay sourcing and liquidation. eBay's buyer-side linkage is aggressive and payment-anchored, and their restriction messaging is famously vague. If eBay is part of your sourcing or resale flow, the guide to managing multiple eBay accounts covers what that platform specifically keys on.

Etsy and smaller marketplaces. Lighter fingerprinting, heavier payment-instrument linkage. The card matters more than the browser.

Mistakes that actually kill accounts

In rough order of how often I've seen them do real damage:

1. One shipping address across everything. The prep centre. Fix it with suite numbers at minimum, separate receiving accounts ideally.
2. One card, or one card issuer, across everything. Different issuers, not just different numbers.
3. Logging into the wrong profile once. Permanent, silent, unrecoverable.
4. Buying the same ASIN across every account within the same hour.
5. Datacenter proxies, or one residential IP serving four accounts.
6. Skipping the warm-up and putting a $1,200 order on a two-hour-old account.
7. The mobile app. Three accounts, one phone, done.
8. A randomised fingerprint that changes every launch. A device whose GPU changes weekly is not a device.
9. Reusing recovery emails or phone numbers, usually the operator's own.
10. No records, so when one account dies you can't tell which others share a component with it.

Notice how many of those are the browser's fault. Two, arguably.

Choosing the tooling

Whatever you use, the requirements list for this workload is short and specific:

• A real per-profile data directory on disk, so sessions persist and survive restarts and machine moves. Losing all your logins to a cache clear is a bad afternoon.
• Native, engine-level fingerprinting rather than injected JavaScript, so there are no patched-function tells and the spoof reaches Web Workers.
• Internally consistent generated devices, not a random-value slot machine.
• A proxy per profile, including SOCKS5 and authenticated HTTP proxies, with the timezone and language derived from the exit IP automatically.
• Bulk import — CSV of names, proxies, groups, cookies — because setting up thirty identities by hand is how you make thirty typos.
• Cookie import and export in the formats you actually have (JSON exports, Netscape cookies.txt, raw header strings).
• Team roles if VAs operate profiles, so an operator can use an identity without holding its credentials.
• Local-first storage. Your account list is sensitive commercial data. It shouldn't be sitting in someone else's database as a condition of using the software.
• An automation API if you want deal-list checking or price monitoring driven per profile rather than by hand.

Dual Login does all of the above: each profile is a separate OS process with its own data directory, the fingerprint is applied natively by a custom Chromium engine rather than injected, proxies are per-profile with automatic geo/locale matching, and the profile store lives on your own machine. If you're weighing it against the established names on price and feature set, the comparison of cheaper Multilogin alternatives is a reasonable place to start.

Measuring whether any of this is working

Track three numbers per identity and you'll know months before an audit does:

Survival age. Days since creation, still active. If your median identity dies at 40 days, something structural is wrong — probably an address or a card, not a fingerprint.

Order acceptance rate. Orders placed vs orders not cancelled by the retailer. A dropping rate across several identities at once usually means a shared component just got scored.

Checkout friction. How often an identity gets an OTP challenge, a card verification, or a "confirm it's you" interstitial. Friction rising on one profile is that profile's problem. Friction rising across the fleet is your proxy provider or your fingerprint generator.

And keep a simple incident log. When an account dies, write down the date, the last three orders, the address, the card, the proxy region and the profile age. Four entries in, the pattern is usually obvious, and it is almost never the thing you assumed.

Conclusion

Running multiple Amazon buyer accounts for online arbitrage is a terms-of-service question first and a technical question second, and most of the people who lose accounts lose them for reasons a browser was never going to fix — a shared prep centre address, one card across six logins, forty units bought in nine minutes.

If you're going to do it, do the legitimate structures first: Amazon Business with real requisitioners, separate entities where the volume justifies them, marketplace accounts where they're genuinely separate. Then make the technical layer boring and airtight — one profile per identity, a coherent fingerprint that doesn't change, one residential exit per account, and records good enough that you can trace a closure in thirty seconds. Warm slowly, ramp gradually, stagger everything, and keep Seller Central on an island of its own.

If you want the isolation half handled properly, Dual Login runs each profile as its own browser process with its own data directory, native fingerprint and proxy — locally, on your machine, with your account list staying yours. Spin up a couple of profiles, run them through Cover Your Tracks and a fingerprint checker, and see what a clean, consistent device actually looks like before you put a real account behind one.

FAQ

Is it against Amazon's terms to have multiple buyer accounts?

Amazon's Conditions of Use don't spell out a numeric limit, but they give Amazon broad discretion to close accounts and cancel orders. In practice, using multiple accounts to defeat per-customer quantity limits, stack one-per-customer promotions or re-trial Prime is treated as a violation and does result in closures. Separate accounts tied to genuinely separate legal entities, separate marketplaces, or separate purchasing users under Amazon Business are a different situation entirely.

Will an antidetect browser stop Amazon from linking my accounts?

It handles two of the six linkage layers — site storage and device fingerprint — and a proxy handles a third. It cannot touch payment instruments, addresses, phone numbers, purchase timing or anything you do in the mobile app. If six accounts share a card and a prep centre address, perfect browser isolation only delays the outcome.

How many Amazon buyer accounts can I realistically run?

The hard ceiling isn't the software; it's how many genuinely distinct payment methods, addresses, phone numbers and email domains you can maintain honestly. Most solo operators run out at three to five before things start overlapping. Teams with real entity structures go further, but the constraint stays financial and administrative, not technical.

Do I need residential proxies, or are datacenter proxies fine?

For Amazon checkout, datacenter IPs are a liability — their ASNs are classified instantly and they carry accumulated abuse reputation. Use residential or mobile exits, one per identity, held sticky for the whole session. Avoid the cheapest pools; a heavily-abused residential IP scores worse than a clean datacenter one.

Can a closed buyer account get my Amazon seller account suspended?

It can contribute. Amazon's related-account reviews look across shared devices, IPs, payment instruments and addresses without caring whether the accounts were buying or selling. Keep Seller Central in its own profile with its own proxy and its own payment method, and never log into it from a sourcing profile.

Can I use Amazon retail invoices to get ungated in a brand or category?

No. Ungating requires an invoice from a supplier or authorised distributor with your business name and address, on letterhead, dated within roughly 90 days, for a meaningful quantity. Amazon retail order confirmations are consistently rejected regardless of how many accounts they came from.