Skip to main content

Corridors and coverage

You can accept payments in local currency over local rails, with the collected value recorded to your balance for that currency. Coverage spans markets across several regions, India, Ghana and Kenya among them, and new corridors are added as we source them. The corridors enabled on your own account are the authoritative list for what you can collect today, and you can see them in your dashboard. GET /v1/capabilities — which needs no authentication — is the wider catalogue: the markets, methods and currencies the platform supports, the same answer for every caller, so read it as coverage rather than as your account. If the market you need is not named on this page, ask your account manager rather than reading the page as the boundary. This page explains the coverage model and the payment-method families.

Coverage is activated per account

The exact countries and methods activated for your account are shown in your dashboard after onboarding, because coverage depends on your approved markets and your risk profile. Your activated corridors are confirmed during onboarding and can be extended later, so a market you do not have yet is a question for your account manager rather than a limit. Which method fits a given country can also shift with local conditions.

The one rule​

Coverage is activated per account and rendered through the same one integration. You do not choose the payment-method mix and you never re-integrate to add a method or a market. The docs use methods like UPI, Pix, or SEPA as examples of the flow, never as method-specific integrations. The same create then present then confirm then webhook path carries every rail.

Concretely: currency on POST /payments should be a corridor enabled for your account, and the methods presented to a customer are whatever is enabled for that corridor.

Create does not check this for you

A payment in a currency you have no corridor for is accepted at create. There is no corridor check on POST /payments; only a malformed currency code is rejected there (ERR_2002). The mismatch surfaces later — at confirm, as a route-configuration error (ERR_4088), i.e. in front of your customer rather than in your server logs. ERR_4088 covers any problem with the route itself, not only a missing corridor: if you bring your own processor, credentials that processor rejects surface the same way.

So validate the currency on your side before you create the payment. The dashboard already does this for Payment Links, offering only the currencies your account has a corridor for.

When TensorRail enables a new corridor for you, the only change in your system is that a new currency value starts working and new methods start rendering.

Method families​

Generic method families only. On rails TensorRail enables for you, you do not integrate, contract, or hold accounts with any underlying institution; TensorRail presents these as its own rails. (If you bring your own processor, you hold that account yourself — see Connect your own processor.) For each family, what differs is the customer's action; what your integration sees is always the same payment object, next_action, and webhook.

The families below are the ones you meet most often, not a fixed catalogue. Card and wallet acceptance is described in Security and data and the Drop-in SDK, and further local families are added as we source them, so what your markets can be covered with is worth a conversation with your account manager.

Mobile money​

The customer pays from a mobile-money wallet, typically by approving a prompt on their phone. Widely used across Africa and parts of Asia — Ghana, Kenya, Tanzania and Uganda among them. For the markets available to you, check with your account manager. Your integration sees: confirm returns requires_customer_action; the customer approves on their phone; the outcome arrives by webhook, often within seconds but sometimes minutes.

Bank transfer​

The customer is shown account or reference details and pays by local bank transfer. Dedicated per-collection virtual accounts are available and can be enabled for your account — ask us about the shape you need. Your integration sees: next_action carries what the customer must be shown; the payment can stay processing until the transfer lands, so the gap between checkout and the success webhook is longer than for instant rails. Build fulfilment on the webhook, never on a timer.

Local rails​

Domestic instant-payment and account-to-account schemes, UPI among them — the way most people in a given market actually pay. Which ones are enabled for you depends on your markets and your account, and the set is not fixed; your account manager can say what a given market can be covered with. Your integration sees: typically a redirect or in-app approval via next_action, then an asynchronous webhook. The Quickstart walks one of these end to end as the worked example of exactly this pattern.

Crypto​

Accepted and presented in checkout alongside every other method, and reported in the same place. How crypto settles depends on the arrangement configured for your account — talk to us about the shape you want.

Collect in local currency, on any enabled rail​

Whatever method the customer chooses, the path to your balance is the same:

  1. The customer pays in their local currency.
  2. The platform confirms the outcome on that rail and emits the webhook.
  3. The collected value is recorded to your balance for that currency, as a posting on the ledger (see Balances).

Where a currency conversion applies to your account, it is set in your commercial terms rather than fixed here, so ask your account manager which options are open to you. Amounts are always expressed in the smallest unit of the collection currency on the API (50000 = INR 500.00), and every credit to your balance is a posting on the ledger described in Money integrity, so a multi-currency account stays auditable rather than becoming a spreadsheet exercise.

Clearing speed​

Collections do not all clear at the same speed. How long a corridor takes depends on local banking hours, holidays, and rail behaviour, and all timing is indicative unless TensorRail states in writing that it is guaranteed. Indicative timing per corridor is shown in your dashboard and commercial terms. The pending versus available split in your balance reflects exactly this: a collection can be confirmed on its rail and still be inside its corridor's clearing window.

What to evaluate coverage on​

When you compare providers, the useful questions are not "how many logos" but:

  • Does one integration carry every corridor, or does each market add integration work? (Here: one; adding a market is account configuration.)
  • Do declines and errors mean the same thing in every market? (Here: yes, one catalog; see Error intelligence.)
  • Does money from every corridor land in one reconcilable balance? (Here: yes, one ledger; see Money integrity.)

TensorRail, Limassol, Cyprus. TensorRail operates the collection rails and presents them as its own; no underlying institution is your counterparty. This describes rails TensorRail enables — on a processor you bring yourself, that processor remains your counterparty.