Accept cards & ACH on Medusa —
straight through Kadima.
medusa-payment-kadima is a Medusa v2 payment provider that processes credit cards and ACH bank payments directly through your own Kadima merchant account — no middle gateway. Card data is captured in the browser with Kadima Hosted Fields, so your backend stays in PCI SAQ-A scope.
Early access The package isn't on npm yet — request access and we'll send the build and integration guide.
Most Medusa stores bolt on an aggregator and inherit its rules. Kadima runs on your own boarded merchant account — card and ACH, one provider, risk defined upfront.
Two providers,
one checkout.
The plugin registers two Medusa v2 payment providers. Use either or both.
kadima-card
Synchronous card processing. Browser-side Hosted Fields tokenize the card (PCI SAQ-A); the backend authorizes, captures, refunds, and reconciles via signed webhook. Supports saved cards, recurring, and MOTO.
kadima-ach
Asynchronous ACH bank debits. A submitted debit is authorized immediately and marked captured when Kadima's Settled webhook arrives; returns and voids are handled automatically, with PPD/CCD/WEB/TEL SEC codes.
Production-grade
from the first commit.
PCI SAQ-A by design
Card numbers are captured in the browser via Hosted Fields and never touch your Medusa backend.
Auth, capture, refund
Full lifecycle with configurable capture — auth to authorize now and capture later, or sale to do both at once.
Saved cards & vault
Tokenize and reuse cards through Kadima Customer Vault for one-click checkout, subscriptions, and card-on-file.
Recurring & MOTO
Server-to-server charges for stored tokens — recurring (MIT/card-on-file) and mail/telephone-order payments.
Signed webhooks
Every Kadima webhook is verified against a SHA-512 signature before the plugin acts on it. Out-of-order events are handled safely.
Resilient by default
Automatic retries on transient network and 5xx errors, and a defined set of retryable decline reasons.
Drop it into
medusa-config.
Register the providers under Medusa's payment module with your own Kadima credentials. (Package available in early access.)
// medusa-config.ts — register the Kadima payment providers
modules: [
{
resolve: "@medusajs/medusa/payment",
options: {
providers: [
{
resolve: "medusa-payment-kadima/providers/kadima-card",
id: "kadima-card",
options: {
apiToken: process.env.KADIMA_CARD_TOKEN,
terminalId: Number(process.env.KADIMA_TERMINAL_ID),
webhookSecret: process.env.KADIMA_WEBHOOK_SECRET,
captureMethod: "auth", // or "sale"
},
},
{
resolve: "medusa-payment-kadima/providers/kadima-ach",
id: "kadima-ach",
options: {
apiToken: process.env.KADIMA_ACH_TOKEN,
dbaId: Number(process.env.KADIMA_DBA_ID),
webhookSecret: process.env.KADIMA_WEBHOOK_SECRET,
secCode: "WEB",
},
},
],
},
},
]You supply your own Kadima credentials — API token, terminal id, and DBA id — from your boarded Kadima merchant account. No platform key, no shared aggregator.
Your merchant account —
not someone else's.
No middle gateway
Card and ACH run straight through Kadima on your own MID/TID and DBA — not aggregated behind a third party.
ACH as a first-class rail
Native bank debits with the full settlement lifecycle modeled onto Medusa payment states — not an afterthought.
Risk defined upfront
Kadima underwrites and boards you first, so a strong month doesn't trigger a freeze on funds you're counting on.
Questions developers
actually ask.
Which Medusa version does it support?
Medusa v2 only. It declares a peer dependency on @medusajs/framework ^2.0.0 and builds on Medusa v2's AbstractPaymentProvider API. It is not compatible with Medusa v1.
Does it support both cards and ACH?
Yes — the kadima-card provider handles synchronous cards (auth, capture, refund, saved cards), and the kadima-ach provider handles asynchronous bank debits confirmed by webhooks.
Is it PCI compliant?
Card entry uses Kadima Hosted Fields, so the card number is captured in the shopper's browser and never reaches your Medusa backend — keeping you in PCI SAQ-A scope.
Can I authorize now and capture later?
Yes for cards — set captureMethod: "auth" to authorize at checkout and capture later, or "sale" for both at once. ACH is inherently asynchronous: a debit is authorized on submit and becomes captured when Kadima sends the Settled webhook.
How are refunds handled?
Card refunds and pre-capture cancellations call Kadima's refund/reversal endpoint. For ACH, the plugin voids the transaction if it hasn't transmitted yet, or issues an offsetting credit after settlement (PPD or CCD SEC codes).
How does it differ from the Stripe plugin for Medusa?
Kadima processes through your own boarded merchant account with no intermediate gateway and per-merchant credentials, treats ACH as a first-class provider, and defines your risk upfront via Kadima boarding — rather than aggregating you behind a single platform key.
Is it on npm yet?
Not yet — medusa-payment-kadima (v0.0.1) is in early access. Request access and we'll send the package and integration guide.
Build it on Medusa. Run it on Kadima.
Get early access to the plugin, a sandbox merchant account, and an engineer to help you wire it up.