In payments, strategies for identifying customers are often built around channel-specific tools, technologies, and terminology. For instance, the term "card-on-file" refers to an eCommerce business' storage of its customer's payment card information, to avoid requiring customers to re-key their credentials when placing subsequent orders.
In the brave new world of OmniCommerce however, customers often interact with merchants through multiple channels. A retailer might recognize a repeat customer by their payment card, whereas an eCommerce provider may rely on an e-mail address. A laundromat might use a phone number to bring up a customer's prior orders and starch preferences. An attribute useful for identification in one channel, may be unavailable in another. It’s time for a “re-think” of card-on-file and multi-channel payments, and developers have an important role to play.
How Did We Get Here?
At one time "In-store" was the only channel available. Over time, merchants devised other channels like mail-order, telephone order. With the advent of the web, some merchants opened an on-line channel to interact with their customers. With the proliferation of mobile devices now bringing the shopping experience to the wireless “great outdoors”, the variety of interactions between customers and merchants is increasing dramatically. In-app payments, tap-to-pay, mobile-wallets and beacon technologies are all indicators of this rapid pace of change.
The progression of payment options has led to often disconnected, parallel ecosystems of technology and middleware that interact with customers in separate, inconsistent ways. We’re fast approaching a point where growing expectations of customers require that the walls between payment ecosystems be broken down. While it is great to be a consumer in this brave new world, building for multi-channel commerce is clearly a challenge.
From “Card-on-File” to “Customer-on-File”
Ideally, mobile systems, eCommerce systems, and point-of-sale systems should share a common view of the customer. All three should be able to recognize an existing customer, allow for the creation a new customer, and all should be able to read or write interaction events associated with a central customer record.
This all sounds logical, but creating a composite customer identity can be hard to do in practice.
- Customers on mobile devices may not have the patience to key-in a lot of data, and merchants may be reluctant to ask lest they inhibit sales
- In-store customers may not want to volunteer personal information like e-mail addresses and phone numbers
- Customers often use throw away yahoo or gmail accounts for on-line interactions to avoid receiving nuisance e-mail on their primary e-mail accounts
Data veracity is an ongoing challenge. People move, phone numbers change, cards expire, devices get swapped out, and data entry errors are common.
Flexible, Extensible Schemas
A customer database that can serve multi-channel commerce needs to tolerate some level of “fuziness”. It may not be possible to populate all customer attributes with just one or a few transactions. It may take several interactions before identity can be “federated” and transactions previously viewed as discrete can be recognized as belonging to the same customer.
The database schema that underlies this type of “customer-on-file” functionality needs to be flexible and easily extensible. Merchants will almost certainly have a need to capture and store additional attributes in future including new types of tokens, credentials from new authentication services, or digital signatures from devices not invented yet.
In an age where the cost of storage is plummeting, and the cost of data acquisition (for digital transactions at least) is approaching free, a good practice is to store everything you can just in case you need it in future. This includes contact info, payment credentials (secured, of course), and customer device info; anything related to a customer that identifies them and how they interact with various touchpoints is of value.
How Customer-on-File Helps the Business
Creating a single, cross-channel customer identity provides value at several stages in the merchant – customer relationship.
The acquisition phase is where you need to build your customer database. All payment channels should access a common database to:
- Identify if a customer is new or existing
- Append to a customer's record with as many attributes as possible.
If a customer is in a retail shop, they could be incented to sign up for an email list by providing their email address, or providing their phone number and first/last name. If a customer phones into a customer service center, they could provide their mailing address or phone number. If a customer browses your website, store as much as you can including browser information, the IP addresses, and any unique device ID. The more information attached to the customer record, the better.
The conversion phase is where a centralized customer view starts to show value. When a customer is ready to buy, the merchant can demonstrate how attentive they’ve been during the acquisition stage.
Buy-online-pick-up-in-store is a powerful tool for retail and food service merchants, but requires online/offline systems to be able to quickly access customer details for efficient identification and fulfillment. Similar scenarios - buy-online-ship-from-store, buy-in-store-ship-from-warehouse, split shipments - all help to ensure successful conversion, but all depend on quick and easy access to a customer-centric system.
Developers should think about how to design systems that are flexible enough to “set the table” for the next interaction, but avoid introducing friction into the conversion process. On the eCommerce channel a fraud service provider like Threatmetrix can pass your web-application additional “telemetry” and device signature information helping you more easily identify a device if it enters your ecosystem in the future.
Retention / Up-sell
The retention and upsell phase is where a customer-centric data strategy can really pay off for merchants. Effective identification of an existing customer will increase loyalty and boost the lifetime value of the customer relationship. Is the customer returning a website purchase to a retail location? The store should be able to grab the payment credentials from the eCommerce system, process the refund, and e-mail a confirmation. Is the customer buying a pair of shorts at an outlet store? Your system should ideally present the customer’s cross-channel buying history, and identify cross-sell / up-sell opportunities.
How Do We Get There?
For developers, enabling these smart, customer-centric buying experiences starts with a common customer database. The key is to build deliberately, and assume that there will always be new channels that your customers will use to reach you. There will be specific idiosyncrasies to adapt to with each new channel, but a customer-on-file database remains central of them all.
Building a solution on a technology platform focused on a single channel runs the risk of creating a patchwork of services that will be difficult and costly to maintain and integrate.
To help facilitate this “customer-on-file” design principle, selecting payment providers that are channel agnostic will pay dividends in future. It will make it easier and more cost effective to support new channels and technologies, and it will increase the value of your solution to the merchants you serve.
Did you like this post? Click "like" at the top to tell us to make more content like this.