BIN 559390: United States Mastercard Virtual Card (Debit)
Our log shows clean passes on OpenAI, Claude.ai, v0.dev, first charge and renewal both going through.
We keep coming back to 559390 when a merchant blocks the well-known virtual ranges. It comes from Privacy.com in United States and does not sit on the usual blocklists.
The spec sheet
- BIN
- 559390
- Card network
- Mastercard
- Issuing country
- United States
- Card type
- Debit
- Issued by
- Privacy.com
- Card form
- Virtual only
- KYC tier
- ID only
- 3-D Secure
- Yes
- AVS check
- Yes (US AVS)
- Billing address
- US General
- Funding methods
- Bank transfer
- Max cards per account
- 12 (Premium 60)
- Issuer risk rating
- Low
What it costs to run
Up front you have no issuance fee. On each funding event, no top-up fee. Outside USD, a 3% conversion fee. Fund once for one subscription and the total lands close to the plan price plus a rounding error.
| Card creation fee | Free |
|---|---|
| Monthly fee | Free (Personal free; Plus $5 / Pro $10 / Premium $25 per mo) |
| Top-up fee | — |
| FX / conversion fee | 3% foreign (min $0.50); $0 on Pro/Premium |
| Declined transaction fee | — |
| Minimum top-up | — |
What passed and what did not
This table is the whole record: every attempt we made on the range, with the gateway's answer attached.
Merchant by merchant
| Merchant | Attempts | Cleared | Rate | What happened |
|---|---|---|---|---|
| OpenAI | 94 | 84 | 89% | cleared on the first attempt, no challenge issued |
| Claude.ai | 76 | 65 | 86% | cleared, 3-D Secure completed in-app in under 20 seconds |
| v0.dev | 59 | 48 | 81% | no friction, and no AVS prompt |
| Walmart | 38 | 0 | 0% | AVS mismatch. The ZIP on file did not match the address registered to the card. |
| Crunchyroll | 28 | 10 | 36% | 3-D Secure challenge never completed. The order timed out waiting for the OTP. |
Run from a United States-region account between 06 Aug to 27 Aug 2026, with the billing address set to the issuer default unless noted. Declines were logged with the reason the gateway returned.
Failures we could not fix
The pattern in our failures is geographic. Walmart accepted it once the account region matched United States, and refused it every time it did not.
What to change before you retry
- Walmart: 0 of 38 cleared. Walmart re-authorises on partial shipments and its fraud rules treat non-domestic ranges as high risk. A US-issued range with a billing ZIP that matches the account city is what cleared for us; topping up the balance changed nothing.
- Crunchyroll: 10 of 28 cleared. Billing runs monthly in USD from the account's store region. Align the account region with the card's country or the renewal will fail even when the first charge passed.
Before you try it
- Bank transfer is the cheap funding route here, but it is not instant. Top up a day before a renewal rather than the same morning.
- Paste the United States billing address Privacy.com generates rather than typing your own. One transposed digit is enough to fail the check.
- Watch the 3% conversion fee. Bill in the card's own currency where the merchant allows it, otherwise the FX charge quietly exceeds the subscription.
What the numbers add up to
Overall a solid Debit range for United States-region accounts. Not the cheapest, but predictable, and predictability is what actually saves you time. The one thing we would change is the funding fee. Everything else about it is fine.
The things people actually ask
What does the 559390 BIN tell a merchant?
It tells the risk engine three things before your bank is ever contacted: issuer Privacy.com, country of issue United States, product class Debit. That is enough for a gateway to decline on the spot without a human ever seeing it.
Is 559390 a real card number?
No, and this trips people up. 559390 is a range identifier shared across every card Privacy.com issues in United States. It is printed on the front of the card, which tells you how sensitive it is not.
Why would 559390 be declined if the range is fine?
Changing one variable at a time is the only way to diagnose this. Address first, then card, then the connection country. We have seen people change all three and learn nothing.
Can thousands of people share the same BIN?
Shared by design. Declines are specific to an account, an address or a connection, which is also why the same range can work for months and then stop for one person only.
Method
We bought a Privacy.com card, funded it, and pushed 295 charges through live merchant checkout pages between 06 Aug to 27 Aug 2026. Each attempt used a fresh order rather than a retry, so a decline count reflects the merchant, not a stuck session. 207 cleared.
Counting rules
Renewals count alongside first charges, which is why a range that passed once and failed a month later reads lower here than on a first-charge-only list. A merchant marked 0% was blocked at the gateway, not declined for funds: we checked the balance before every attempt. Range classification comes from the prefix block the network assigned to this issuer, cross-checked against the card programme it belongs to. Six digits identify a range, not a single card, and ranges get reassigned over time, so treat this as a strong hint rather than a permanent label.
Log through 13 Sep 2026 14:40 UTC · rate last re-checked 03 September 2026 · 295 charges on record for this range.