Skip to main content

TensorRail

TensorRail is one platform for accepting payments across many markets. You integrate once and reach every market and method enabled for your account: one API, one account, one balance per currency, one set of webhooks, one error contract. You never re-integrate to add a method or a market. When a new one is enabled for you, it flows through the same integration with no code change.

One platform, one API, one account​

Everything in TensorRail hangs off a single idea: you build the create then present then confirm then webhook path once, and it carries every rail we enable for you.

  • One API and one account. Whether you use the hosted page, share a payment link, or call the API directly, it is the same account, the same balance, and the same webhooks. The base URL is https://api.tensorrail.com.
  • We enable methods and corridors on your account, based on your approved markets. The methods a customer can use are configured per account, not hard-coded in your integration.
  • You never re-integrate to add a method or a market. Adding a market later is an account-configuration change on our side, not an integration change on yours.

This is why the docs use methods like UPI, Pix, or SEPA as examples of the flow, never as a method-specific integration. The same path carries mobile money, bank transfer, virtual accounts, local instant-payment rails, and crypto alike, and it carries rails not named here just as readily. The authoritative list is whatever is enabled on your own account: see your dashboard. For what the platform covers as a whole, call the unauthenticated GET /v1/capabilities catalogue — it is the same answer for every caller, not your account's list. If a market or method you need is not on it yet, your account manager can tell you what we can add.

What the integration looks like​

The whole platform reduces to one small, stable surface. This is a complete first call:

curl -X POST https://api.tensorrail.com/payments \
  -H "api-key: rail_full_test_xxx" \
  -H "Idempotency-Key: 5f0c9e2a-1b7d-4d3e-9a1c-6b2f8e4a1c33" \
  -H "Content-Type: application/json" \
  -d '{ "amount": 50000, "currency": "INR", "return_url": "https://yourshop.com/done" }'
{
  "payment_id": "pay_N5cPeGw6uS2QIMjnsjVF",
  "status": "requires_payment_method",
  "amount": 50000,
  "currency": "INR",
  "client_secret": "pay_N5cPeGw6uS2QIMjnsjVF_secret_…"
}

Present the enabled methods (hosted page or your own UI), confirm the customer's choice, forward them to the generic next_action, and treat the payment as paid on the payment_succeeded webhook. That is the entire model; the Quickstart walks it end to end in about ten minutes.

Why teams trust it​

These are the concrete properties evaluators ask about, each covered in depth in its own page:

  • Money integrity you can verify. Every unit collected posts to a double-entry ledger under your balance, and an automated reconciliation runs every hour comparing the balance against the net of that ledger. You can export the underlying collections and re-derive the number yourself. See Money integrity.
  • Safe retries, no duplicate charges. Payment creation is idempotent, and that idempotency is enforced: retrying POST /payments with the same Idempotency-Key returns the original payment instead of creating a second collection. The same contract covers refunds. See Orchestration and routing.
  • One error contract everywhere. Failures return stable ERR_NNNN codes with the same meaning across every method and market, so you write error handling once instead of learning each rail's dialect. See Error intelligence.
  • Orchestration that lifts realized approval rates. Where routing and decline recovery are enabled for your account, a recoverable decline can be re-attempted on an alternative eligible route inside the same payment, before you ever see a terminal outcome. Both are capabilities we switch on per account rather than default behaviour — see Orchestration and routing.
  • One commercial relationship. One contract, one account, one set of balances. You never contract with, integrate against, or hold accounts at any local institution.

The value​

  • Reach. Present the methods customers actually use in their market, in their local currency, without needing separate local integrations or in-country arrangements.
  • Simplicity. One integration surface, one balance view per currency, one webhook contract, and one error catalog underneath everything.
  • Resilience. Safe retries and one unified error contract are ambient on every payment. Orchestration and decline recovery are enabled per account, so a higher realized approval rate is something we switch on for you rather than something you build.
  • Trust. Every unit collected is accounted for on a double-entry ledger with automated reconciliation, and every posting is traceable back to the payment that produced it.

One platform, one integration​

TensorRail is a single platform. You integrate once and accept payments across many methods and markets, with the same API, account, balance, webhooks, and error contract everywhere. TensorRail supplies the local connectivity, so you present the rail each customer expects and the collected value is recorded to your balance for that currency — and you reach new markets without assembling them one by one.

See The platform for what that gives you.

Where to go next​

TensorRail, Limassol, Cyprus. One integration, any market.