Accept local payment methods through one pay-in API

In India and South Korea you can skip building a screen and use the hosted payment page. Add a checkout object to the same create request and send the buyer to checkout.url, or put checkout.embedUrl inside your own checkout with Atlas.mount. The page follows the method you asked for and returns the buyer to your returnUrl. Argentina, Venezuela, Turkey and Europe connect through the API.

On your own screen, the response gives you what each method needs. A UPI order comes with a QR, the UPI ID and an intent link, and on request with PhonePe and Paytm links that open the app with the amount locked. An IMPS order gives an account number and IFSC. A Korean order gives a bank account or a Kakao Pay QR. The response only includes keys that apply to the order's market and rail, so read keys by name.

A pay-in has four statuses. It is WaitingPayment while the details are out, Completed once the payment is reconciled, Expired when its lifetime runs out unpaid and Failed after an administrative cancellation.

An expired order can still turn Completed when it is confirmed by hand later, so your code should accept a late completion.

Each of these outcomes sends a webhook: pay_in.completed, pay_in.expired or pay_in.failed. Check its signature, an HMAC-SHA256 of the raw body signed with your API secret, before you act on the payload; the developer guide to webhooks and HMAC signatures covers the details.

If your server answers with anything other than 2xx, ATLAS tries again, up to 10 attempts over about five hours. The same event can arrive twice, so deduplicate on the event name and the pay-in ID.

Retries from your side are safe as well. Your order ID is the idempotency key: send it again for an order that hasn't failed and you get the original pay-in back.

If a buyer sends less than the order asked for, support can close it on the amount received, and the order keeps your first figure as its original amount.

When something is wrong with a completed pay-in, open a dispute with POST /api/merchant/disputes. You can contest the whole amount or part of it, and ATLAS holds the funds in question until the dispute is decided.

The dispute starts as PendingEvidence with a 24-hour evidence deadline. You add messages and evidence to its thread, up to 10 files per request. If the deadline passes, the dispute resolves in your favour automatically. You follow it through dispute.opened and dispute.resolved on the same webhook URL, or read the thread with GET /api/merchant/disputes/{id}.

The portal lists your pay-ins with filters by status, market and date, and exports them to CSV.

Open one and you see a card with the fiat and USDT amounts, the commission and a status timeline with the webhooks that went out. The request log keeps every API call with its response code and signature check, and every webhook with its delivery attempts.

Before you write any code, Pay-Ins → Test Pay Page in the sandbox creates an ordinary pay-in and shows its live status while you walk through the payment steps. The sandbox runs the same contracts as production.

Completed pay-ins add to your USDT balance. When your balance reaches your threshold, USDT goes to your TRC-20 wallet automatically. You can also withdraw on request; USDT settlement has the details. Pay-outs, settlement and the dashboard come together on the page for merchants.