Why Tenderlane

Every team that ships in more than one country ends up writing this layer themselves.

The single-PSP integration was easy. Then Switzerland needed Twint, the Netherlands needed iDEAL, Brazil needed Pix, and the conditional logic spilled into every screen of the checkout. Tenderlane is what we wished existed the second time we wrote this.

The landscape

There's a gap in OSS payments. Tenderlane fills it.

Plot every meaningful payment SDK on two axes — open vs closed, backend-orchestration vs frontend-reactive — and the top-right quadrant is empty. Was empty.

↑ OSS ↓ CLOSED SAAS frontend-reactive → ← backend orchestration OSS · backend OSS · frontend-reactive SaaS · backend SaaS · frontend Tenderlane Stripe SDK single PSP Adyen Drop-in proprietary UI Braintree Hyperswitch Rust, server-side Primer.io Gr4vy Spreedly
The empty quadrant

OSS, frontend-reactive, typed.

Hyperswitch is OSS — but server-side Rust. Primer is reactive — but closed SaaS that sits in your payment path. We needed both halves in one library.

OUR TAKE

The right place for routing decisions is the browser, not a third party's API. If you're going to own your checkout, own the orchestration too.

The matrix

What each tool actually does.

No 'enterprise' / 'pro' / 'contact us' columns. The cells are functional, not commercial.

capability TenderlaneStripe SDKHyperswitchPrimer / Gr4vySpreedlyIn-house
Multi-PSP routing ?
Frontend-reactive (browser state) ?
Typed end-to-end (TypeScript) ?
Serializable rules (JSON, DB-able)
Open source · MIT
No per-tx fee / never in payment path
Bring-your-own UI (headless) ?
Zero-runtime-deps core
Lazy-loaded provider SDKs
Time to add a new PSP days weeks vendor vendor months
The business case

Routing is not a refactor. It's revenue.

The cost of a single-PSP checkout in a multi-region business isn't engineering time — it's authorizations that don't happen because the customer didn't see the local method they wanted.

5–15%
acceptance rate variance
across PSPs in the same market — real money on the table.
20–40%
lift on local methods
iDEAL, Pix, UPI, Twint vs card-only checkouts.
1–2 quarters
to hand-roll this
and it grows brittle the moment the next market lands.
per-transaction cut
Tenderlane is a library, not a service. Never in the payment path.
BUILD VS BUY · THE THIRD OPTION

Don't build it. Don't buy it.
Import it.

Building this in-house costs 1–2 engineer-quarters and a perpetual maintenance tax. Buying it from Primer or Gr4vy costs a per-transaction cut and a migration off in 3 years. Tenderlane is an OSS library — `pnpm add`, MIT, your code, your repo.

// total cost of ownership · year 1
Build in-house $240k eng · ongoing maint.
Primer / Gr4vy 0.4–0.8% per transaction
Tenderlane 0¢ · 1 npm install
Honest limits

When Tenderlane is the wrong call.

If one of these is you, ship something else. We'd rather you pick the right tool than pick us.

don't use tenderlane if
You have one PSP and you will never need another.

Use Stripe Elements directly. Routing layers are overhead until they aren't.

don't use tenderlane if
You want a hosted checkout you don't maintain.

Pay Stripe Checkout, Paddle, or LemonSqueezy. They're great at that.

don't use tenderlane if
You need PCI scope reduction via a hosted vault.

Spreedly or Basis Theory. Tenderlane is not a vault.

don't use tenderlane if
You run an enterprise procurement on a 9-month cycle.

OSS without a vendor backstop won't pass your security review. Primer or Gr4vy will.

Don't request a demo.
Just read the code.

MIT. On npm. On GitHub. No sales call. No "talk to us." If you have an hour and a Stripe account, you can have a multi-region routed checkout running this afternoon.

$ pnpm add @tenderlane/core @tenderlane/react @tenderlane/stripe