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, Brazil and Indonesia 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, 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.
What the platform covers
| Market | Methods | Currencies |
|---|---|---|
| Brazil (BR) | Bank transfer / mobile money | BRL |
| Indonesia (ID) | Bank transfer / mobile money | IDR |
| India (IN) | UPI | INR |
Currencies across the platform: BRL, EUR, GBP, IDR, INR, USD
Payment methods: Bank transfer / mobile money, Cards, Crypto, UPI
Features: Payment links, Self-serve API keys
Read this as the platform catalogue, not as your account: it is the same answer
GET /v1/capabilities gives every caller. The
corridors and methods enabled on your own account are in your dashboard. To add a market or a
method, ask us.
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.
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.
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
Payment method categories, described generally. You integrate once, with the TensorRail API.
For each category, 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. Cards work on card rails enabled for your account; the card shape is described in Security and data. Wallets and pay later follow the same pattern. What is enabled for you is in your dashboard; ask your account manager about the methods your markets need.
Mobile money
The customer pays from a mobile-money wallet, typically by approving a prompt on their phone.
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. On eligible
accounts, the customer can be given a per-payment collection account number to pay into; 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. The arrangements behind it are set in your agreement; 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:
- The customer pays in their local currency.
- The platform confirms the outcome on that rail and emits the webhook.
- The collected value is recorded to your balance for that currency, as a posting on the ledger (see Balances).
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 balances in several currencies stay 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 each 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.