How do I get access to the Kadima API?

Request a copy of the API reference using the form on the developers page. Tell Kadima what you are building and the documentation is sent over, along with sandbox credentials and an engineer who works on this gateway every day.

What can I build with the Kadima payments API?

Embedded merchant onboarding, payment links and hosted checkout, recurring and subscription billing, reporting and transaction visibility, and webhooks for real-time platform notifications. It supports cards and ACH.

Who is Kadima Developer Access for?

ISVs, SaaS companies, and vertical software platforms that want to embed payments, onboard their own merchants, and own the payment experience inside their product.

How do I get the full Kadima API reference?

Request a copy on the developers page. Kadima sends the reference over once you describe what you are building, so the documentation arrives with the right integration path, the right underwriting path, and an engineer attached to it rather than on its own.

How does Kadima handle risk and underwriting for platforms?

Kadima underwrites and defines risk upfront, including for regulated and specialty verticals, so platform and sub-merchant growth doesn't trigger sudden holds, reserves, or account shutdowns.

Kadima Developer Access — Payments API for Platforms

What you can build with Kadima

One API for the whole
payment workflow.

Embedded merchant onboarding

Onboard and verify your own merchants through the API — KYC, underwriting, and boarding handled by Kadima, surfaced inside your product.

Payment links & hosted checkout

Generate branded payment links or drop in hosted checkout so card data never touches your servers — PCI scope stays minimal.

Recurring billing

Subscriptions, metered usage, stored credentials, retries, and dunning — recurring revenue logic exposed through clean endpoints.

Reporting & transaction visibility

Query authorizations, captures, refunds, settlements, and chargebacks — reconcile and report without scraping a dashboard.

Webhooks & platform notifications

Subscribe to signed, real-time events for payments, payouts, disputes, and account changes to drive your platform workflows.

ISV / SaaS / vertical platforms

Built for software platforms that want to own payments end to end — split payments, sub-merchant payouts, and unified reporting.

Straight from the live API

Clean, predictable endpoints.

Real requests from the live API — not illustrative pseudocode. Every endpoint is bearer-authenticated.

onboarding

# Start a merchant application from a campaign
POST https://kadimadashboard.com/api/boarding-application
Authorization: Bearer <your-token>
{
  "campaign": { "id": 206 },
  "processingMethod": "Acquiring"
}

# → 200 { "id": 607, … }

charge

# Charge a card. Amounts are decimal strings, not cents.
POST https://gateway.kadimadashboard.com/payment/sale
Authorization: Bearer <your-token>
{
  "terminal": { "id": 24 },
  "amount": "39.00",
  "source": "Internet",
  "card": { "token": "<hosted-fields-token>" }
}

Two details worth knowing before you write a line of code. Amounts are decimal strings ("39.00"), not minor units — an integer 3900 is a different charge. And card data reaches Kadima through Hosted Fields, so raw card numbers never touch your server and you stay in SAQ-A scope. For the full reference, request a copy of our API — tell us what you’re building and we’ll send it over.

Building with AI?

The AI writes it.
Someone still has to direct it.

Most integrations that reach us now were drafted by Claude, Copilot, or Cursor — and the code is usually good. What it can’t know is which of its confident defaults happen to be wrong for a payments API. These are the six we catch most often. Every one of them passes a test card.

Amount units

Most payment APIs take minor units, so that’s the default a model reaches for. Ours don’t. Guess wrong and the charge still succeeds — for the wrong amount, silently.

Retries without idempotency

Generated retry logic almost never carries a stable key. The first timeout you hit in production bills the customer twice, and your logs show two clean successes.

Webhook verification

Our signature isn’t built the way the industry convention assumes. The generated verifier looks right, never matches, and gets “fixed” by deleting the check.

PCI scope creep

Routing a raw card number through a server you operate is the difference between SAQ-A and SAQ-D — roughly a weekend of compliance work versus a quarter of it.

Token lifecycle

Short-lived, single-use credentials look like something worth caching. Cache one and your first checkout works perfectly — which is why the bug ships.

Declines as one error

A soft decline you should retry and a hard decline you must not are different events. Collapse them into a generic failure and you lose revenue on one and risk fines on the other.

We wrote both of these up in full. What AI gets wrong when it writes your payment code covers the failure modes with the wrong and right versions side by side; embedding payments with Claude Code walks the integration itself. If you’d rather have someone who does this every day look at what your AI wrote — amount handling, token lifecycle, webhook verification, PCI boundary — tell us what you’re building. It takes about an hour and it has caught real money bugs.

Security & managed risk

Risk defined upfront — so your platform doesn't break.

Kadima underwrites and boards merchants with risk defined upfront, including regulated and specialty verticals others won't touch. Hosted checkout and tokenization keep card data out of your stack, signed webhooks verify every event, and dedicated merchant accounts mean platform growth doesn't trigger sudden holds, reserves, or shutdowns.

How access works

Tell us what you're building. We'll do the rest.

One short form puts the reference, a sandbox, and an engineer who works on this gateway every day behind your build — with the right underwriting path already lined up.

1

Request the API reference

One short form below. We send the full documentation over, not a sales sequence.

2

Tell us what you're building

Use case, volume, timeline. It’s what lets us point you at the right integration instead of all of them.

3

Get your credentials

We set you up with sandbox access and the terminal and campaign IDs your calls need.

4

Build with an engineer on it

We match your use case to the right integration and underwriting path.

Get Developer Access

Tell us what you’re building. We’ll send the API reference and put the right engineer and underwriting path behind it.

First name *

Last name *

Work email *

Company name *

Company website

Role / title

What are you building? *

Estimated monthly processing volume

Merchants / users expected

Timeline to integrate

Anything Kadima should know?

Request received

Thanks — your developer access request has been received. We've sent the API docs link to your email. If the use case looks like a fit, someone from Kadima may reach out.

Ready to build on Kadima?

Request developer access, or talk to our team about the right integration path for your platform.

Get Developer Access Talk to Kadima

Build payments intoyour platform.

One API for the wholepayment workflow.