Payment gateway for India, settled in USDT

India has three pay-in methods on two rails. UPI and UPI Intent share the UPI rail and pay the same kind of destination, a UPI ID. IMPS is a bank transfer on a rail of its own. You choose the method on every order with paymentMethod (upi, upi_intent or imps). In India the field is required, and amounts are whole rupees.

UPI

UPI is India's system for bank-to-bank payments from a phone, run by NPCI. The buyer scans a QR code with any UPI app, or copies the UPI ID and the amount into the app by hand. The create response carries both: qrImageBase64 for the QR and upiVpa for the text fallback.

UPI Intent

The same rail, handed to the buyer as a tap. Every UPI order returns upiIntentLink, which opens the buyer's UPI app with the payee and the amount filled in. Send includeUpiAppLinks: true to also get PhonePe and Paytm links that open each app's own send-money screen with the amount locked.

IMPS

A bank transfer to an account number and IFSC, the 11-character code of the bank branch. The buyer types the amount into their bank app, so ATLAS never changes the amount of an IMPS order.

The UPI and IMPS method pages go deeper into each rail, and pay-ins shows how the flow works in every market.

Pay-outs in India also run on two rails. IMPS to an account number and IFSC is the default, and paymentMethod: "upi" pays a recipient's UPI ID instead. A field from the wrong rail gets 400 VALIDATION_ERROR, so a mixed-up recipient is caught before any money moves. The recipient fields for each rail are on the IMPS and UPI pages.

On the UPI rail, ATLAS sends the pay-out from a local account in its network. Both rails end with the same pay_out.completed webhook, and each pay-out is funded in USDT from your pay-out balance. Statuses and failures are covered on the pay-outs page.

India is one of the two markets where the ATLAS pay page is available, so you decide how much front end you build.

• Payment link: add a checkout object to POST /api/merchant/pay-in and send the buyer to checkout.url. You build no payment screen.
• Embedded checkout: the same page inside your own checkout, from checkout.embedUrl and Atlas.mount.
• H2H API: you draw the payment screen from the response, collect the buyer's UTR after the transfer and relay it with POST /api/merchant/pay-in/{payInId}/utr. An India pay-in is confirmed against a UTR, relayed by you or recorded by ATLAS when it confirms the payment.

The pay page covers orders served by the ATLAS network. A checkout request for an order your routing sends to a partner route is refused with CHECKOUT_NOT_SUPPORTED, no pay-in is created, and you retry without checkout. Request and response samples for each method are on the UPI and IMPS pages.

The pay page opens in English or Hindi, and the buyer can switch languages with one tap. Pass locale: "hi" to open it in Hindi.

For a UPI order the first choice is the app: PhonePe, Paytm or Other UPI. PhonePe and Paytm open with the payee and the amount filled in. Other UPI unfolds the QR and the UPI ID with copy buttons, and the QR can be saved to the phone's gallery. An IMPS order shows the account number, IFSC, bank and account holder, each with its own copy button.

A countdown shows how long the details stay valid. After paying, the buyer can tap "I have paid" and add the 12-digit UTR, with a hint on where to find it. The UTR is optional. The page keeps checking on its own, switches to success once the payment is confirmed and sends the buyer back to your returnUrl. If the buyer closes the tab early, the order still completes.