Unifying Payments on Stripe Across Four Operating Companies for a Global DentalTech Enterprise

About the Client

The client is a global DentalTech enterprise whose operating companies sell to dental professionals. This program covers four of those companies in the United States and Canada, taking payments in USD and CAD. Their orders run through SAP and Oracle E-Business Suite, Adobe Commerce (Magento) and Drupal storefronts, a customer payment portal, and sales and order-entry apps. Card payments relied on several legacy payment providers, including a tokenization service due to be retired.

Impact Delivered

4
Operating companies, one payment platform
12
Payment channels, one Stripe platform
2
ERPs, SAP and Oracle, served by one set of payment APIs

Standing at a Turning Point

Fragmented Payment Processing

Payments were handled channel by channel, with no shared payment layer across the operating companies. Online stores, a customer payment portal, sales apps, ERP-initiated orders and a receivables platform each connected to card processing separately. Any new rule or new brand meant more one-off integration work.

Security, Compliance and Cost Pressure

Every system that stores or passes card data sits inside PCI DSS scope, and the client wanted that footprint smaller. It also wanted to offset card processing fees with surcharges, which must follow rules that differ across US states and Canadian provinces. Meanwhile, its tokenization provider was due to be retired, so stored cards had to move without disrupting customers.

The client needed one payment platform that every operating company could share, and a faster way to bring the next one on board.

Solutioning

A Stripe-Centered Payment Architecture

Zimetrics designed a unified payment gateway that puts Stripe behind a single layer of reusable APIs. Every channel takes payments through the same APIs, and every payment flows back to the right ERP. Five design principles shape it:

  • Stripe as the one card processor for every channel in the program, with InterPayments surcharging called through Stripe APIs
  • Stripe-hosted checkout and tokenization wherever feasible, to keep card data out of client systems
  • The ERP as the system of record for orders, invoices and cash application
  • One set of payment APIs, reused by every operating company and channel
  • Webhook-driven, idempotent processing, so payment status stays consistent across systems

A Three-Layer Reusable API Model

Built on MuleSoft, the gateway separates channels from payment logic, and payment logic from back-end systems.

  • Experience APIs: one per channel (storefronts, the customer payment portal, sales and order-entry apps, ERP-initiated payments, bill pay), plus one for Stripe webhooks
  • Process APIs: payment orchestration, confirmation, orders, refunds, payment status, reconciliation, surcharging, processor routing and event processing
  • System APIs: SAP, Oracle E-Business Suite and Stripe

A new channel adds its own experience API and reuses everything beneath it.

Engineering the Transformation

 

  • Stripe Payment Intents with embedded checkout for storefronts, the payment portal and sales apps
  • Payment links by email and SMS for orders raised in the ERP
  • InterPayments surcharge calculation through Stripe APIs, with inclusion and exclusion rules set in Stripe
  • Authorization tokens and surcharge amounts carried into SAP and Oracle orders
  • Refunds, credit memos, cancellations and declined-payment handling
  • Split payments, and installment or subscription-renewal payments
  • Settlement and reconciliation, plus an order-level dashboard of Stripe activity

Stripe-hosted components and tokenization are used wherever feasible to keep card data out of client systems. Security testing checks that card numbers and security codes are never stored or logged. Webhook signatures are verified, idempotency and retry controls cover every integration, and access runs on role-based controls with managed secrets.

In the pay-by-phone flow, a Twilio IVR verifies the caller before sharing any account data, then reads out open invoices fetched from the ERP. Card details are captured through Twilio Pay and processed by Stripe, with any surcharge calculated by InterPayments. The payment is posted and cleared against the chosen invoices automatically, referenced to the Stripe payment; only unmatched payments need manual clearing.

Card processing on the client’s receivables platform moves from legacy processors to Stripe merchant accounts and is validated end to end. Stored card tokens migrate from the outgoing tokenization provider in coordination with Stripe.

Future Outlook

The gateway is built to grow. Because every channel reaches Stripe through the same APIs, the next operating company, region or payment method can reuse what exists instead of starting a new integration. Channels outside this program can join the same platform later.

Zimetrics Team Perspective

“Unifying payments is not just a processor switch. When every channel, from the storefront to the phone line, reaches Stripe through the same APIs, the business gets one way to take a payment, one way to reconcile it, and a faster path for every brand that comes next.”

Related Stories

Let's Talk

To find out more about us, email
biz@zimetrics.com or complete the form below.