Platform
One integration. Any market.
Routing, decline recovery, collection on local rails, settlement, and a ledger that balances to the cent are capabilities of one unified platform, not separate products. You integrate once and turn capabilities on as you grow.
local and global payment methods · your processors · a growing set of markets
01 Orchestration & smart routing
Every payment takes the route most likely to be approved.
You set priority, volume, and fallback rules per market, method, and amount, or opt in to approval-optimized routing that sends each payment to whichever of the processors you enable has the best recent success rate. Either way, the decision happens in milliseconds and your customer sees one checkout.
When a route declines for a recoverable reason, the same payment is retried on the next route in your cascade automatically. No code changes, no second checkout attempt.
✓Rule-based and approval-optimized routing · automatic failover across your cascade
rule · cards · high-value
priority, volume, and fallback rules per market, method, and amount
02 Decline recovery & error intelligence
A decline means the same thing, no matter who processed it.
Every processor speaks its own dialect of failure. The platform maps all of them onto 170+ unified error codes, so the same underlying decline always carries the same code, the same remediation guidance, and the same retriable flag.
That is what makes recovery targeted instead of blind: retries happen only when the code says a retry is worth making, and declines that cannot be recovered are surfaced to your customer with a clear next step.
✓170+ unified error codes · per-code remediation guidance · targeted retries
same code, same meaning, every processor
03 Money integrity
Every debit has a matching credit. The books balance to the cent.
Every movement of money is recorded as a balanced double-entry posting in an append-only ledger. Nothing is ever edited in place; corrections are new postings, so the history of every unit of money is complete and permanent.
The ledger is reconciled every hour. Any drift is surfaced as an incident to be resolved, never silently absorbed. When you ask where money is, the answer is a ledger row, not a guess.
✓Double-entry postings · append-only ledger · hourly reconciliation · drift 0.00
posting · pay_8kT2
04 Local corridors & coverage
Local rails in the markets big processors overlook.
Your customers pay the way they already pay at home, in their own currency, on the rails they already trust. Local instant rails, bank transfer, mobile money, wallets, cards, and crypto are among the methods that reach you through the same call.
We work across five regions, and the markets below are examples rather than a limit. Your integration stays the exact same call it was on day one: methods and markets are enabled on your account, not built into your codebase.
✓Local rails per market · Enabled on your account · One integration.
your integration
POST /payments
unchanged, every market
methods and markets are enabled on your account
Regions we work across
South Asia
India · Pakistan · Bangladesh · Sri Lanka
Southeast Asia
Indonesia · Philippines · Vietnam · Thailand · Malaysia
Latin America
Brazil · Mexico · Colombia · Peru · Chile
Africa
Nigeria · Kenya · Ghana · Tanzania · Uganda · Egypt · South Africa
Europe
Eurozone · United Kingdom
Payment method categories
Local instant rails
Domestic real-time payment schemes: how most people in a market actually pay.
Bank transfer
Account-to-account and virtual-account collection, including per-collection references.
Mobile money
Phone-based wallets, dominant across much of Africa and parts of Asia.
Wallets
The wallets and super-apps your customers already have installed.
Cards
Card acceptance, captured in hosted fields so card data never reaches you.
Crypto
Major assets and stablecoins, presented and reported like any other method.
Coverage and methods are configured for your account. Tell us your markets and we will confirm what we can enable.
05 Developer experience
First sandbox payment the same day you get keys.
One API covers every method and market. Take payments through hosted checkout, embed a drop-in, or call the direct API; all three sit on the same surface, so you can start simple and go deeper without re-integrating.
Webhooks are signed and retried automatically until you acknowledge them. Every failure follows one error contract: a unified error code, a link to the docs, and a flag that tells you whether a retry is worth making.
✓Sandbox from day one · signed webhooks with retries · unified error contract
$ curl -X POST /payments \
-H "api-key: rail_full_test_…" -d amount=1200 -d currency=USD
201 Created · pay_7mQ4 · status: succeeded
webhook payment_succeeded delivered ✓ signed · auto-retried
error → code · docs link · retriable: true
06 Settlement
You request. You see the fee. You accept. Then it moves.
With Direct, funds flow from your processors to you under your own processor agreements; TensorRail orchestrates and records, and never sits in the flow of funds. With Collect, collections aggregate into a balance per corridor and are settled on your request.
When you request settlement of a balance, you receive a quote showing the exact fee and the net amount, and nothing moves until you accept it. Each settlement carries a reference and moves through a clear lifecycle, and it posts to the same ledger as your payments, so the books stay balanced end to end.
✓Quote with the fee shown before you accept · settlement reference · same ledger as payments
07 Configurable 3DS
Step up when it protects you. Stay frictionless when it does not.
3DS is a dial, not a switch. You decide when authentication is required, per market, method, and amount: keep low-risk payments frictionless, and step up high-value or unusual ones with a challenge.
The platform handles the full authentication flow, and every outcome comes back through the same API and webhooks as any other payment event.
✓Per-market, per-amount 3DS rules · frictionless where possible, step-up where it counts
your rules per market, method, and amount · not one-size-fits-all
08 Hosted card capture
Card data goes into hosted, isolated fields. Your servers see a token.
Cardholders type their card number into secure fields provided by the processor infrastructure, embedded in the TensorRail-hosted checkout. Card data never touches your servers or ours.
What you receive is a token you can charge, save for returning customers, and route across processors like any other payment method.
✓Hosted, isolated card fields · tokens on your side, never raw card data
your checkout page
hosted, isolated card fields
card data stays in the hosted fields · your servers see a token
09 Recurring & one-click
Save a method once. Charge it again with no re-entry.
Save a customer's method on their first payment and get back a token you store against their record. Returning customers pay in one click, and subscriptions, renewals, and usage billing are charged off-session with no customer present.
It is the same payment API either way, so recurring rides the same routing, decline recovery, and webhooks as every other payment. You hold a token, never the underlying credential, so the card details never reach your servers.
✓One-click for returning customers · off-session recurring charges · tokens, never credentials
your servers store a token, never the credential
Security and operational controls documented and available on request. Read our security overview
One platform. Your markets.
Tell us where you sell and how you want to get paid. We will map it to the platform.