After reviewing the Plastc closure note and subsequent blog posts across the tech web, it's clear that folks are angry that Plastc was not able to deliver on their promise, despite nearly $9M raised via Kickstarter (and subsequent investors). I'm not going to even begin to address the issue of meeting investor/kickstarter supporter expectations, nor do I know the specific details of the failure at Plastc, but I can share some quick thoughts on what I've seen here and why this was such a difficult problem to address.

I'm going to address this in a few chunks, namely:

  1. What is the problem being solved? How do you define the customer need?
  2. What are the technical challenges in making this work?
  3. What are the political challenges in making this work?

Lets get started...

The Problem

I believe Coin, Plastc, Swyp and others came at the problem from a specific premise, namely form and function of payment cards. People have complained for years about the bulk of their wallet, particularly the "Costanza Wallet" of the 90's. This is a fashion/comfort/ergonomic issue of simply carrying too many unitask items, likely loyalty cards, travel credit cards and building IDs.

Alongside the comfort/aesthetic issue is the concern about managing disparate payment and loyalty cards to ensure you always have the right one to use at the right time. This is manifested by the NerdWallet community at the product-by-product level, and by folks like Wallaby on the transaction-level.

These are what i'd consider the first level problems with the wallet and multiple payment/loyalty cards. Unfortunately, they solve some of the problem - not all of it. From what I've seen from these startups, they largely stopped here. There's more to consider.

Fraud is another issue that has become a growing concern for consumers and merchants. Static account number, expiration date, and CVC make it easy to replicate a card, particularly for use on POS systems that don't use EMV. The vulnerability is static data. Making any of this information dynamic requires integration points via the issuer processor and payment network to ultimately map the data back to their static account information. To add further complexity, physical cards are periodically reissued, due to lost/stolen, fraud, or just card lifecycle issues. Each time this happens, the old plastic needs to be updated to reflect the new static data.

Integration/coordination of loyalty and payment into a single swipe is another issue which consumers and merchants have identified. How do I know who the customer is, to get them their offers/coupons/etc prior to checkout, and how do I ensure that the checkout is done in a secure manner using a known payment card. Today, the two are completely disjointed in the physical world, with the exception of a handful of merchant-specific cards (particularly private label).

To sum it up, customers and merchants want four things:

  1. Something that is ergonomic/comfortable/fashionable, light, and simple to carry around
  2. Something that holds all your loyalty/credit programs in one and helps you figure out what to use when
  3. Something that adds dynamic characteristics to an otherwise static set of account data for security purposes
  4. Something that applies customer-specific offers/coupons to the transaction and then helps complete the payment

Technical Challenges

So we've identified the customer/merchant needs - now we need to describe the technical constraints for these needs.

Physical Form

Payment card manufacturing is fairly complex these days, and for good reason - plastic, particularly pre-personalization, is like raw currency. Regulation is fairly stringent around how card stock is generated, transported, stored, personalized, and discarded. Hence, all the major manufacturers operate facilities with security features that resemble the Pentagon. As one would suspect, changing process or adding new technology is difficult and takes considerable time in these environments.

By contrast, Loyalty card manufacturing, which is clearly not considered currency, can use the same underlying technology (mag stripe, bar code, smart chip, NFC, etc), and doesn't require any of the same security measures - the underlying technology is the same for both, but because the security requirements aren't there, its fairly simple and cheap to use and deploy.

One tangible example - writing to an NFC chip requires an NFC card reader/writer, which is a fairly cheap piece of hardware. Writing to an NFC chip is fairly straightforward, particularly if the data that is being written is static or coming from a single source. Hence, a loyalty database that simply spits out three or four fields of customer data to write to an NFC chip should not take any time or be too costly to build and deploy - in fact, even someone like me could do it. However, when a payment credential is used, you now have security concerns around what data is actually written to the card, where its sourced, and how it gets sent to the writer. Typically, this involves handoffs between multiple databases and multiple encryption key stores, which have to be locked/unlocked on the fly. This adds considerable complexity and time to the process.

So, what does a startup who is aggregating card data do? Hmm... They are not building relationships directly with the card issuing banks or the networks, so that limits them considerably - they're simply copying the static data to their new multi-wallet card. This becomes more complex with EMV or NFC, as they have dynamic elements, but they may be spoof-able.

Smart Wallet

Wallet cards are not new - the networks have enabled wallet cards for some time. Issuers had a difficult time handling the 'Smart' part, namely how to give the customer the ability to switch from one credential to the next, and ideally to apply some algorithm to identify the right credential to choose. For the former, a few different variations have been shown in market, including embedded physical buttons, physical button/e-ink or other screen, and e-ink or other touch screen. Obviously the more electronics added to the card, the more expensive it is to produce.

An alternative model, where a new card credential is created and used for this smart wallet, then routed to an individual card after the fact has been conceived, but not executed to my understanding. The way this might work is the customer uses a newly issued card from the startup. The card is used at the POS, somehow gets through authorization and completes the transaction. Then, post transaction but before settlement, the customer and/or startup decides which credential to route the transaction to and the transaction is conducted after the fact. This requires two critical systems to work, namely - (1) an authorization model that is approved by the networks and likely requires a new credit line established for the initial authorization, and (2) a new transaction, auth, settlement process that incorporates the original merchant POS interaction for the new credential. The former should be doable, but could get expensive to operate. The latter is particularly tricky, because of economics (the interchange may differ between the first and second cards) and logistics (how does the merchant POS input, either signature or PIN, get incorporated into the secondary process, or do you remove it entirely, and what are the implications on interchange, risk/fraud, and who owns that liability). Hard to do.

The startups have largely gone the route of adding a screen to the card and giving the customer the ability to switch credentials with a button or touch. Algorithms/logic have not been added in any iteration i've seen thusfar.

Dynamic Credentials

Tokenization, which is applied by EMV and now NFC/Mobile transactions, uses one-time credentials to ensure security for individual transactions. This is something that involves active correspondence between the issuer, network, and in some configurations, the physical device (phone or card). To make it work securely, an integration with the network and/or processor is truly necessary, but these requirements up the infrastructure required - not easy for a smaller scale startup.

I believe most startups have shied away from this effort, because its just hard to coordinate and the issuers/networks have limited appetite to support these efforts technically.

Personalization

After all these technical challenges, there's the possibility to delight the consumer with a personalized card experience - namely making a connection between merchant and cardholder at POS. This is achieved with an embedded loyalty program into the card credential, which is achieved in a handful of closed-loop systems (think Uber/Braintree). Startups have not been able to get on this as of yet, because it requires multiple different credentials to be connected elegantly, and most likely on the merchant infrastructure side of things.

Political Challenges

The issuers and networks have largely disowned these multi-wallet cards for a few reasons: 

  1. No one wants to share with another issuer/network and not have control over branding/styling of the card/experience; In particular no one wants to move from top of wallet down the row, or encourage their customers to optimize rewards at the transaction level, if it means not using their cards
  2. Issuers and Networks have largely gotten comfortable with mobile wallet as the ultimate disruption of physical plastic, and specifically of tokenization replacing physical security like EMV. The result is heavy R&D dollars in areas that encourage mobile and virtual, and somewhat limited investment in the physical form.
  3. Issuers are generally more conservative, particularly when it comes to physical security and infrastructure. They're not all that excited about partnering with startups who have a 'lean' mentality when it comes to either of these things. They are also quite conscious of their heavy investment in card infrastructure equipment, and long-term production/personalization/storage/destruction services.

Tough market to disrupt in the manner the startups have tried...