Paying for fuel at the pump sounds simple. Tap a card, pump the gas, and drive away. Payment processing, however, is far from simple. There’s a routing decision for every card, every station brand, and every payment processor involved. Each decision is made in milliseconds, and when they’re made correctly, you barely notice it happening. For one client’s commerce platform serving national fuel and convenience retailers, that routing logic had outgrown its original system. Coherent Solutions helped rebuild it.
At a glance
Client: A multinational e-commerce and payments platform.
Industry: Fintech, Energy, and Retail
Challenge: Reverse engineering a client’s original platform architecture and services to build a new platform and integration layer that supports the company’s tokenization system.
Outcome: A single, config-driven platform capable of integrating additional acquirers, banks, and tokenization providers; a dual tokenization approach to migrate acquirers to the client’s new system without disrupting transactions; and idempotency checks to prevent duplicate customer charges and vendor payments.
Coherent’s role: Embedded engineering partner, reverse engineering the existing platform, building a new integration layer, and creating supporting integrations.
Client overview
The client began as a startup in the early 2010s, building payment technology for fuel retailers. As the business grew, so did the list of banks, acquirers, and tokenization providers it needed to support. Currently, the platform serves some of the largest fuel brands in the industry, with operations spanning the United States, Canada, and New Zealand. Coherent has worked with the client as an engineering partner for over six years. Recently, the client needed to rebuild its original platform to support a new proprietary tokenization system, designed to give the company more control over card security and processing across its network.
The challenge
The client's original integration layer was built with unique code for each new acquirer. The company’s engineering team wrote tightly coupled, single-use code for each new bank or payment processor addition. While this process worked when the platform supported three or four acquirers, it could not scale to support the dozens of acquirers the business depended on.
On the existing platform, documentation was thin, and knowledge of how the system's many services communicated with one another was held by a few engineers. Before rebuilding the integration layer, Coherent's team had to reverse-engineer the platform's architecture, service by service, before it could safely make any changes. At the same time, the client was building a tokenization system to replace a costly third-party provider, which meant every existing acquirer integration would need to support both systems during the transition.
Our approach
Coherent's team owned the redesign and build of the acquirer integration layer and rebuilt the platform's institutional knowledge from the ground up. The team mapped how each of the platform's services called and depended on one another, including services it accessed indirectly. The team used the newly mapped and indexed services to bring new engineers up to speed far faster than the original, largely undocumented system allowed.
Rather than porting the existing tightly coupled code, the team replaced it with a configuration-driven model, allowing each tenant, a fuel brand or retail partner, to carry a configuration that determines which card is routed to a particular acquirer and bank. Moving forward, adding an acquirer or changing how a fuel brand or retail partner routes transactions would require a simple configuration change instead of a new codebase.
The solution
The Coherent team rebuilt the client’s platform to run on a small set of durable, configuration-driven patterns instead of one-off integrations for each acquirer. The new platform features:
Configuration-driven routing: Tenant-level configuration determines which acquirer and bank handle a given card, including cases where a card is enrolled with one provider but processed by another that shares the same tokenization system. Maintaining the platform now means updating a config, not shipping new code.
Dual tokenization support: While the client built a proprietary tokenization system to reduce reliance on its third-party provider, Coherent's team built every new acquirer integration to work with both systems, switchable through a single config key. This allowed the client to migrate acquirers to its tokenization system without a parallel rebuild.
Idempotent transaction processing: The new platform is cloud-based and message-driven rather than request-response. A message that takes longer than the default 30-second lock window to process can be picked up a second time and run again by another consumer, a normal quirk of cloud messaging that the original framework never accounted for. Coherent added idempotency checks to catch that overlap before it reached a customer.
Standardized ISO-8583 messaging: The new platform’s acquirer connections are built on a shared ISO-8583 messaging standard, layering each acquirer's variations on top. Building to that shared core, rather than treating every acquirer as a one-off, cut the effort needed to bring new acquirers online.
Split-tender and multi-source payments: Pay-at-the-pump transactions include an authorization step, where funds are held, and a finalization step, where the actual amount is charged. Supporting split-tender transactions, where a customer pays across more than one card or source, meant authorizing multiple sources at once and reconciling them correctly at finalization, a harder problem than the happy path suggests.
The impact
The client's payment infrastructure moved from a collection of hand-built, hard-to-maintain integrations to a single streamlined platform capable of supporting new acquirers, banks, and tokenization providers without requiring rewrites. The platform’s dual-tokenization approach allows the client to roll out its proprietary token system in stages, migrating acquirers without disrupting existing integrations. Additionally, idempotency checks are in place to prevent duplicate customer charges and vendor payments.
Throughout the rebuild process, Coherent’s team ensured that the platform maintained PCI compliance and passed acquirer audits. Moreover, the team improved system documentation and institutional knowledge processes that will help the client maintain compliance as the system scales. Coherent's payments team has worked with the client for over six years, alongside other Coherent teams working the same account on loyalty and on a subscription engine, which the client had identified as legacy and rewrote from the ground up to support new subscription offerings such as car washes and coffee. The payments team built the specific payment-side integration needed to support that new subscription engine, connecting it into the same acquirer and tokenization infrastructure the rest of the platform relied on.
What's next
With its new configuration-driven platform in place, the client is ready to integrate more acquirers and complete the migration to its new tokenization system. Additionally, improvements in routing, documentation, and transaction processing have reduced operational overhead and created opportunities for the client’s payments team to work on new features. Most importantly, the platform’s durability perfectly positions the client to confidently scale and increase its footprint across markets.