Payment routing across our own network and partner routes

ATLAS builds and runs its own trader network. Vetted traders, each with a USDT deposit, take payments on local accounts in the ATLAS network, and our ledger records every one of them. This is the first kind of route, and the one we control end to end.

Confirmation on this route runs on our own tools as well. ATLAS confirms the incoming payment from the receiving bank's notification. Before a pay-in closes, it checks the amount, the bank reference and the time.

The second kind is a partner route: another provider's processing, connected to ATLAS as a cascade. Where our own network runs short in a market, traffic cascades to partner routes, with automatic failover between routes.

You don't integrate twice. Your server sends the same pay-in request, POST /api/merchant/pay-in, whichever route ends up serving the order, and gets the same statuses and webhooks back.

Inside our network, each pay-in goes to a trader with the right weight and a free receiving account. The weight sets each trader's share of your traffic. A receiving account is free when that exact amount isn't already waiting on it, because each one holds only one open order per exact amount.

Round amounts are common, so the same figure can be open on every receiving account at once. If amount adjustment is switched on for your account, a UPI order in that position is served at the nearest free amount within your configured range; with it off, which is the default, the order gets the exact amount or NO_CARD_AVAILABLE.

Other limits narrow the choice further. Each receiving account has per-order and turnover limits, and an account can be taken off traffic at any time. The method you request matters too, because the rail decides which receiving account can serve the order: in India upi and upi_intent share one rail and the same receiving accounts, while imps has its own.

Pay-outs go to a shared pool, and each one is executed from it. If verification sends one back, it returns to that pool.

Routing is set for each merchant, and within each merchant for each market. For your account, ATLAS sets how much traffic goes to the internal trader pool and how much to partner routes, and in what order routes take over when one can't. India can run on one set of weights while Venezuela runs on another.

Weights spread the traffic between routes that are all working. The failover order says what happens when one stops: the next route in line takes the order. Both settings live with your account, so they change without any change to your code.

In practice, a market can run on our trader pool with a partner route behind it. Orders spread across the traders by weight while the pool has room. When it runs short, the next orders cascade to the partner route.

A route that accepts orders can still convert poorly. ATLAS watches conversion on every route in its own console, and when it dips, our team moves the traffic. Technical and operations support runs around the clock.

Your side is the order itself. You choose the market and the method for each pay-in, from the methods contracted for your merchant account; GET /api/merchant/payment-methods?geo={geo} lists them. Your account has a minimum and a maximum amount, and orders outside them are refused with AMOUNT_BELOW_MINIMUM or AMOUNT_ABOVE_MAXIMUM. You also decide whether to ask for the hosted page and how long each order lives.

Our side is everything between your request and the money. ATLAS runs the trader pool and its receiving accounts, sets the weights and the failover order, connects and watches the partner routes, and moves traffic when a route weakens. To change how your traffic is routed in a market, tell us what you need there and we set it up.