Skip to main content

TensorRail

TensorRail is one platform for accepting payments across many markets. You integrate once and reach the markets and methods 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.
  • Routing you do not build. Each payment is routed to a rail enabled for your account under the routing set up for it, and you get one outcome back on the payment and its webhook. See Orchestration and routing.
  • One commercial relationship for the methods TensorRail provides. One contract, one account, one set of balances. For those methods you do not 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 apply to every payment, and routing is account configuration rather than logic 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​

Getting help​

Wherever these pages say to contact support, they mean support@tensorrail.com, the one address for account questions, enabling a method or corridor, and anything a page tells you to ask us about. Include your merchant id and, for a payment question, the payment_id; both are on the object and in your dashboard. Your account manager remains the right person for commercial questions: pricing, new markets, agreements.

TensorRail, Limassol, Cyprus. Payment infrastructure for local and global payments.