https://kunle.app/september-2021-card-tactics.html
Home
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.
Copy/Paste
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)
[democard]
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.
lyft://checkout?pan=4242424242424242&exp=0223&postcode=94111
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.
[walletlink]
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.
Notes
[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.
Share this essay on twitter
To get notified when I publish a new essay, please subscribe here.