Local payment methods API
One API runs seven local payment methods across India, South Korea, Venezuela and Argentina. Each method has its own code, its own payment details and its own way of confirming, and every one of them settles to you in USDT.
Every method with its API code
The table lists every method you can call today, the code you send and whether it works for money in, money out or both.
| Method | Country | API code | Pay-in | Pay-out | Hosted page |
|---|---|---|---|---|---|
| UPI |  India | upi | Yes | Yes, to a UPI ID | Yes |
| UPI Intent | India | upi_intent | Yes | Use upi | Yes |
| IMPS | India | imps | Yes | Yes, the default | Yes |
| Kakao Pay |  South Korea | kakao_pay | Yes | No | Yes |
| Bank transfer | South Korea | kor_bank | Yes | Yes | Yes |
| Pago Móvil |  Venezuela | optional; any bank, or a bank code such as 0102 | Yes | Yes, Pago Móvil / bank transfer | No, API only |
| Transfer to a CVU or CBU |  Argentina | cvu (optional) | Yes | Yes, bank transfer to a CBU | No, API only |
Turkey and Europe and the UK are on our markets list. Contact us for details.
How the API picks a method
Every pay-in goes to POST /api/merchant/pay-in, and the method is the paymentMethod field. GET /api/merchant/payment-methods?geo={geo} returns the codes contracted for your account, as code, name and type, where type is the rail underneath. Two codes can share a rail: upi and upi_intent are both type: "upi".
India and South Korea run several rails side by side, so there the field is required and a missing value returns 400 VALIDATION_ERROR. In Venezuela and Argentina it is optional, and leaving it out picks the market's default rail. Anywhere, a code your account doesn't have returns METHOD_NOT_CONTRACTED.
[ { "code": "imps", "name": "IMPS", "type": "imps" }, { "code": "upi", "name": "UPI", "type": "upi" }, { "code": "upi_intent", "name": "UPI Intent", "type": "upi" }]What changes from method to method
The request looks the same everywhere. The response changes with the method, and it only carries the keys that apply.
- UPI returns a UPI ID, a QR and a deep link, and on request PhonePe and Paytm links
- IMPS returns an account number and an IFSC code
- A Korean bank transfer returns an account number and a bank, and Kakao Pay a QR
- Pago Móvil returns a phone number, a cédula and a bank
- A transfer to a CVU or CBU returns a 22-digit CVU or CBU
Confirmation differs too. In India every order closes on the buyer's UTR, which you can relay through the API. Korean orders confirm without any reference. Amounts in rupees and won are whole numbers, while bolívars and pesos take two decimals.
A hosted page or your own screen
For the Indian and Korean methods you can skip the front end: add a checkout object and send the buyer to the hosted payment page, in English, Hindi or Korean, or embed it in your site. Pago Móvil and CVU/CBU connect through the H2H API, where you draw the payment details yourself.
Pay-outs by method
Pay-outs use POST /api/merchant/pay-out, and each market asks for its own recipient fields. India pays out by IMPS by default, or to a UPI ID with paymentMethod: "upi". South Korea pays out by bank transfer only, Venezuela takes a phone, cédula, bank and account number, and Argentina a 22-digit CBU. Kakao Pay is a pay-in method. More on the pay-outs page.
Response keys per method
Every create response carries payInId, displayId, geo, ownerName, bankName, amount, requestedAmount, amountAdjustment, currency, expiresAt and requiresManualConfirmation. The payment details on top of those depend on the method, and a key that doesn't apply is left out, never sent as null.
| Method | Code | Payment detail keys |
|---|---|---|
| UPI, UPI Intent | upi, upi_intent | upiVpa, upiIntentLink, qrImageBase64, qrPayload; upiAppLinks when you send includeUpiAppLinks: true |
| IMPS | imps | accountNumber, ifscCode |
| Bank transfer (South Korea) | kor_bank | accountNumber |
| Kakao Pay | kakao_pay | qrImageBase64, qrPayload |
| Pago Móvil | optional bank code | recipientPhone, recipientCedula; cbu when a partner route issues an account number |
| Transfer to a CVU or CBU | cvu (optional) | cbu; qrImageBase64 and qrPayload when the account carries a QR |
FAQ
Which local payment methods does ATLAS support?
UPI, UPI Intent and IMPS in India, bank transfer and Kakao Pay in South Korea, Pago Móvil in Venezuela and CVU/CBU in Argentina, all through one API.
How do I find the methods enabled for my account?
Call GET /api/merchant/payment-methods?geo={geo}. The list is scoped to your account and gives the code to send as paymentMethod.
Is paymentMethod always required?
Only in India and South Korea. In Venezuela and Argentina you can leave it out and the default rail is used.
Which methods support pay-outs?
UPI and IMPS, Korean bank transfer, Pago Móvil and CBU. Kakao Pay is for pay-ins only.
Which methods have a hosted payment page?
The Indian and Korean methods. Venezuela and Argentina connect over the API.