The payment industry is in a state of constant flux and innovation. New payment processors, methods, and third-party services keep emerging, which, in theory, allow merchants to fine-tune their payments to meet their business goals.
However, the reality is often a little different, and many businesses have found themselves bogged down by the complexity that comes with figuring out how best to build, maintain, manage, and optimize their integrations with different payment services.
Overcoming this challenge is a primary reason merchants contact Primer.
Our team, led by Tania Pikovskaia, is dedicated to building and optimizing integrations with various parties across the payments ecosystem. This ensures that Primer has one of the most extensive and reliable ranges of integrations available.
Here, Tania talks about Primer’s approach to adding new integrations to the platform and how the team creates maximum value for merchants.
What makes integrating with various third parties so challenging for merchants?
Over the past decade, the payment ecosystem has become increasingly complex and fragmented. There are now more players in the payment value chain than ever, each functioning slightly differently with unique quirks and nuances.
No two integrations are the same. The lack of consistency creates huge issues for merchants attempting to create a unified payment stack and a consistent checkout experience.
And there are two paths we typically see merchants take as a result.
The first is attempting to patch all these services together, creating a semi-stable solution allowing them to accept payments. Typically, these businesses only pay attention to payments when something goes wrong. It’s a problematic approach that creates all sorts of risks and prevents these businesses from using payments as a strategic lever.
The other path is to throw money at the problem. We often see companies with huge teams of product and engineering folks dedicated to payments. Some have got it right and have well-oiled payment machines that add value to the business. But these are few and far between. More often than not, the team is simply maintaining the payment stack—finding the time and ability to make optimizations is limited.
How is Primer solving this issue for its customers?
Neither of the two paths I just mentioned is sustainable. There will come a time when every business reaches a point where they need to take action. And, increasingly, that answer is adopting a third-party payment infrastructure, like Primer, that builds and manages all these integrations for them.
That’s where my team steps in. Our mission is to Unlock every integration in the payment ecosystem in every market in the world.
To make this happen, we've crafted a proprietary integration framework. This framework simplifies, secures, and scales integrations through abstraction and consistent interfaces. These interfaces describe how to map from Primer's data types to third-party interfaces and vice versa.
Thanks to this framework, we can integrate with any third party in a standardized way, handle various edge cases, and provide our merchants with a unified, consistent experience no matter the services they use through Primer.
Can you provide some examples of the framework in action?
If we consider the framework purely from an integration standpoint, a good example would be nol Pay in Dubai. We’re the first provider to use their SDK. We were able to do this relatively quickly because our framework provides the necessary flexibility.
But the framework is about more than building integrations. It allows us to abstract the complexity of managing multiple payment integrations and unify them in a way that delivers a consistent experience for merchants using Primer.
Let’s take 3DS for example. We have some customers who wish to use their processor's 3DS capabilities. Our integrations accommodate this with no issues. However, the challenge for merchants is that each processor has a different flow regarding 3DS.
Some processors want you to receive and render an HTML page with the challenge during the authorization process. Other processors may require you to redirect the customer to another page to display a 3DS challenge.
It’s complex for the merchant and inconsistent for the customer. However, using our framework, we have removed this issue by standardizing all the distinct Processor 3DS flows, meaning the experience is consistent for the merchant and their customers, no matter their processor.
Recurring payments are another great example. Processors all use different ways of mapping various payment types. But we can unify this mapping using our framework, meaning our merchants don’t need to learn the unique requirements of each processor and instead can simply use the Primer standard across all their payment flows.
Primer has plenty of connections outside of payment methods and processors. Can you provide more insight into this?
Take fraud as an example. Fraud is a massive pain point for merchants. As a result, more merchants are adopting various third-party fraud tools to screen their transactions.
However, embedding these fraud detection providers across different payment flows with varying payment methods and processors is hard. So, often, we see merchants using these tools on a small subset of their transactions.
That’s not optimal and something we set out to help merchants solve. We’ve built integrations with the world’s leading fraud prevention providers so that now, with Primer, merchants can easily leverage their fraud prevention provider across all their payments. All they need to do is drop it in their payment workflow on Primer, and all the processing logic and data mapping we’ve built do the rest.
But we also want to ensure we give merchants more control if they want it. That’s why we’ve built our metadata mapper. This tool allows merchants to dictate how the additional metadata information is translated and sent to different payment providers. Fraud prevention is a perfect use case, where merchants can include specific fields that activate fraud detection and prevention mechanisms in third-party payment systems.
What else is on the team's plate?
We have a broad scope. For instance, we've been focusing on unifying and improving our decline mapping, and we've seen many positive data trends. This work has contributed to the fallback success of merchants overall, with the success rate jumping from 15% to 30%.
Maintenance and support are also as important as building integrations. We take the pain away from merchants because we handle all the maintenance. It involves upgrading the API versions for each integration whenever needed, ensuring we keep up with the regulatory requirements, mapping all the necessary fields in line with the new requirements, providing additional data, and keeping up with all the required changes. Automated testing and comprehensive monitoring ensure our integrations are healthy, and we can proactively identify and resolve any issues so merchants have the best experience.
We also strategically support and advise merchants on the most relevant payment providers and payment methods. It’s a strategic partnership, with merchants’ needs at the heart of everything we do.
What’s next for the integrations team at Primer?
We have built more than 160 integrations so far. And we’ll be building more this year. An example is ACH via Stripe, which will give our merchants a more cost-effective, secure, and convenient payment method in the US.
We’ll also continue our work to deepen our existing integrations, allowing us to support more data mappings, use cases, features, and edge cases.
However, our main priority for 2024 is to revisit and improve our framework by further centralizing core business logic. As a result, future integrations will be as "thin" as possible and configuration-driven.
These steps will allow us to add new integrations that fit the existing business logic even faster— such as authorizing payment, creating customers on the 3rd party side, canceling payment, etc. It’ll also make enabling new features and capabilities much easier and faster.
It’s an exciting step, which, in line with the optimization of our development model, will mean we can scale effectively to hundreds or thousands of integrations.