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.

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.