Dejan

A card number for every situation – instant to create, safe to use online, and disposable when you are done with it.

Product case study · Role: Product Manager · Domain: Consumer Fintech / Card Payments

TL;DR I led Virtual Account Numbers (VANs): virtual card numbers customers can generate instantly in the app – to spend online the moment they are approved, to shop at merchants they do not fully trust, and to kill a compromised number without replacing their physical card. Instant issuance cut time-to-first-transaction from about a week to minutes and became one of our strongest activation levers.

The problem

The 16-digit card number is the weakest link in card payments. Customers type it into dozens of checkout pages, store it with merchants of varying security, and when it leaks – anywhere – the whole card has to be reissued. That means days without a card, updating every subscription, and a support-heavy, expensive process for the issuer.

There is also a colder-start problem: a newly approved customer traditionally waits a week for plastic before they can spend. Every day of that wait is lost engagement at the exact moment excitement is highest.

What we built

• Instant issuance – a virtual card number available seconds after approval, so customers can spend online and add the card to Apple Pay / Google Pay before the physical card ships.
• On-demand virtual numbers – customers can create additional VANs for specific purposes, view the full number/expiry/CVV securely in-app, and copy them into checkouts.
• Independent lifecycle – each VAN can be paused or deleted without touching the physical card or any other number. A leaked VAN dies alone.
• Same account, same rewards – all VANs draw on the same underlying account, so statements, limits, and rewards stay unified.
• Controls per number – per-VAN pause and delete, plus naming and per-number transaction history for easy attribution.

How it works

The flow

From the card tab, the customer taps “create virtual card,” names it (e.g. “Streaming subscriptions”), and gets a full card number instantly. Sensitive details are revealed only after authentication and displayed through a secure view. Transactions made with each VAN are labeled with the VAN’s name in the activity feed, so customers can see exactly which number every charge came through – which also makes spotting fraud trivially easy.

Key product decisions

• Digital-first activation. Making the virtual number the default first card experience (rather than a power-user feature) is what turned VANs into an activation lever: spend on day zero instead of day seven.
• Attribution as a feature. Naming and per-VAN transaction history turned a security feature into an organizational one – customers used VANs to bucket subscriptions and trials.
• Kill without collateral damage. The promise “delete this number and nothing else breaks” had to be absolute; it is the entire trust proposition of the feature.

Under the hood (for the engineers)

• Many PANs, one account. Each VAN is a distinct card credential mapped to the same underlying account. Authorization resolves credential to account, applies per-credential state and controls, then account-level rules – all within the standard authorization latency budget.
• PCI-scoped display. Showing full card numbers in-app pulls the mobile surface toward PCI scope; the design used a secure display path so sensitive data is fetched and rendered without persisting on-device or transiting general-purpose backend logs.
• Push provisioning. Getting the virtual card into Apple Pay / Google Pay minutes after approval involved network tokenization – the wallet stores a network token, not the PAN, which adds another layer of protection.
• Lifecycle states. Active, paused, deleted – enforced at authorization time, with careful handling of recurring transactions and credentials-on-file when a VAN is killed (declines must be clean, not ambiguous errors).

My role

• Defined the product scope and the security/UX balance: what requires re-authentication, what is visible where, and how deletion behaves.
• Worked with engineering and security on the sensitive-data display path and with the issuance platform on instant credential creation.
• Positioned instant issuance as an activation play and defined the metrics to prove it, running the day-zero activation rollout with the issuance and mobile teams.

Challenges and trade-offs

• Security vs. convenience on reveal. Re-authenticating before showing card details protects customers but adds friction to the core loop. We tuned session rules so repeat reveals within a short window stayed smooth.
• Recurring payments on killed numbers. Deleting a VAN that a subscription bills against produces declines the merchant may retry for months. Clean decline responses and customer messaging mattered more than expected.
• Explaining the feature. “Virtual card” means nothing to many mainstream customers. Naming, onboarding education, and defaults did more for adoption than any functional change.

Results

• Median time-to-first-transaction dropped from about seven days (waiting for the physical card) to under ten minutes for customers using instant issuance.
• Roughly 30% of customers created at least one additional virtual number beyond their default card.
• Full-card reissues fell significantly, since compromised virtual numbers could be killed individually instead of replacing the whole card.

What I learned

The best security features are the ones customers adopt for non-security reasons. VANs succeeded where they were framed as convenience – spend instantly, organize your subscriptions, kill a number without drama – with the security benefit riding along underneath. It reshaped how I think about pitching protective features in consumer products.