The company has initiated a Credit Card Data Portability Standard, starting with a small group for merchants and payment processors that intend to "meet in the middle" and provide both security and portability of the sensitive credit card authorization used by merchants to bill for services. Today, for some parties in the ecosystem, this data is locked up with payment providers due good faith efforts to achieve compliance, but what has happened is vendor lock centered around personal data.
In a not-so-distant m-commerce post, Sarah Perez covered some of the "tower of babel" challenges that occur for developers when dealing with payment processes for mobile payments.
In the organic information economy that has been built in our world, we find sometimes things that should be simple are not.
Here, we explore the concept of Data Portability means and where a dialog is taking place in the payments industry.
30,000 feet: Payment Processing Landscape
Braintree is a payment gateway that is part of the payments landscape. Here, we see where the gateway (in this case Braintree) fits in the ecosystem.
For purposes of security and liability, the merchant calls services that transact, but don't store information on the transaction. In processing this information the gateway is shielding the merchant from change in the payment system and technology framework by offering front end services to websites that connect to back-end (and PCI compliant) back ends.
For reasons of liability and data compliance, many merchants and gateways have agreed to allow the payment processor "hold" the data for the consumer. This practice has created a sense of lock and causes merchants to restart transactions with consumers by speaking with them manually. It is in this process where customers can leak out by opting out, or not confirming the continued transaction.
Braintree points out that this is effectively holding consumers data hostage.
Scope of the Data
To help us understand the scope of the portability being requested, asked the team at BrainTree to share the data fields that fall under this model and which of those fields are considered required and optional. Here is the list he shared below:
- Payment information
- Credit Card Number Required
- Expiration Date Required
- Amount Required
- Name Optional
- Address Optional - Merchants get rewarded with lower processing rates if they include the billing address, so while it's not required, merchants have a big incentive to send it.
- Phone Number Optional
- Order Information Optional
- Customer Number Optional
- Product / Service Optional
- Etc. Optional
Out of this list there is an interesting mix, both transactional and conversational on what is going on with our credit cards.
Yes, indeed, (especially if you're in Vegas) transactions can tell a story.
The Required Fields: Transaction Authorization
In the most basic form, merchants (through gateways) would receive portability in this proposed standard. That is the goal of the team at Braintree and others that support this open approach to industry competition.
At this stage, it consists of programs for merchants and payment processors to announce their intention to support portability of credit card authorization information.
For merchants it suggests they ask these questions when negotiating a contract with a payment processor and gateway.
- Does your organization adhere to the Credit Card Data Portability Standard?
- What is required of us to receive the sensitive data we process and/or store with you?
- What is the process of receiving the data and how long does it take?
- Are there fees associated with releasing the data to us?
- What data will be released and is there a time limit?
- Where can I get a copy of the terms?
In addition to these questions for merchants, the Credit Card Portability site includes suggestions for payment processors on how they can setup infrastructure needed to meet required PCI requirements for managing the sharing of sensitive information.
The Optional Fields: Transaction Authentication and Details
These optional fields above (name, address, phone number, what was purchased) are not required to enable transaction authorization in its base form.
However, considering consumer rights and privacy they are in a way the most sensitive. For example, if each field was populated with detailed text, values from a list, or microsyntax, we could easily see valuable consumer level data involved in the transaction between parties.
One are in the specification that might be nice is a focus on customers and rights of customers to have a say in how this information is stored, forwarded, and retained.
We took a few moments to consult some of the folks at the DataPortability Project (similar name, broader scope) to weigh in.
Connecting Dots: Start of Data Portability.Org Working Group
We found the DataPortability Project supportive about all types of data portability efforts. The group is is welcoming the Credit Card Data Portability effort to join as a workgroup in the project.
As this happens, it is likely that an increasingly broader voice and view into the issues surrounding the importance of data portability to businesses and consumers alike will form.
One of the active DataPortability Project efforts is focusing on Terms of Service. A team, led by Steve Greenberg is focused on the portability of personal information offered and agreed to when agreeing to use different web sites.
We can see a direct tie-in to these efforts. Where business is conducted on the web, whether transactional (Visa), learning (Google), or social (Facebook), consumer rights to a basic set of patterns around portability could center around the consumer and the agreements accepted at point of entry into a new site.
The case of credit card portability shows that industry privacy and liability can create significant boundaries between parties sharing data. This can create information lock and become a fertile ground for vendor lock in an ecosystem.
In a service-orientated world we look to simplifying processes for everything. In payments, the flash point is recurring payments and finding a balance for the many businesses that doesn't increase exposure for customers. The current state of affairs in the credit card ecosystem is a big challenge to building seamless apps between merchants and consumers.
In many ways, it seems much more challenging than the problems of "end to end control" that Apple tends to demonstrate in its business. Perhaps because Apple thinks of model driven architecture and wants to have no surprises in the user experience, it has set constraints on how applications perform.
So far, the credit card data portability effort seems like it is off to a good start. It is working on expanding its team, focusing on quick wins, and keeping it simple.
Does your gateway or payment processor support data portability?
What would it take for you to insist?
Photo credit: andresrueda