Managing payment data: How merchants can simplify that work.

By Marco Conte

In our previous post, we looked at the jungle of providers, payment methods and data that merchants have to navigate just to accept payments today. 

Adding a new provider or new payment method is a difficult task that requires patience and strategy. Even more complex, however, is managing all of the data that comes from payment service providers (PSPs) and payment methods.  

Why are payment data so difficult to manage? 

For starters, “payment data” can mean a couple of different things. 

Payment data can refer to:  

• The information that merchants send to PSPs. This is what’s collected at checkout and can include things such as the customer’s name, email address, billing address and shipping information. 
• The information that PSPs collect during the payment flow process. This data can including payment card data, data from the issuer, data from the acquirer, 3DS data and data that fraud-detection systems produce. 

Ideally, the payment service provider’s ETL process for extracting, transforming and loading that data would output clean, understandable payment data.  

However, our experience in the industry shows this is not the case. 

The common issues merchants face when managing payment data 

Most merchants will have several PSPs they work with. A typical payment setup might include PayPal, Stripe, Adyen, Klarna and payment methods native to the markets in which the merchant operates. And each PSP has its own way of making sense of payment data. 

This creates the following problems: 

• Merchants don’t have uniform data formats. If you have three PSPs, you might see three different values for a payment with an American Express card. One might label it “credit card,” one might use “amex” and one might use “American Express”. Merchants need a data mapping tool just to reconcile those differences. 
• Reason codes don’t align. Again, different PSPs can use different reason codes to explain, for example, why a transaction was declined. Data mapping is needed once more to bring all of those disparate reason codes into some coherent grouping.  
• BIN formats are different. The six- or eight-digit BIN code from card issuers has important information. BIN data can let you derive the issuer’s name, country, card product and card type. But, again, PSPs don’t translate that information uniformly. As a result, merchants often struggle to access that information. 
• 3DS data have become more complex. With the introduction of 3DS2, there’s much more 3-D Secure data to parse. Merchants must now pore over status reasons, exemption indicators and authentication types. 

On top of this, merchants must reconcile payments at the transaction level to understand the true cost of payments. Settlement data are not easy to parse, so merchants often don’t understand the fees they are paying. 

And, of course, the rise in fraud looms large over all of these conversations. It is common now for PSPs to have fraud prevention solutions and solutions for managing chargebacks that are integrated into their services. In the event of a fraudulent transaction or a chargeback, the acquirer must inform the merchant and send over the necessary data.  

Here again data discrepancies emerge. Fraud data sent from TC40/SAFE reports and chargeback data, with dispute reason codes and the statuses that providers send over can vary from one PSP to the next.  

How merchants usually have to organize that data 

Let’s add another wrinkle to this problem. 

Merchants typically do not receive all of this messy payment data in one clean, easy-to-access place. Instead, those data arrive from a variety of sources, including:  

• The payment service provider’s API. 
• Webhook notifications. 
• Reports that the PSP sends over. 

This means merchants have to spend time and energy in ETL processes for extracting, transforming and loading data before they can begin the work of unifying the data, reconciling payment information and deriving actual business insights from it. 

Of course, this work can all be done internally. Plenty of struggles and expenses — e.g. buying dedicated software, hiring data engineers and business analysts — come with that approach. But we think we have a better way to organize and make sense of provider data. 

Congrify’s payment analytics no-code solution 

We designed Congrify to be an easy-to-use solution for managing payment data. 

 We know from two-plus decades in the industry that any such solution needs to: 

• Work with any PSP, no matter what language that PSP’s data speaks. 
• Provide KPIs and benchmarks to gauge payment system performance against. 

• Reduce complexity, not add to it. That’s why Congrify works out of the box, without any intense coding or technical integration work needed. 

If you are looking for a way to harmonize your payment data, contact us today to learn more about Congrify.