The Kadima Medusa Plugin: Payments for Headless Commerce

Headless commerce gave teams the freedom to build the store they actually wanted. The catalog, the checkout, the fulfillment logic, the storefront — all decoupled, all under your control. Then most teams reach the payment layer and discover the freedom stops there. The processor dictates the onboarding, the data, the payout schedule, and how much help you get when something breaks.

That gap is what the Kadima Medusa plugin is built to close. It connects payment acceptance directly into Medusa, the open-source commerce framework, so your store can accept card and ACH payments through Kadima without routing through a generic middle aggregator. The result is a commerce stack where the payment layer is as flexible as everything else you built.

What modern commerce teams actually need from payments

Before talking about the plugin, it helps to be honest about what teams running a modern stack expect from a payment partner. After working with operators and developers across verticals, the same requirements come up again and again.

Flexibility. The payment layer should adapt to the stack, not force the stack to adapt to it. Card-present, card-not-present, ACH, recurring — the merchant decides the mix.
Real gateway access. Teams want a direct relationship with processing infrastructure, not a thin wrapper over an aggregator that can change terms or freeze an account without warning.
Stable onboarding. Approval that holds. A merchant account structured correctly with the acquiring bank from day one, so growth does not trigger a surprise review.
Transparent processing. Clear pricing and clear data. The merchant should be able to see what they are paying and why, down to the transaction.
Support beyond a help center. When a settlement looks wrong at 9pm before a launch, a ticket queue is not a plan. A real partner is.

Most aggregator-style payment products are excellent at the first ten minutes — sign up, paste a key, accept a card. They are far less reliable across the next two years, when a business develops real volume, real risk, and real complexity. That is the window the Kadima plugin is designed for.

How the plugin reduces development friction

The plugin installs into a Medusa v2 project as a payment provider. Once configured, Kadima becomes a selectable payment method at checkout, and the framework handles the rest of the order lifecycle the way Medusa already does — authorizations, captures, and refunds flow through the provider interface your developers already understand.

One integration, card and ACH

Rather than bolting on separate tools for card and bank payments, the plugin supports both card and ACH acceptance through a single Kadima connection. For merchants who want to steer larger or recurring payments toward lower-cost ACH rails, that capability is present without a second integration project.

Direct processing, not a reseller hop

Payments move through Kadima’s processing relationships rather than an extra intermediary layer. Fewer hops means fewer parties between you and your money, and a cleaner line of accountability when you need answers. It also means the merchant account underneath your store is a real, properly underwritten account — the same foundation we describe on our payment infrastructure page.

Built to match the framework’s conventions

Because the plugin follows Medusa’s provider model, it slots into the patterns your team already uses. There is no parallel checkout to maintain and no bespoke order-state machine to reconcile. The developers keep working in the framework; payments just become one more capability inside it.

The goal was never to make payments clever. It was to make payments quiet — a dependable layer your team configures once and stops thinking about, so the work goes back into the product.

Where this fits in the go-to-market picture

Speed to launch is where the difference shows up. A team building on Medusa has usually already invested in a custom storefront and a custom operational flow. The last thing that should slow a launch is a payment integration that requires its own discovery phase, its own compliance back-and-forth, and its own support escalation path.

By giving developers a provider that drops into the existing framework and giving operators a merchant account built to last, the plugin compresses the distance between “checkout works in staging” and “we are taking real orders.” For ecommerce brands and subscription businesses alike, that compression is the point.

Who should look at this

The plugin is most useful for teams that have outgrown plug-and-play payments and want infrastructure they can stand on:

Developer-led commerce teams building on Medusa who want payment acceptance to live natively inside their stack
Operators who need a stable, properly underwritten merchant account rather than an aggregator sub-account
Businesses with mixed payment needs that benefit from offering both card and ACH at checkout
Brands in specialized or higher-risk verticals that need a processor willing to support them long term — see our high-risk processing overview

Getting connected

If you are building on Medusa and want payment acceptance that behaves like part of your stack instead of a bolt-on, we should talk. The fastest path is a short conversation about your architecture, your volume, and your verticals — from there we can map the right Kadima configuration and merchant account structure for your business.

Explore our partner program if you are building integrations at scale, or reach our team at (888) 292-8555 or info@KadimaHQ.com to start a technical conversation.