We build the checkout layer, so you can build the checkout.
Naturpay exists for one job: give engineering teams an embeddable, headless checkout they actually own. Not a hosted page to redirect to, not a widget to wrap — components, an SDK and a typed API that drop into your own product and read as yours from the first pixel.
What we believe
Three convictions the whole product is built on
We did not set out to build another payments dashboard. We set out to settle a few arguments about where checkout belongs, who should control it, and what good infrastructure feels like. Everything we ship is downstream of these.
Checkout is part of your product
The payment step is the most important screen in a purchase, and it should feel like the rest of your app — same type, same spacing, same behavior. Treating it as someone else's page you bounce out to is a product decision, and usually the wrong one. So we let you build it in.
Your design systemHeadless beats hosted
A hosted page is fast to start and slow to live with — it constrains your flow, your branding and your data the moment you outgrow the defaults. Headless components cost a little more on day one and keep paying you back forever. We optimize hard for the second week, not just the first hour.
Components, not pagesBoring infrastructure wins
Payments should be the least exciting part of your week. Idempotent writes, signed and replayable webhooks, predictable errors, stable contracts that do not move under you — that is the kind of boring we chase. Surprise belongs in your product, never in your payment layer.
Predictable on purposeHow we got here
Born from one bad redirect
Naturpay started as an internal frustration before it was a product.
The teams who became Naturpay had shipped checkouts on hosted pages and rigid widgets for years. Each one launched quickly, then turned into a wall: the flow could not change, the styling never quite matched, and the data we needed lived on someone else's screen. Every workaround was a hack on top of a tunnel we did not control.
So we wrote down what we actually wanted — mount the payment step inside our own UI, style every element, keep raw card data off our servers, and talk to a clean API underneath. Nothing on the market gave us all four. We built it, used it in anger, and the embeddable checkout we wished for became the thing we ship to other engineers.
Today Naturpay is a focused company with a single mandate: keep that checkout layer fast, predictable and genuinely yours. We stay deliberately narrow — the online checkout and nothing else — because depth in one surface beats a thin spread across many.
// the API we wished existed — so we built it import { PaymentElement } from 'naturpay/react'; export function Checkout({ secret }) { return ( <PaymentElement secret={secret} appearance={ourTheme} // our brand layout="inline" // our flow onResult={fulfil} // our logic /> ); } // no redirect. no iframe we can't reach.
The platform today
What the checkout layer runs on
# Stability is a feature - versioned API, no silent breaking changes - deprecations announced, then dated - every endpoint typed end to end - webhooks signed, idempotent, replayable # How a change reaches you 1. RFC in the open with examples 2. ships behind a version pin 3. docs and SDKs land together 4. old behavior keeps working
How we work
Values you can read in the API
Principles are easy to write on an about page. We try to make ours legible in the product itself — in the contract, the docs and the way changes reach you.
- Stability over novelty. We version the API and refuse silent breaking changes, because a payment layer you cannot trust is worse than no library at all.
- Docs are part of the release. A feature is not done until the reference, the SDK and a working example ship alongside it.
- We answer in code. Support is staffed by people who can read your stack trace and reply with a snippet, not a ticket number.
- Narrow and deep. We build one thing — the embeddable online checkout — and we would rather make it excellent than make ten things adequate.
In practice
What working with us actually looks like
Start in the sandbox
Grab a test key, mount the payment element and run a full flow in your own UI before a single contract is signed.
No sales gateBuild it your way
Compose the components, theme them with an appearance object, and drop to CSS for the last details. Your markup, start to finish.
Total controlTalk to an engineer
When you go live, you reach people who know the platform — for volume, edge cases and a real technical review of your integration.
Real conversationsShip and stay shipped
Run on a stable contract with signed, replayable webhooks. Upgrades are opt-in, and your old version keeps working.
No surprisesBuild your checkout on a team that thinks like you
Read the docs and run a real flow this afternoon, or write to us and start a technical conversation with someone who builds the thing. Either way, you talk to engineers.