Solving For Data Fragmentation Across Processors and Brands

In the early days of a business, using a single full-service payment service provider (PSP) to process every transaction has massive appeal: it accelerates time-to-market, simplifies financial projections, and concentrates all vendor management in one place.

As transaction volumes grow, however, merchants generally come to the conclusion that they can do better with a multi-processor solution. This looks like higher payment success rates, more geographically-aligned payment methods, and, above all, an opportunity to improve profitability by arbitraging varied rate schedules.

Managing customers across a range of providers, however, can get tricky for those who don’t have a plan in place from the start.

When customers interact with a merchant more than once (either by signing up for a subscription, or making a string of purchases), they expect not to have to input their payment details every time. For the merchant, this means making an initial important choice: store the customer’s data with the processor, or to store it on their own systems.

Each comes with its own set of benefits and challenges:

• When the PSP holds the data, they assume the obligation to store it according to the PCI-DSS standard, nearly eliminating PCI compliance for the merchant. However, the merchant generally ends up with just a PSP token, meaning that all subsequent transactions must go through that one processor, effectively eliminating many of the benefits of the multi-processor approach
• When the data is local, the merchant maintains the flexibility to send future transactions to their processor of choice. However, they now must ensure their payments system is compliant with PCI-DSS, which can be a significant burden.

How does data fragmentation impact payment data? 

Data fragmentation in payments generally refers to a situation where it becomes difficult to track and manage transaction records owing to the differences in data standards, agreements, and financial arrangements across a range of third-party providers.

Whether the merchant chooses to store customer data locally or with each individual payment processor will determine the complexity of the challenge. Those who leave payment data storage to the processors will quickly discover that the variety of ways PSPs report, track, and charge for their services makes financial reconciliation a tricky game of data cleansing and standardization.

On the other hand, those who keep the data locally, and appropriately track key details about each transaction, including which PSP was responsible for its processing, may find themselves putting more of their systems into PCI scope in order to manage the tracking and reconciliation processes.

There is, however, a third alternative, which is to add a programmable payments vault into the equation.

The vault can collect and store the customer’s payment data (keeping the merchant payments system out of scope), and allow the merchant to submit transactions to any downstream processor programmatically. The vault can return key elements of the transaction to the merchant, which can store it alongside the customer record, making it available for use in the reconciliation process.

With such a system in place, it becomes easier to extract details on transactions associated with each downstream processing partner and align processes with the otherwise fragmented data delivered to track progress.

Return to Top

Can we identify the same customer across portfolio companies? 

The math gets even more complicated for merchants who run more than one business: not only must they manage multiple processors, but also multiple entities using them. Our three choices of approach (store locally, store with each processor, or use a third-party vault) deliver very different experiences:

• Store Locally: By sharing a single customer database, portfolio companies can make it relatively easy to identify a single customer (by matching name, address, email, etc.). On the other hand, not only is the core payments system in PCI-DSS scope, but when multiple portfolio companies have access to the customer payment data, every system through which it passes is also brought into scope. Questions of the commercial connections between the business entities must be clearly defined, managed, and updated over time, creating a potentially expensive long-term task.
• Store with the Processor: While the customer database may still be shared, accessing the customer payment data across multiple portfolio companies may end up being impossible: most PSPs do not allow multiple organizations to access the same account. It is true that market platforms like Shopify can solve for this by providing their own customer identification approach - but this necessarily removes the option to add additional processors to the mix.
• Use a Third-Party Vault: This is likely the strongest option, as portfolio companies can share a database for identifying customers without directly accessing the payment data. A well-designed system would likely include one payment system being shared across the portfolio (a self-managed version of the market platform, if you will), with a central control to ensure a single connection point to the third party vault, so that only approved sources can request transactions be transmitted through the vault.

The challenge of identifying and sharing information across multiple portfolio companies is tricky but doable, until you take into account managing the PCI-DSS compliance. Keeping data in a third-party vault, so that it never enters the systems of the individual merchant brands, represents a very real opportunity to manage resource intensity down.

Return to Top

Managing Data Across Processors 

Working out how to share customer information between portfolio companies is one end of the challenge; working out how to use that information to support a multi-processor payment system is quite another.

A single processor can provide a non-decryptable token that, in principle, can be shared between portfolio companies and kept in a vault to avoid bringing systems into PCI-DSS scope. However, it can be used with only the processor that issued it. As such, when the merchant decides it needs to add other PSPs to enable, for instance, superior transaction success metrics in cross-border transactions, or to arbitrage processing fees, the token is of no immediate value.

Instead, each time the merchant wants to use a different processor, it would need to collect the customer’s information again. And if the merchant is committed to using processor-issued tokens, it would need to do this for each incremental processor.

By contrast, a token that is issued by a third-party vault is far more portable. When the initial cardholder data is collected by the vault, it remains under lock and key for submission to any processor the merchant may prefer. Thus, as each transaction is agreed to by a customer, the merchant can make a value judgment on the best processor to target, then instruct the vault to submit the details without bringing the underlying payments system into scope.

And, without having to reacquire the customer’s information.

While technically solvable without the use of third-party solutions, the challenge of protecting internal systems from slipping into PCI scope is challenging, complex, and constantly evolving.

The strongest approach to creating leverage, flexibility, and protection against profit-eroding compliance requirements is to use a third-party vault that securely stores customer data and makes it available for submission to any preferred processor.

Return to Top