Privacy.com Virtual Cards: How Payment Privacy Works

A virtual card does one specific thing: it changes what the merchant receives, not what your bank knows. This is the entire mechanism, and understanding it explains both the protection you get and the protection you do not.

Most coverage treats virtual cards as a general privacy tool and skips the technical detail. This article covers what is stored on a card, why the magnetic stripe is the weak point, and how Privacy.com’s card types behave in practice.

The practical payoff is narrow and real: a stolen number becomes useless to a thief, because it only works at the merchant it was issued for.

The Short Answer #

What Is on a Payment Card #

Three things authorise a card-not-present transaction: the primary account number, the expiry date, and the verification value.

The PAN is not a random string. The first digit identifies the scheme, the next several identify the issuing bank, and the remainder identifies the account. The structure means a card number is checked for plausibility without contacting anyone, and why the Luhn check digit catches a single transposed digit.

The CVV is what proves someone physically held the card when it was issued. It is not stored on the magnetic stripe, which is exactly why a skimmer copying the stripe never obtains it.

Inspect all of this yourself with the Magnetic Stripe Decoder and Encoder , which parses Track 1 and Track 2, decodes the service code digits, and re-encodes the result. It runs entirely in your browser, which matters because this is the full contents of a payment card.

Why the Magnetic Stripe Is the Weak Point #

The stripe stores account data in plaintext, and any compatible reader reads it.

A magnetic stripe holds up to three tracks. Track 1 carries the PAN, the cardholder name, the expiry, and a three-digit service code, and it is the only track holding alphabetic text. Track 2 carries the PAN, expiry, and service code in a denser numeric encoding, and Track 2 is what almost every point-of-sale terminal reads. Track 3 is effectively unused by the major networks and is often not present on the card at all.

The service code is worth understanding, because it describes the card’s permitted use. Digit one covers interchange rules, digit two covers authorization handling, and digit three covers the range of services. A card coded 201 permits international interchange, needs no special authorization path, and carries no service restrictions.

The history explains why the stripe lasted so long. In 1969 an IBM engineer named Forrest Parry tried to attach magnetic tape to a plastic card and failed to get it to adhere without damaging it. His wife suggested using a clothes iron, and the heat bonded the tape to the card. The improvisation became the standard for over half a century.

Two developments are ending it:

The stripe was replaced by chip and contactless payment because copying one requires no skill beyond owning a reader. Our magnetic stripe tool shows how little data is needed to reconstruct a working track.

How to Read Track Data #

A magnetic-stripe string is a sequence of fields, not a second card number. The reader finds the start sentinel, separates fields, reads the expiry and service code, then checks the end sentinel and LRC.

The optional sentinels identify the physical record boundaries. A decoder often omits them when it displays the fields, but a physical encoder needs the complete record format expected by the reader.

Track 1 Example #

This is a synthetic example. It uses the standard test PAN from the tool and fake name, expiry, service code, and discretionary data. It is not a Privacy.com card and it is not valid payment data.

%B4111111111111111^TEST/USER^2912501000000000?

Read it from left to right:

The real encoded record also carries an LRC character after the end sentinel when the reader expects it. The visible text form is useful for studying structure. The bit-level representation also carries odd parity for each character.

Track 2 Example #

Track 2 removes the name and format code. The same synthetic values become:

;4111111111111111=291250100000000?

Track 2 is shorter because it has no cardholder name. Many terminals read Track 2 for ordinary swipe transactions, while Track 1 provides the name field when a reader requests it.

Service-Code Digits #

The three service-code digits describe terminal and authorization behavior. They do not contain the CVV, and changing them on a real card without issuer authorization produces a malformed or misleading payment credential.

First digit covers interchange and chip preference:

Second digit covers authorization handling:

Third digit covers service restrictions:

For example, 201 means international interchange with chip use where feasible, normal authorization processing, and no service restrictions. The decoder exposes each digit separately so you do not have to memorize the table.

LRC and Parity #

The LRC is a check character, not another field to invent. The encoder XORs the data value of each character from the start sentinel through the end sentinel. It converts the result back into the track’s printable character range and reports the encoded odd-parity bits separately.

Track 1 uses a six-bit ALPHA character set. Its data value is the ASCII code minus 0x20. Track 2 uses a four-bit BCD character set. Its data value is the low nibble of the ASCII code. Applying the Track 1 mapping to Track 2 produces the wrong LRC.

The decoder’s Include calculated LRC option adds the printable LRC character to the output. Its breakdown also shows the LRC bit pattern with odd parity. Use this to learn how a reader checks the record, not to bypass an issuer’s controls.

Writing Synthetic Cards for Testing #

Use the decoder to write test strings, not live payment cards. The tool accepts fields, rebuilds Track 1 and Track 2, adds optional sentinels, and calculates the LRC. It runs locally in the browser.

1. Open the Magnetic Stripe Decoder and Encoder .
2. Select Load Test Card. This fills the tool with the synthetic PAN 4111111111111111, the name TEST/USER, expiry 2912, service code 201, and test discretionary data.
3. Enable Include start and end sentinels to display the physical record boundaries.
4. Enable Include calculated LRC to append the calculated check character.
5. Enable Split discretionary data into PVKI, PVV and CVV only to see how a nine-digit synthetic field is displayed. Those labels are issuer conventions, not a universal Track 1 or Track 2 layout.
6. Change the name, expiry, service code, or synthetic discretionary data. The output updates as you type.
7. Compare the decoded fields with the generated strings. Clear the fields when finished.

For a synthetic Track 1 exercise, use:

PAN: 4111111111111111
Surname: TEST
First name: USER
Expiry: 12/29
Service code: 201
Discretionary data: 000000000

For a synthetic Track 2 exercise, use the same PAN, expiry, service code, and a numeric discretionary field. The generated Track 2 string omits the name because Track 2 has no name field.

Do not copy a live Privacy.com PAN, expiry, CVV, or discretionary value into a writable card. Privacy.com describes its product as virtual card numbers created through its website or app. Its official page does not present the service as a magnetic-stripe-writing system, while a virtual card number is not proof of an issuer-authorized physical stripe record. A writable test card containing a live credential creates a duplicate payment instrument and violates issuer terms or payment rules.

The safe boundary is simple: use the tool’s built-in synthetic sample, use a lab card with dummy values, and use an issuer-approved physical card when you need to pay in person. Do not attempt to turn a Privacy.com virtual card into a physical swipe card.

What a Virtual Card Changes #

A virtual card is a second number standing in front of the first one.

When you pay with a virtual card, the merchant receives a number, an expiry, and a CVV belonging to the virtual card. Your real PAN never reaches them. Practically, the change shows up after a breach:

What it does not change matters as much. Your bank still sees the transaction. The card network still processes it. The issuer still holds your identity, because anti-money-laundering rules require verification. A virtual card reduces merchant-side exposure. It is not a way to spend anonymously.

The distinction trips people up constantly. If your threat model includes the issuer or the network, a virtual card changes nothing about it.

What the Merchant Still Sees #

A virtual card masks the funding account and the original PAN. The change does not erase checkout data.

Privacy’s support documentation lists the card data shared with a merchant: the 16-digit card number, expiration date, CVV, and billing address entered at checkout. The merchant also sees the name you provide. Read the official explanation of merchant-visible data before treating a virtual card as an identity shield.

The practical boundary is simple. A virtual card reduces reuse of card credentials. Your name, shipping address, merchant account, browser session, and other details submitted outside card fields stay visible to the merchant. Separate merchant accounts and email aliases help limit cross-site identity linkage. A virtual card alone does not provide this separation.

The Three Kinds of Card-Shaped Thing #

The terminology is used inconsistently, and the difference matters when you are choosing what to hand a merchant.

A mobile wallet uses a fourth mechanism entirely. When you add a card to a wallet, the wallet stores a device-specific token rather than your PAN, and the merchant receives the token. This is called tokenization, and it is why paying with a phone is safer than handing over the plastic even without a virtual card.

Network tokenization and virtual cards solve overlapping parts of the same problem. Tokenization protects the number in transit and at rest. A virtual card protects you from what the merchant retains afterwards.

Privacy.com Card Types #

Privacy.com offers four card behaviours, and they are not interchangeable.

Merchant locking is the mechanism carrying most of the value. A locked card fails at any merchant other than the one it was first used with, which means a breach at the merchant yields a number useless anywhere else.

Single-use is the stronger option where it applies. A card closing after one charge cannot be replayed at all, and it removes the need to remember to close it later.

Two operational details worth knowing:

• Shared cards lock to the first merchant they are used with, so sharing one with a family member or employee still carries the merchant restriction.
• A card is paused rather than closed. Pausing is reversible, which is useful when you want to stop a subscription temporarily without losing the card details.

Spend Limits and Controls #

Every card carries a spend limit, which is a separate control from merchant locking.

Set both a per-transaction and a monthly limit on any card tied to a subscription. A merchant quietly raising its price hits the limit rather than your balance, and you notice it from a failed charge instead of missing a statement line.

Our Personal Finance Security module places this alongside credit freezes and card tokenization as the three controls limiting what a single compromised merchant reaches.

Recurring Charges and Authorizations #

Card controls act at authorization time. Privacy describes a pending transaction as permission for the merchant to debit an agreed amount. A $0 authorization checks whether a card is active. A $0 authorization is not a completed purchase. Bank-funded transactions add a settling stage before the debit finishes. See the official transaction-state guide .

A card limit is not a prepaid balance. Privacy’s card-specific guide says the limit blocks authorization attempts above the chosen amount. The funding source is debited as transactions complete. Its rolling windows include 24 hours for daily limits, 30 days for monthly limits, and 364 days for yearly limits, with a six-day buffer for some subscription billing cycles. The official spend-limit guide documents those rules.

For subscriptions, set a recurring limit before the first charge, review pending and settling entries, and cancel with the merchant separately. Closing a card blocks future authorizations. The action does not cancel an authorized purchase or create a refund. Privacy’s pause and close guide states the same boundary.

Plans and What Each Unlocks #

Privacy.com runs a free tier alongside three paid plans. Prices and feature boundaries change, so confirm current terms before subscribing.

The free tier covers the core security benefit. Merchant locking, single-use cards, and spend limits are the mechanisms reducing exposure, and they are available without paying. The paid tiers add organisation and convenience rather than additional protection.

Foreign transaction fees differ by tier. The free tier charges 3% on foreign transactions with a $0.50 minimum, while the paid tiers do not.

This plan snapshot was checked on October 10, 2026. Pricing, eligibility, card availability, and limits are provider-controlled. Read the current Privacy.com terms before subscribing.

What Privacy.com Does Not Do #

Being clear about the limits is more useful than a feature list.

The merchant-blocking point matters in practice. Some subscription services and airlines reject card ranges they associate with virtual or prepaid cards, and no amount of configuration fixes the problem. Keep a real card available as a fallback for those cases.

The honest summary: a virtual card is a containment control for merchant-side exposure, not an anonymity tool. If you need anonymity, this is a different problem with different tools.

Who Issues the Card and Why It Matters #

A virtual card is still a real card, issued by a real bank, under a real scheme licence.

This is why the protection is genuine. The card carries the same scheme protections as any other Mastercard or Visa product, which means chargeback rights and fraud dispute processes apply normally. It is not a gift card or a closed-loop store credit.

Two certifications are worth naming because they are independently verifiable rather than marketing claims:

• PCI-DSS compliance, which is the payment card industry standard for handling cardholder data
• SOC 2 Type II, which is an audited report covering security controls over a period of time rather than a point-in-time assertion

On the business model: the company states it earns interchange from merchants and does not sell customer data to advertisers or third parties. This is the same revenue model as every other card issuer, which is worth understanding rather than treating as unusual.

The practical reason to check the issuing bank is verification. Anyone claims to run a card programme, and the issuer name on the card is what you confirm against the bank named in the paperwork.

Inspect the scheme and bank from the PAN prefix using the Magnetic Stripe Decoder , which reports the major scheme range and validates the Luhn check digit.

Account Recovery and Provider Dependency #

Account access is a separate control from card isolation. Privacy’s guidance for unrecognized activity says to contact the merchant, check 2FA and shared cards, review new-device login codes, reset the password, and contact support. The account-security guide lists those steps.

Keep the recovery email and US phone number current. Privacy requires confirmation when either detail changes, according to its account-details guide . Enable 2FA, and keep merchant names and card last-four values in a password manager. Do not place a full PAN or CVV in an ordinary notes app.

Closing your account does not erase all records. Privacy’s policy, last updated June 8, 2026, states retention periods of at least five years for identity-verification and payment-card data, six years for funding-bank information and ACH transactions, and three years for audit logs. Read the Privacy Policy retention section before treating account closure as deletion.

Privacy remains dependent on its funding bank, Plaid, ACH, card networks, and its own account systems. Bank funding uses ACH through Plaid. Privacy says unsupported banks have a debit-card funding alternative, yet eligibility still depends on a US bank or credit union and a US phone number. Its bank-connection guide and eligibility guide describe those requirements.

Funding problems affect payment operations. Privacy documents temporary account pauses when the service fails to debit a funding source, including an insufficient balance or a closed account. Its support page also states a funding-source removal does not stop transactions already authorized against the source. Read the unsettled-transaction guide and funding-source removal guide before removing a bank or debit card.

Privacy’s terms describe separate services from the company and its financial-service partners. The terms also allow additional identity information requests and account restrictions. Treat provider access and account records as part of the threat model. Do not route every essential bill through one card provider.

Using Virtual Cards Well #

The controls only help if you configure them. Six habits carry most of the benefit.

1. Lock every card to a merchant unless there is a reason not to. The lock is what makes a leaked number useless.
2. Use single-use for anything unfamiliar, including trials and one-off purchases from smaller sites.
3. Set both spend limits on subscription cards, so a price increase fails rather than charges.
4. Name each card after the merchant, so a transaction list is readable and an unexpected charge stands out.
5. Pause rather than close when you plan to resume a service, and close when you will not.
6. Keep one real card for merchants rejecting virtual ranges, so a blocked checkout does not become an emergency.

Common Mistake: treating a virtual card as a substitute for noticing your statements. Merchant locking stops one class of harm. It does not detect a compromised account at your bank, an unauthorised transfer, or a fraudulent charge on the real card behind it.

Current Control Boundaries #

Privacy.com’s current support documentation states that a card-specific spend limit blocks authorization attempts above the limit. Its spend-limit guide also describes rolling time windows. The developer card documentation lists merchant-locked cards and spend-limit fields.

Review the funding account, account recovery methods, alerts, and card list as one control set. A virtual number changes the number shared with a merchant. It does not hide the transaction from the issuing bank, the card provider, the merchant, payment networks, tax records, or a court with lawful authority. It also does not turn a debit card into a credit line or guarantee a dispute outcome.

Key Takeaways #

• A virtual card changes the number the merchant stores. Your real PAN never reaches them, which is the whole mechanism.
• It does not make the transaction private. Your bank, the network, and the issuer still see it, and identity verification is mandatory.
• Merchant locking is the highest-value feature, because a leaked number then fails everywhere else.
• The free tier includes the security controls. Paid plans add organisation and convenience rather than protection.
• The magnetic stripe stores card data in plaintext and is being removed by 2033, with US banks stopping issuance in 2027.
• The CVV is not on the stripe, which is why a skimmer copying tracks still lacks what many online merchants require.
• Some merchants reject virtual card ranges. Keep a real card as a fallback.
• Verify the issuing bank rather than trusting a card programme claim, and check the PAN prefix yourself.

Next Steps #

1. Inspect your own card’s track data and see exactly what a stripe carries: Magnetic Stripe Decoder and Encoder
2. Freeze your credit if you have not already, which is the stronger control for new-account fraud: Personal Finance Security
3. Apply the tiering discipline to decide how much effort this deserves for your situation: Prioritized Personal Security Checklist
4. Review the Privacy.com plans and current terms before subscribing: Privacy.com
5. Check whether your details already appear in a breach before assuming you are unaffected: Have I Been Pwned
6. Read the payment security checklist for the organizational counterpart: Incident Response Checklist

References #

1. Privacy.com - what virtual cards are, merchant locking, and spend limits
2. Digital card - Wikipedia, covering digital versus virtual cards, magnetic-stripe tracks, service codes, parity, and LRC
3. ISO/IEC 7813:2006 - identification cards, financial transaction cards, tracks 1 and 2 data structure
4. ISO/IEC 7813 - track field layout in detail, including sentinels and service codes
5. PCI Security Standards Council - cardholder data environment requirements
6. Consumer Financial Protection Bureau - credit reports and scores
7. ANSI/ISO ALPHA data encoding, the Track 1 character set and parity table
8. Magnetic card ISO characters, the Track 1 and Track 2 sets side by side
9. Reading magnetic card data, a practical walkthrough with a live card scan
10. Privacy developer documentation - card types, states, and spend limits
11. Privacy support - information shared with merchants
12. Privacy support - card-specific spending limits
13. Privacy support - transaction states and authorizations
14. Privacy support - pausing and closing cards
15. Privacy support - bank statement descriptors
16. Privacy support - connecting a bank account through Plaid
17. Privacy support - account activity and recovery checks
18. Privacy support - updating account email and phone
19. Privacy support - account eligibility
20. Privacy support - unsettled transactions
21. Privacy support - removing a funding source
22. Privacy.com Privacy Policy
23. Privacy.com Terms of Service