Smart routing & cascading
The right route for every transaction.
Localpayment sends each transaction through the local connection best placed to complete it — and when a connection fails, cascades to a fallback, so a single provider issue doesn’t become your outage.
- One integration, many connections
- Automatic fallback
- Rules configured with our team
One integration, many connectionsWhat it does
Routing that works behind your integration
Routing and cascading run behind the same API you already use. You don’t integrate each local connection — we do.
Route
Each transaction is evaluated against the local connections available for its country and payment method.
Cascade
If a connection fails for technical reasons or degrades, the transaction can be retried on a fallback.
Resilience
A single provider incident doesn’t have to stop your payments.
One integration
Connections are added and maintained on our side — no new integration for you.
Rules set with you
Coverage and routing rules are agreed with our team for your countries, methods and flows.
Transparent status
Component status and incident history are public on our status page.
How it works
Evaluate, route, cascade, report
Evaluate
Each transaction is checked against the connections available for its country, method and rules.
Route
It is sent to the connection best placed to complete it.
Cascade
If that connection fails or degrades, the transaction moves to a fallback where one is configured.
Report
You keep one record and one status per transaction, whichever route it took.
Scope
What routing covers, and what it needs from you
Pay-in methods
- What is included
- Bank transfers, QR, wallets and cards as available per country
- Notes
- Confirmed per market during onboarding
Countries
- What is included
- Any of the 14 countries with local rails
- Notes
- Fallback only where a market has more than one connection
Trigger
- What is included
- Technical failures and degraded connections
- Notes
- Business declines (insufficient funds, wrong data) are not retried
Rules
- What is included
- Configured with our team per country, method and flow
- Notes
- Reviewed as volumes and markets change
Limits and pricing
- What is included
- No separate limits; the payment method’s limits apply
- Notes
- Contact sales
Your integration
- What is included
- Same endpoints, statuses, webhooks and reports
- Notes
- Nothing to change on your side
Coverage depends on the connections available in each market. Our team confirms it for your countries and methods.
Why it matters
A single connection vs. routed, cascaded payments
A single connection
- One point of failureWhen the provider has an incident, your payments stop with it.
- Technical failures are finalA timeout or a degraded connection means a lost payment.
- Every new provider is a projectAdding redundancy means another integration, contract and report.
- Fragmented dataEach provider reports in its own format.
Localpayment routing & cascading
- Fallback connectionsWhere a market has more than one connection, a fallback is ready.
- Technical failures get another routeTransactions can cascade to another connection instead of failing.
- Added by configurationNew connections are configured on our side, with no reintegration.
- One API, one reportThe same statuses, webhooks and reports on every route.
Coverage
Configured for your markets, with our team
Routing and cascading depend on the connections available in each country and for each payment method. During onboarding, our team maps the routes and fallback rules that fit your flows — and reviews them as your markets and volumes change.
- Mapped per country and payment method
- Fallback rules agreed with your team
- Reviewed as you add markets and volume
Overview
USD
1,284,560.00
+4.2%
BRL
3,420,118.40
+12.8%
MXN
8,905,332.10
+6.1%
- Pay-in · Pixorder_8F2K-1043+ R$ 1,250.00
- Payout · SPEIseller_0921− MX$ 18,400.00
- FX · BRL → USDfx_3b7q250,000.00 USD
- Pay-in · Bre-Border_9A1C-2210+ COP 890,000
Transparency
See the health of every rail
Our public status page shows real-time component status and incident history — from pay-in and payout APIs to authentication services and per-country rails.
- Real-time component status
- Incident history and updates
- Per-country rail components
- 09:41:02.11409:41:02PayIn100 INPROGRESS20084 ms
- 09:41:05.90209:41:05PayIn200 COMPLETED20091 ms
- 09:42:18.33009:42:18PayOut100 INPROGRESS20077 ms
- 09:42:40.01809:42:40PayOut200 COMPLETED20088 ms
- 09:43:00.55109:43:00VirtualAccount200 COMPLETED20080 ms
POST https://example-merchant.com/webhooks/localpayment
x-Signature: HMAC-SHA256 3f9a1c0e…b47e2b
{ "transactionType": "PayIn", "transactionFlow": "DIRECT",
"data": { "externalId": "order_8F2K-1043",
"status": { "code": "200", "description": "COMPLETED" } } }For your teams
Built for the teams that own payment performance
Product & growth
Cascading gives technically failed payments another route, without changes to your checkout.
Finance
One settlement flow and one report, whichever connection processed the payment.
Engineering
No extra integration per connection: the same endpoints, statuses and webhooks.
Use cases
Where routing and cascading pay off
E-commerce & marketplaces
Checkout keeps converting during a provider incident; shoppers never see the fallback.
E-commerce & marketplaces —Digital goods, streaming & gaming
High-frequency, low-ticket payments where every technical failure is a lost sale.
Digital goods, streaming & gaming —Payment platforms
Offer your own merchants redundancy without integrating each local connection yourself.
Payment platforms —Fintechs & wallets
Top-ups and transfers keep flowing when a single rail connection degrades.
Fintechs & wallets —
For developers
No routing fields: the request stays the same
Routing happens behind the Create Payin endpoint. You send the same request you already send; the route and any cascade are handled on our side, and you receive one status and one webhook per transaction.
- Same request shape in every country
- One externalId, one status, one webhook — whichever route ran
- Stage mirrors production with no real money
# Create a PSE payin in Colombia (fictitious values) — routing needs no extra fields
curl -X POST https://api.stage.localpayment.com/api/payin/ \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"paymentMethod": { "type": "BankTransfer", "code": "1936", "flow": "REDIRECT" },
"externalId": "9d2b4c10-0000-4000-8000-000000000042",
"country": "COL",
"currency": "COP",
"amount": 185000,
"accountNumber": "<your-account-number>",
"conceptCode": "0003",
"merchant": { "type": "COMPANY", "name": "Tienda Ejemplo S.A.S." },
"payer": {
"type": "INDIVIDUAL",
"name": "Camila",
"lastname": "Rojas",
"email": "camila@example.com",
"document": { "type": "CC", "id": "00000000" }
}
}'Frequently asked questions
Do I need a separate integration for routing?
No. Routing and cascading happen behind the same Localpayment API you use for payments.
Which countries and payment methods does it cover?
It depends on the connections available in each market. Our team confirms the coverage for your countries and methods during onboarding.
Can I define my own routing rules?
Routing and fallback rules are configured together with our team, based on your countries, payment methods and flows.
Do you publish approval uplift figures?
No. Results depend on your mix of countries, methods and customers, so we review performance with you instead of quoting a generic number.
Does routing change my reports or webhooks?
No. You keep the same statuses, webhooks and reports, whichever route a transaction takes.
How do I find out about incidents?
The public status page shows real-time component status and incident history. Our support team is available 24/7 at support@localpayment.com.
Also on the same API
Make every payment count
Tell us your markets and methods, and we’ll show you how routing and cascading can be configured for your flows.