Consent Preferences

Custom Payment Engine for a Global Medical Technology Company

Unifying multi-country payment providers to cut costs and scale seamlessly.

Quick Insights

The custom payment engine that enabled:

Cost savings of up to $100 million

in operational expenses.

Compliance-first payment design

with tokenization, masked card data, and provider-side 3D Secure handling.

3–4 week provider onboarding

for faster integration of new payment methods and markets.

Seamless global expansion

to Asian and six European markets.

Client

The client is a global medical technology company operating multiple ecommerce stores across international markets. Its digital commerce ecosystem supports different business scenarios, customer groups, and regional payment requirements, making payments a critical part of both daily operations and global expansion.

Client Need

The client’s payment landscape had become fragmented across multiple stores, countries, and provider setups. Each storefront relied on its own combination of payment methods and local requirements, which increased operational costs, complicated management, and made expansion into new markets slower and more resource-intensive.

The client needed a more unified payment model that would simplify operations across stores, reduce duplication, and lower the cost of supporting multiple regional payment flows. At the same time, the solution had to remain flexible enough to support local payment methods, country-specific requirements, and future global growth.

Technical Specifics

The solution had to work within a distributed payment infrastructure, accounting for:

  • three independent ecommerce storefronts, each with its own payment flows and business context;
  • multiple regional payment providers with different technical requirements, merchant setups, and local payment methods;
  • country-specific payment behavior, which meant the same centralized solution had to support different market rules without duplicating integrations store by store;
  • SAP Commerce-based ecommerce flows, where payment handling had to fit into the existing platform landscape;
  • PCI DSS constraints, requiring secure transaction design without storing sensitive payment data.

This required a payment architecture that could decouple storefronts from payment complexity, centralize transaction handling, and remain scalable enough to support future expansion without repeated rework.

Solution

As part of a custom ecommerce development initiative, Expert Soft worked with the client to build a centralized payment engine that unified payment handling across multiple ecommerce stores and regional payment providers. Instead of maintaining separate payment logic inside each storefront, the solution introduced a shared layer that could process transactions in one place while still supporting country-specific payment methods, merchant configurations, and operational requirements.

Process

Early stage

At the initial stage, the payment engine relied on a more direct integration model, where provider-specific logic was tied more closely to individual payment flows. This allowed the solution to cover the client’s immediate payment needs across different stores and markets, but it also meant that scaling the architecture further required more effort as the number of providers and use cases grew.

Evolution

As the solution matured, the architecture was strengthened with a central routing layer that handled provider selection and transaction delegation through a shared structure. This reduced duplication across integrations, made the payment logic easier to manage, and improved the engine’s ability to support new providers and additional regions, reducing integration time by half.

00 / 00

Over time, the payment engine evolved from a custom integration layer into a reusable payment foundation that could support multiple storefronts, local payment requirements, and ongoing global expansion more efficiently.

The engine was also designed to operate reliably and safely in a payment landscape where provider behavior was not always consistent and compliance constraints had to be treated as part of the architecture rather than as an afterthought. The solution incorporated several mechanisms at the core level:

  • normalized provider errors in the core routing layer, so vague or inconsistent provider responses could be translated into clearer, more predictable system behavior;
  • retry logic with preserved user context, allowing failed transactions to be retried without forcing users to restart the flow, rebuild the cart, or re-enter payment details;
  • token-based payment handling, especially for recurring payment scenarios, so raw card data never has to be processed or stored directly in the system;
  • masked card data storage, where sensitive values such as CVV were excluded entirely and only non-sensitive card references were retained;
  • provider-side 3D Secure flows, keeping sensitive authentication data outside the payment engine and within the appropriate security boundary;
  • PCI DSS-aware architecture, where compliance requirements were treated as a design constraint from the outset rather than added later as a separate control layer.

This made the payment engine not only easier to scale across providers and regions but also more resilient in day-to-day operation, where transaction stability, secure data handling, and graceful recovery from failures were essential.

Payment Engine core features

The payment engine combined customer-facing payment functionality with the operational capabilities needed to manage transactions, subscriptions, and payment-related workflows across multiple stores and markets. Its core features included:

Features

Automated customer notifications
The engine sent email notifications for successful payments, card expirations, and subscription updates, helping keep customers informed at key stages of the payment lifecycle.
Reporting and transaction visibility
Built-in reporting supported daily, monthly, and post-transaction views for finance and operations teams, making it easier to track payments and monitor payment activity across the system.
Customers could link payment methods for recurring payments, allowing subscription-based transactions to be processed more conveniently and with less manual effort.
User analytics
The system captured behavioral signals, such as link clicks, form interactions, and error messages, giving internal teams more insight into how users moved through payment flows.
A dedicated support interface allowed the team to assist customers with subscription creation and order-related payment actions without relying on manual workarounds outside the system.
Multi-merchant payment handling
To support invoice payments tied to different organizations and merchants, the engine included a parent-cart capability that grouped multiple merchant carts into a single virtual payment container while remaining compatible with SAP Commerce session limits.

Integration Specifics

The payment engine supported multiple providers across regions through one centralized architecture, allowing the client to handle local payment methods without maintaining separate payment logic in each storefront.
The core provider ecosystem included:

  • Checkout.com for the US and broader international payment scenarios;
  • Cybersource for Brazil;
  • Inicis for Korea, including virtual bank accounts;
  • Softbank for Japan;
  • Ingenico for India, and more.

Several integrations also came with provider-specific challenges:

Challenges

Provider extensions that did not fully support real business scenarios
In some cases, vendor-provided extensions or SDKs were not flexible enough to support the required transaction logic, which required custom code changes beyond the intended extension behavior.
Korean payment flow requirements
Expanding into Korea required support for virtual bank accounts, a common local payment method. To reduce implementation risk, the flow was first validated through a proof of concept before being rolled out into full production behavior.
Inconsistent provider behavior and limited testing conditions
Some providers introduced integration complexity through incomplete test environments, non-standard API behavior, or unclear error handling. These cases required additional adaptation in the engine to keep payment flows predictable and operationally stable.

A separate migration challenge emerged when the client moved from Cybersource to Checkout.com. Because PCI DSS compliance prohibited storing full card details, the system relied on payment tokens provided by the processors. To preserve payment continuity, custom scripts were developed to migrate and correctly map those tokens between providers, ensuring that payment information remained usable and accurately linked after the transition.

Solution Global Expansion

The centralized payment engine made regional rollout significantly easier by reducing the need for store-by-store payment integrations. Once the shared architecture was in place, new markets could be connected faster through provider onboarding and localized payment configuration rather than rebuilding payment logic from scratch.

This helped shorten provider integration timelines to around 3–4 weeks, making expansion into Asian markets and six European countries faster and more predictable while keeping payment operations more consistent across regions.

Outcomes

Cost Reduction
The centralized system eliminated the need for individual store integrations, saving the client up to $100 million in operational costs.
Faster Global Expansion
The payment engine made it easier to launch new markets by reducing the effort required to support local payment methods and onboard new providers.
Lower Operational Complexity
Unifying fragmented payment flows into one system simplified management across stores, countries, and provider setups.
Stronger Payment Scalability
The client gained a reusable payment foundation that could support new markets, providers, and business scenarios without rebuilding payment logic from scratch.
Improved Backoffice Efficiency
Operational teams gained more convenient tools for managing payments, subscriptions, refunds, and transaction visibility, reducing manual workload.
01 / 02

Conclusion

By centralizing fragmented multi-country payment operations into one scalable engine, Expert Soft helped the client reduce costs, simplify global expansion, and build a more manageable payment foundation for long-term growth.

Technologies

SAP Commerce Cloud (Hybris), Java, Groovy, JSPs, JavaScript, Docker, and integrations mainly via APIs, utilizing REST and JSON.

Contact Us
All submitted information will be kept confidential
EKATERINA LAPCHANKA

EKATERINA LAPCHANKA

Chief Operating Officer