Underexplored tactics for driving card adoption

September 2021

The vast majority of credit and debit cards used online and on mobile start out being typed manually, by the user, by hand. ApplePay & other tokenization schemes are changing this by making it possible to programmatically link cards in merchant payment forms, but today, the vast majority of card payments on the internet start out with a human typing out a card number. Eventually your browser, password manager, or merchant app saves the card number, and autocompletes it for you. This is an improvement, but we can do better.

This state of affairs also makes for some interesting opportunities for a new card program to drive adoption. 

Caveats here; more and more startups and big companies are issuing cards everyday, and the process of going through creating a card program is far easier than it used to be. This explosion is driven by interchange economics being quite attractive[1], which means companies with large audiences or a distribution advantage are increasingly economically incentivized to launch card programs. This dynamic is also assisted by the proliferation of issuer-processors and banking-as-a-service providers[2]. The more card issuers that exist, the more competition each will face to gain adoption. What follows are some software driven ideas for driving actual end-user adoption of your card program, that should only cost technical effort on the margin. Of course there’s an extensive set of expertise built around paying to acquire consumers - I’m not going to spend much time on that topic. At the margins, cardholder behavior (as with most consumer behaviors) often reverts to the path of least resistance. This means that if a consumer has your shiny new card, but their old one is already linked in the checkout form right in front of them, they're marginally less likely to pull out their wallet, pull out the card you’ve sent them, and type in that card number in the checkout form. Incentives help, which is why lots of card issuers spend lots of money to get you to link your card in the first place (often through general reward schemes or offers at specific merchants). Having your card linked in more places increases the odds that the path of least resistance will favor you. It also just makes your card marginally lower friction vs the other cards in a consumer’s wallet, if they don’t have to pull out their wallet everytime they're trying to spend (this is true of other instruments like account and routing number by the way - the utility of a balance increases as its spending and funding instruments are linked in more places, so when you’re issuing a new financial instrument whose lifeblood is money movement, getting it linked in more places is key). I’ll talk through software driven approaches to reduce friction and improve adoption for new card issuers.

Instant Issuance

The vast majority of card issuers or banking as a service providers now enable card programs to instantly issue virtual cards. This means, the moment a customer creates an account, you can issue them a spending instrument, and make it available to them right away to start spending. To really leverage this (at least on debit), you’ll also need an instant funding method that the customer can use to add money to the account (Won’t get into instant funding in this essay). This way, a potential customer can go from zero, to a funded spending instrument in minutes, instead of waiting 4 - 7 days for their physical card to arrive in the mail, and going through a card activation process (however simple). Even though many card programs can, only few do this, and they miss out on the lift in spend and usage available.


Most of your customers are already on their phones all day. They increasingly buy on their phone as well. And phone keyboards, while better than ever, are still error prone. So, in addition to making card details available in-app for a user, its important to make them easy to copy & paste. This will reduce the odds that the user enters the card number incorrectly. and on the margin, make it more likely they’ll use your card (vs. any other card in their wallet). I’ve seen this more over the last year than prior, but it’s been possible and easy for a long time, and many new programs just don’t do it. For example, Robinhood has a well designed card tab with really rich, deep functionality in app including add to apple wallet, spend alerts and the ability to order a physical card. But even today, you can’t copy the card number in the app (not picking on Robinhood here - just pointing out the low hanging fruit).

Push Provisioning of Apple Pay / Google Pay

Instant issuance + instant funding gives your customers the option to spend as soon as they open their account. Copy/Paste makes it marginally easier for them to link their cards in checkout. Both of these help prior to the physical card arriving, but are somewhat bounded to online commerce (imagine trying to type in a card number in the checkout line at Target. You might do it, but people will think it’s weird, and the marginal awkwardness means most people won’t do it).

Apple Wallet & Google Pay make your virtual card available anywhere there’s tap to pay, which, increasingly, is everywhere. What this means is, your customer can go from zero, to spending real money in the real world, in minutes. The majors (Chase, Amex, BofA etc) are only just starting to do this in the past couple of years, with relatively clunky implementations. A smooth implementation of this won’t save your program, but you’ll be doing better than most card programs out there today. The original implementations of Apple Pay required cardholders to type their card number manually into Apple Wallet, which is as error prone as typing it into a checkout form. In many cases, you even had to talk to someone at a call center to verify your identity before you could spend. With push provisioning a user can add their card to Apple Pay or Google Pay right from your mobile app, and also handle the verification step electronically. Like with instant issuance, this feature is table stakes - even most incumbent issuers now have push provisioning. During the early days of the Cash Card, as part of product testing, we’d go to the CVS down the street and try to go from account opening to funding + spending via ApplePay all while in the checkout line - and use that ApplePay card to pay for the transaction. Back in early 2017 we could routinely do this in under 3 minutes.

Add cards to autofill

A ton of commerce happens on mobile web. As a result most browsers have an option to autosave all card details except the cvv. As a new card issuer, you can create a component that pushes your card directly to the browser to be saved, and you can include this in your onboarding/issuing process so that once a user opens an account, they’re prompted to save the card to Safari/Chrome, and it’s available for further use. The demo below is meant to illustrate how this might work (even though all the logic is handled on the client, please use the sample card number in the demo, and don’t use your real card). Also, make sure your browser is set to save credit cards for autofill.

Demo #1: Add a card to autocomplete
4242 4242 4242 4242
James Bond
EXP 06/40 CVV 123
Add Debit Card to Your Browser   
Here's how it should look (in case your browser settings don't allow autofill)

One more weird trick (this is pretty arbitrary) - you can save the card with a label starting with the letter “A”. Safari and Chrome rank a user’s saved cards alphabetically when you come across a checkout form, so labeling the card with “A” will ensure it shows up first.

All the tactics described thus far don't require permission or coordination with any other party - as a card issuer you can do this today, and no one can stop you[3]. The remainder, need quite a bit of coordination and thought to get right.

Profile linking

On web, with an agreement between issuers and merchants, deeplinks can be used to automatically fill out payment profiles (the section in every ecommerce site that you use to update your card, shipping address etc). Again, the objective here is to, on the margin, reduce the odds that a person mistypes a card number. It's good for the merchant because they're more likely to complete the sale, and it's good for the issuer because they'll earn the interchange. This does come with some PCI scope issues (described below) but for larger merchants, this is less likely to be a problem. Demo behind the button (relies on a janky/borked version of the Stripe checkout).

Demo #2: Autofill merchant profile

Autofill Payment Profile   

App-to-app deep linking

Of all the tactics, this is the most technically complex, and requires some merchant < > issuer coordination. Mobile checkout forms could be set up to accept deeplinks. If this existed, card issuers could directly insert their cards into mobile apps and webforms. This would solve a few problems for every party involved:

  • Fat Fingering: So often a consumer types in a card number and fudge 1 digit, and it fails the luhn check, and you have to start from scratch. As a card issuer, these failures are invisible to you because most checkout/card linking forms do basic luhn validation on the client, and the card verification call is never sent to the network as a result.
  • Card issuers want you to use their card: Every bank/credit card company/card issuer makes money (via interchange) when you spend on their card.
  • Merchants want a valid card linked: Every company that gets paid wants a valid card linked so you can buy their stuff
  • Consumers want convenience: whenever you’re about to pay for something online, you don’t want to have to go fishing for your wallet.

Everyone involved is incentivized for this to exist, but there’s a cold start problem; merchant app checkout forms aren’t properly set up to receive a card deeplink (even though they’re set up to receive other types of deeplinks). Card issuer apps broadly don’t currently host payment card details (as described above). Cash App pioneered this (having a customer’s card number available in app), and it’s been wildly successful. Brex, Point, Revolut, Robinhood and Empower followed by making a card number available in-app and it’s now a default for neobanks. For incumbent banks, this still doesn’t exist (just log into your Chase or BOFA account and try to find a card number). For companies that already make virtual cards available in app, what we’re about to describe is relatively straightforward.

The ideal experience

As n approaches infinity, we can/should live in a world where no one has to type in a card number into a checkout form. What this looks like is:

  1. You want to add your payment card to Lyft
  2. You head over to {neobank}’s app
  3. You tap “Add Card” and it pulls up the Lyft icon
  4. You tap the Lyft icon, get a biometric auth, and you’re taken directly into the Lyft app’s payment form, with all the values (PAN, CVV, Expiration date, and Zip) prefilled.

This means as a consumer, you can run through this entire experience on your phone, without needing to grab your wallet or type 28 digits manually to add your credit card (admittedly this isn’t by itself the hardest thing in the world to do - it’s just a waste because it can be done better). 

How it could work Option 1: Client Side Only

To do this, you’ll need a checkout form that can handle a deeplinked URLs in a format that hands the card details over as url parameters. Will use Lyft as an example here, but this standard can be applied to any mobile merchant that uses universal links, or any checkout form on the web (this is similar to the checkout linking URL used in Demo #2 above - the big difference is you'll need app handling.


Any merchant could accept the same standard deeplink format with the following parameters

  • Pan
    • Primary account number (also known as the 15 or 16 digit card number)
    • 15-16 digits
    • Integer
  • Exp: 
    • Expiration date in mmyy format
    • 4 digits
    • Integer only
  • Postcode:
    • Postal Code or Zip code. 
    • Alphanumeric string

In addition, merchants could do some basic luhn validation on the card number coming in (this already happens a lot - Stripe’s checkout SDK handles this on the client for example_. Shouldn’t be necessary as these links would primarily come directly from a card issuer’s app, but it’s always a good check. Card issuers could maintain a list of merchant apps that they deeplink into, and that list would only grow over time.

How it could work Option 2: Server/Token exchange

The big difference between option 1 and option 2 is, option 1 requires an exclusively client side integration (which is more lightweight) but you'll be passing raw CVVs in the URL. I think operationally you really could minimize the operational loss from financial fraud as long as you're locking the cards to a single merchant (so that if it gets used at an unintended merchant, you can automatically block the transaction). That being said, from a policy perspective, an organization with a solid infosec discipline will probably not allow you to ship any secret encoded in a URL parameter. Solving this will require a server side integration, but the experience to the cardholder would be the same:

  1. You want to add your payment card to Lyft
  2. You head over to {neobank}'s app
  3. You tap "Add Card" and it pulls up a "Link to Lyft" button. You tap this - it's a Lyft:// url with a token in it. Depending how you implement this, the token can include everything from the server endpoint to hit,instruments available to be requested from that endpoint, etc.
  4. Lyft app receives the click when user taps it, unpacks the URL to obtain a server endpoint to hit for card / instrument data
  5. Lyft server calls neobank server to obtain card data and performs the link

In this approach, you're not sending card details in the clear. In addition, it opens up a bunch more possibilities; the token can specify any kind of money movement credential for the merhcant to request including ACH, crypto, SORT codes etc. This means in addition to pure ecommerce payments, use cases like prefilling ACH credentials into a payroll service (which, any bank or program that accepts deposits also wants) also become viable.

For payment cards specifically, step 5 could probably be handled via existing tokenization protocols, assuming you could a) find a spot in the iso 8583 message spec to communicate the specific neobank details whose cards you're requesting and b) get the card networks to agree in a timely manner. This is also something a company like Stripe is incredibly positioned to build, as it already has developer platforms for instrument issuing and card acquiring, and the relationships with merchants to get meaningful distribution. Main worry about the tokenization route is that getting the card networks to agree means you'll ship in 2030. In addition, you can't kick off token insertion in the issuer app, and it's not usable (at least not yet) for non card payment instruments like ACH.

The future

With this foundation in place you could build a checkout form that dramatically simplifies the card linking flow. As card issuers adopt this standard, any merchant could maintain a list of card issuers that use the standard, and develop a flow that “requests” a card for the customers use. That would look like

  1. Head to Airbnb payment form
  2. The payment form lists the card issuers that have adopted the standard
  3. You pick one from the list with which you have an account. This initiates a “request” to the card issuer app
  4. You’re taken directly into the card issuer app which has a flow set up for merchants to request cards
  5. Card issuer does the appropriate user + app authentication and returns a button which surfaces the deeplink
  6. You tap the button and you’re taken back to airbnb where your card details are prefilled
  7. From inside the merchant app, you hit “Buy”

I suspect the most resistance to this will come from incumbent card issuers. Today the biggest card issuers in the US are Chase, Wells, and BofA, and as organizations they haven't yet grokked that they can and should do this. Most merchants and neobanks will get it, and I'd love to see them bring it to life.

Long Cards

With a system like this in place, as a card issuer you have the ability to do some thing thats both original and useful. Say you were able to issue a single use card that could be deeplinked into Uber/Airbnb/Amazon/Target/Walmart etc. For each merchant where you could deeplink, you’d be able to 

  1. Issue a single merchant long card (multiple uses, locked to only one merchant)
  2. Using the exact same card number, but with a unique, merchant specific expiration date and cvv (this helps the end consumer understand that the card is the same)
  3. You’d never need to surface the cvv and expiration date of a long card to the consumer (because you don’t actually want the consumer to use this card for any other merchants)
  4. Ensure the expiration date is extremely far into the future (say, 50 years)
  5. Automatically decline transactions from any other merchant, except the one this card is linked to.

The advantages of this are; the card won’t expire for 50 years, so the user won’t have to replace it in Netflix for a really long time (this matters because expired cards are a big driver of spend churn. This is great for the issuer and phenomenal for the merchant. In addition, because the card is locked to Netflix, if you see an Uber transaction on it, you’ll immediately know that merchant’s been breached. Once you encounter a breach you can immediately destroy the breached card (or blow away all cards linked to that merchant), issue new ones to your customers, and this breach won’t have impacted all the other places where your cards are linked). The existing ApplePay/GooglePay schemes kind of do this, but still today the way they're implemented in apps like Uber and Lyft, require the user to authorize the card on every ride, which is better than nothing, but still an unnecessary amount of friction.

Lastly - if you're also able to insert other moneymovement credentials (like an account and routing number for ACH use cases), nothing stops you from creating single counterparty account and routing numbers that are connected to the same balance. An example of this would be, for a person that drives for both Lyft and Uber, creating a unique ACH account number for Uber that's different from the one for Lyft, but both of which flow into the same balance for the driver.

Security Challenges

The Browser Trail

One challenge with adopting deeplinks widely; every deeplink currently re-routes via a browser, and will leave a trail of card details in the server logs of the target app, and in the browser history. There’s some technical things you can do here, but the lowest cost way to solve this is to issue a long card (locked to a single merchant with a long expiration date). This way, if the card number ever gets breached or leaked, you can decline fraudulent transactions by default (because any merchant other than the linked one should be unauthorized) at no cost to your customer, or to you. You’ll also know exactly which merchant was breached.

PCI Scope

The long cards approach will give you operational security (where you effectively will be bulletproof against fraud because you’ll be able to explicitly decline all transactions that are not from the intended merchant, and for any force posts transactions you’ll win the dispute), but will create a compliance issue. If the target app is not within PCI scope, they’re in trouble as they’ll be hosting card credentials in an unsecure area. This is true even if they’re using something like the Stripe checkout SDK; the url will route via the app first before being redirected to the card linking flow. For the largest apps and merchants, this is less likely to be an issue, as they’ll likely already be within PCI scope. For everyone else however, handling cards in a non-PCI compliant way could create problems, even though your financial risk is bounded.


What's missing

Most of the ideas discussed above rely on browser and app primitives that are a decade old or more. What doesn't really exist is a universal (or at least widely adopted) mechanism for the safe exchange of money movement (card and ACH) credentials between interested counterparties. Some private attempts at this exist with protocols like Apple Wallet and GooglePay (and I suspect the innovation has happened here because interchange provides sufficient revenue to fund experimentation). Nothing similar exists for ACH, and if you could solve this with the right abstraction, it could scale to credential exchange for non-US payment domains as well.

A Well Known URL for exchanging payment credentials

One possible exchange mechanism (to reuse another browser primitive) is a "well known URL" for exchanging payment credentials. Inspiration for this is the "Well known URL for changing passwords" [4]. The idea here is, every site could publish the format within which the site would accept payment credentials from an issuer. For example, the credential exchange URL for Target.com might look like https://www.target.com/well-known/payment-credentials and at that URL, Target.com would specify the URL parameters by which it would accept card credentials, ACH credentials, etc in a way that would persist through a customer's login (because for probably 99% of merchants, payment credentials can only be added or changed when the user is logged in). Issuers could set a backend job that scans the URL structures for the top ecommerce sites where their cardholders shop, so that whenever a new merchant adopts the protocol, the card issuer can easily prompt cardholders to add their card to the new merchant. This way, multiple issuers and merchants can have a straightforward model of data exchange without continuously coordinating through business development (which would both be unnecessarily onerous and result in bespoke solutions between each pair).

Wallet Linking

This is probably a bit of a rabbit hole, but a second mechanism of data exchange is thriving in the web3/crypto/defi wallet signing world (transparently I don't yet really understand how this works - I'm just familiar with it as a user of a handful of wallets). The website to mobile wallet handshake is starting to train consumers to exchange a kind of "credential", often mediated by a QR code or deeplink. In the crypto use case, a consumer is linking their mobile wallet to a site in advance of a crypto or defi transaction like buying a .eth domain or minting an NFT. It's not that crazy that the same wallet linking mechanism could be used to exchange fiat payment credentials with an ecommerce site or merchant.

In the case I’m describing, you’re relying on the app < > web handshake purely for credential exchange not for payment processing, but once users are trained to do it, it probably accelerates crypto as a mainstream payment mechanism (high and volatile transaction fees still feel like a huge hurdle here, but it doesn’t seem crazy that someone will eventually solve fees if the consumers are already trained on the behavior). My question is whether the wallet linking, credential exchange behavior can become widespread as fast as (or faster than) crypto surpassing fiat payment networks for routine ecommerce use cases.


[1] I once got asked whether card issuing could be as big as card or payment acquiring. The heuristic I use for this is, if you look at the history of card associations (eg Visa and Mastercard) you'll notice that issuers have all the leverage (Visa literally started as an association of banks, not an association of merchants). If you look at the way interchange is set up today (current Visa interchange fees for the US are here, the vast majority of interchange economics flows to the benefit of issuers not acquirers. For example, not including rebates, network fees, or the cost of processing, a Durbin exempt consumer debit issuer would earn 1.19% + $0.10 for a card present restaurant debit transaction. This means if you spend $100 at a restaurant on a Chime card, Chime earns $1.29 before fees (to their issuer processor, to Visa, etc). Interchange economics to issuers are only ever negotiated in court. In contrast, merchants will constantly negotiate down what they pay Square, Stripe, Adyen and other payment acquirers, so much so that the largest merchants pay interchange (whats shown here) plus pennies. Payment acquirers/merchant processors essentially make no margin on large merchants. But their COGs is fixed by Visa and Mastercard, and the vast majority of interchange paid by Stripe/Square etc, on a unit basis, flows to issuers like Chime, JPMorgan, etc, not to card networks like Visa, Mastercard etc. Using this argument, I think the total pie available to card issuers is actually much greater at scale than to card acquirers. This gets murky when you layer in contractual incentives (like Visa rebates) or operational costs (like fraud and dispute processing) but the general point stands. Ultimately this means that there's incredible economic incentive for companies to get into issuing as they scale as I called out in Vertical Neobanks. This incentive has always been there - card programs like United, Costco and others are evidence of this. But the barrier is lower now than it's ever been (you can literally go from 0 to a funded issued card in minutes using platforms like Lithic and Unit) and getting lower everyday.

[2] A relatively up to date list of banks, issuer-processors and banking-as-a-service providers is available here

[3] Code for the add to autocomplete feature is here on Github

[4] A Well-Known URL for Changing Passwords

Thanks to Dami Omojola, Jesse Wilson, Timothy Thairu, Jim Esposito, Dhanji Prasanna, Femi Omojola, and Ryan Lea for reading this in draft form and helping with the demos.

To get notified when I publish a new essay, please subscribe here.