Payment infrastructure for multi-account: prepaid cards, virtual cards, crypto on-ramps

Most people building multi-account operations get the fingerprinting side right, then blow up all their accounts with one card. payment processors link accounts through BIN matching, billing address correlation, and velocity checks. run three accounts off the same Visa debit and you’ll get a manual review flag faster than any browser fingerprint issue ever caused you.

this guide is for operators running multi-account setups on affiliate platforms, airdrop farms, e-commerce marketplaces, or ad platforms. the goal is a payment stack where each account has a unique, non-correlated payment identity. i’m writing this from my own experience running campaigns across Southeast Asia and using a mix of US-issued virtual cards and crypto on-ramps to fund them. this is not legal or tax advice.

by the end you’ll have a working stack: virtual card issuers segmented by account cluster, a crypto on-ramp for cases where card funding isn’t viable, and a rotation system that keeps BIN fingerprints from clustering.

what you need

virtual card issuer: Privacy.com (US residents), Revolut (EU/UK/SG), Wise (global)
prepaid physical cards: Vanilla Visa or Mastercard Gift Cards (US, available at CVS, Walgreens), or equivalent local prepaid cards
crypto on-ramp: MoonPay, Transak, or direct exchange (Coinbase, Kraken) for funding crypto wallets
non-custodial wallet: MetaMask or a hardware wallet for intermediate holding
address stack: a set of real or mail-forwarding addresses for billing (e.g., Earth Class Mail, Traveling Mailbox)
VoIP numbers: for card verification calls and SMS (Telnyx, Twilio, or MySudo for personal use)
budget: budget roughly $5-15 per virtual card account setup, plus funding. Privacy.com is free for up to 12 cards/month on the free tier. Revolut virtual cards require a paid plan (~$9.99/month for the Metal tier with unlimited disposables)
basic understanding of BIN lookup: knowing what a BIN is helps. use a free BIN checker like binlist.net to verify issuer and country before you assign a card to an account

step by step

step 1: map your account clusters before touching cards

before you issue a single card, segment your accounts into clusters. a cluster is a group of accounts that will never need to be correlated. within a cluster, you can share an issuer. across clusters, you must not.

draw this out. if you’re running 30 accounts, maybe that’s three clusters of ten. cluster A uses Privacy.com cards funded via one ACH source. cluster B uses Revolut virtual cards funded from a separate bank. cluster C uses prepaid gift cards bought with cash or crypto.

if it breaks: if you skip this step and assign cards ad-hoc, you’ll end up with overlapping BINs across accounts that you later want to keep separate. there’s no easy fix after the fact, you’ll need to replace payment methods on live accounts which often triggers reviews.

step 2: set up Privacy.com for US-issued virtual cards

Privacy.com is the cleanest option for US operators. you get a free tier with 12 virtual cards per month, each with a unique card number, and you can set per-card spend limits and merchant locks.

go to privacy.com, create an account, and link a US bank account or debit card as your funding source. for multi-account work, use a dedicated checking account at a neobank (Relay, Mercury, or even a basic Chime) rather than your personal bank. this keeps your funding source clean.

once set up, create a card for each account or account cluster. use the “merchant-locked” card type when the platform you’re funding is consistent. use “burner” cards for one-time charges.

card naming convention I use:
[platform]-[cluster_id]-[seq]
e.g., amz-a-001, amz-a-002, fb-b-001

expected output: each account has a unique 16-digit card number with a distinct BIN prefix. Privacy.com cards typically issue on Visa rails with BINs in the 428837 or similar ranges. verify with binlist.net.

if it breaks: Privacy.com occasionally flags accounts that create many cards quickly. space out creation, don’t create 50 cards in an hour. if your account gets restricted, contact support, it’s usually a velocity flag that resolves with ID verification.

step 3: set up Revolut for non-US virtual cards

for accounts that need EU or UK billing addresses, or if you’re outside the US, Revolut is the go-to. the Metal plan at ~$16.99/month (as of early 2026) gives you unlimited disposable virtual cards.

create a Revolut account, upgrade to Metal, and generate virtual cards as needed. Revolut cards issue on Visa or Mastercard depending on your region. the BINs are different from Privacy.com, which is exactly what you want for cluster separation.

use a mail forwarding address in the UK or EU as your billing address. Traveling Mailbox offers UK addresses and works fine for card billing purposes.

if it breaks: Revolut has aggressive fraud detection. if you’re funding from crypto or unusual sources, expect verification requests. keep a clean funding trail into Revolut.

step 4: source prepaid physical cards for cash-equivalent coverage

for clusters that need payment methods with no digital paper trail back to a named account, prepaid Visa/Mastercard gift cards bought with cash work. in the US, $100-$500 Vanilla Visa cards are available at most pharmacy chains.

the registration process is the critical part. most platforms require a billing address to match a card. when you buy a prepaid card, you can register it at vanillagift.com with any name and address. use your mail forwarding address here.

# after buying a card, register it at:
# https://www.vanillagift.com/activate
# fields: card number, expiry, CVV, name, address
# use your cluster's designated mail forwarding address

expected output: a registered prepaid card that passes AVS (address verification system) checks on most platforms.

if it breaks: some platforms reject prepaid BINs outright. you can check whether a BIN is classified as prepaid via binlist.net. if prepaid cards are blocked, fall back to virtual cards from Privacy.com or Revolut, which issue on debit BINs that often pass prepaid filters.

step 5: set up a crypto on-ramp for funding virtual wallets

some platforms accept crypto directly. for others, you need to convert crypto to fiat and load it onto cards. MoonPay is the most widely integrated on-ramp, accepting credit/debit cards and bank transfers in 160+ countries. Transak is similar and has slightly better rates for certain corridors.

for the on-ramp setup: 1. create a MetaMask wallet (or use a hardware wallet for larger volumes) 2. complete KYC on MoonPay or Transak once, with your real identity 3. use this as a funding bridge: fiat -> crypto -> fiat on a different rail

the on-ramp KYC is real. don’t try to skip it. the value here isn’t anonymity at the on-ramp layer, it’s the separation of rails. your crypto wallet address is not linked to your card BINs.

if you’re running airdrop farming operations alongside this payment work, the setup at airdropfarming.org/blog/ covers wallet infrastructure that integrates well with this payment stack.

if it breaks: MoonPay has country restrictions. Singapore residents can use it, but some payment methods are region-locked. check the MoonPay supported countries list before building your flow around it.

step 6: assign VoIP numbers for card verification

some card issuers and platforms call or SMS to verify card ownership. assign a dedicated VoIP number from Telnyx or MySudo to each cluster. Telnyx gives you real DID numbers for ~$1/month per number with pay-per-use SMS/voice.

keep a spreadsheet mapping: cluster -> card range -> VoIP number -> mail forwarding address. consistency across these four fields is what makes an account’s payment identity look coherent rather than assembled.

if it breaks: some issuers won’t accept VoIP numbers for verification. in those cases, a physical SIM on a prepaid plan (e.g., Mint Mobile $15/month) assigned to that cluster is the fallback.

step 7: build a rotation and audit log

the last piece is operational discipline. create a simple CSV or Airtable to log every card assignment:

account_id, platform, card_last4, bin, issuer, cluster_id, address_id, phone_id, created_date
acc_001, amazon_us, 4892, 428837, privacy.com, cluster_a, addr_001, voip_001, 2026-01-15
acc_002, amazon_us, 7731, 428837, privacy.com, cluster_a, addr_001, voip_001, 2026-01-20
acc_003, amazon_us, 3319, 524305, revolut_uk, cluster_b, addr_002, voip_002, 2026-01-20

run a BIN check quarterly. issuers change BIN ranges. a card that issued on one BIN profile may quietly shift, and your cluster separation assumption breaks.

if it breaks: if you lose track of which card is on which account, platforms will correlate them before you do. the audit log is non-negotiable at any scale above 5 accounts.

common pitfalls

using the same funding source across clusters. if Privacy.com cards in cluster A and cluster B both trace back to the same ACH bank account, a platform with access to issuer metadata can see that. keep funding sources separate per cluster, or use crypto bridge funding to break the chain.

reusing billing addresses across clusters. AVS matches on address strings, not just zip codes. “100 Main St” appearing on accounts in cluster A and cluster B is a correlation point. use distinct addresses from your forwarding service for each cluster.

ignoring BIN classification. prepaid BINs, corporate BINs, and consumer debit BINs behave differently on platforms. some platforms block prepaid outright. some flag corporate cards. verify BIN type before assigning to a cluster, not after you get a rejection.

creating cards faster than your platform accounts age. a new account with a brand-new virtual card issued today is a higher-risk signal than an account with a card that’s been on file for 60 days. issue cards a few weeks before you need them and let them sit.

not accounting for currency conversion fees. if you’re using Revolut UK cards to fund USD-denominated platforms, there’s a conversion fee on each charge. at volume this adds up. use USD-issued cards (Privacy.com) for USD platforms whenever possible.

scaling this

at 10 accounts: one Privacy.com account with manual card creation works fine. one cluster, one funding source, one address. keep notes in a spreadsheet.

at 100 accounts: you need at least three issuers across two geographic rails (US + EU). automate card creation via the Privacy.com API for US cards. Revolut doesn’t have a card creation API on retail plans, so you’ll need the Business plan (~$25/month) which includes API access. budget for 3-5 mail forwarding addresses and 10+ VoIP numbers segmented by cluster.

at 1000 accounts: manual card management is gone. you’re scripting everything. Privacy.com Business API, Revolut Business API, and a database backend to track assignments. at this scale you also need to think about issuer concentration risk. if Privacy.com changes its terms (it has done so for certain use cases before), you need a ready substitute. look at Stripe Issuing or Marqeta for programmatic card issuance at scale, both require a business entity and compliance review. the Monetary Authority of Singapore’s payment service provider framework is worth reading if you’re operating here, as it governs what constitutes a licensable payment activity.

for the browser fingerprinting side that pairs with this payment infrastructure, the reviews at antidetectreview.org/blog/ cover which antidetect browsers handle payment-adjacent canvas and WebGL fingerprints well, which matters when you‘re logging in to fund accounts.

where to go next

How to set up residential proxies for multi-account operations - payment fingerprinting and IP fingerprinting need to match geographically. this covers proxy selection by region.
Antidetect browser configuration for e-commerce multi-account - once your payment stack is segmented, your browser profiles need to carry the same geographic and device story.
Back to the blog index for more operator guides.

Written by Xavier Fok

disclosure: this article may contain affiliate links. if you buy through them we may earn a commission at no extra cost to you. verdicts are independent of payouts. last reviewed by Xavier Fok on 2026-05-22.