Payment gateway for Argentina, built on CVU and CBU transfers

ATLAS is a payment gateway for Argentina: buyers pay in pesos by transfer to a CVU or CBU, and your pay-outs go by bank transfer to the recipient's CBU. Each completed order adds USDT to your balance.

Contact us Read the Argentina API docs

For merchants with customers in Argentina

Argentine shoppers pay from their bank or wallet apps. ATLAS gives each order a local account to pay into, and your balance is credited in USDT without an Argentine bank account on your side.

Argentina runs through the API, server to server, so the payment screen stays inside your own product. When you need to pay customers back, the same integration sends pay-outs to their accounts. The merchants page has the full picture of what ATLAS offers.

Where Argentine buyers send the money

Your buyers can pay from a bank app or a digital wallet, because Argentine transfers move freely between bank accounts and wallet accounts. For each pay-in ATLAS returns a 22-digit CVU or CBU, and the buyer pays it from whichever app they use.

The CVU and CBU page explains the two keys and the API fields for both directions.

  • CVU · 22 digits An account at a wallet or payment provider
  • CBU · 22 digits An account at a bank

Pay-ins by transfer to a CVU or CBU

Create the order with POST /api/merchant/pay-in: geo 1 (or Argentina), currency ARS, and an amount with two decimal places. paymentMethod is optional here. Leave it out and the order goes to the market's default rail, cvu, which GET /api/merchant/payment-methods?geo=Argentina lists as "CVU transfer".

ATLAS reserves a destination for the order and returns what the buyer needs: the account holder, the bank or provider, a 22-digit CVU or CBU, the exact amount and the deadline. Argentine pay-ins are confirmed from the receiving bank's notifications, and you learn the result from the pay_in.completed webhook.

The request and response fields are on the CVU and CBU page, and pay-ins shows the flow in every market.

Pay-outs by bank transfer to a CBU

Argentina has one pay-out rail, bank transfer to a CBU. Each pay-out draws on your USDT pay-out balance, a signed webhook tells you how it ended, and the CBU pay-out fields and checks are on the CVU and CBU page. Statuses and retries for every market are on the pay-outs page.

Pesos in, USDT on your balance

You price each Argentine order in ARS. The create response already carries the order's USDT value, fixed when it is created, so your books can record it before the buyer pays.

Completed pay-ins build up your USDT balance, and auto-settle or a withdrawal on request moves it to your TRC-20 wallet.

Integration in Argentina: the H2H API

The hosted and embedded pay page serves India and South Korea only. In Argentina a request with checkout returns CHECKOUT_NOT_SUPPORTED and creates no pay-in, so you connect with the H2H API and show the payment details on your own screen.

Every request is signed with HMAC-SHA256 using X-Api-Key, X-Timestamp and X-Signature. merchantOrderId is your idempotency key: repeat it and you get the original order back instead of a second one. clientReference identifies your customer and is required on every request. Signed webhooks report final statuses and dispute events, with up to 10 delivery attempts, and GET /api/merchant/pay-in/{payInId}/status answers whenever you want to check.

The developers hub has the sandbox, signatures and webhook details.

What a buyer in Argentina does

  1. On your checkout, the buyer sees the account holder, the bank and the 22-digit CVU or CBU, with the amount and the time left to pay.

    A copy button next to the key saves them typing 22 digits.

  2. They open their bank or wallet app and send exactly that amount to the key.

  3. ATLAS confirms the transfer, the order moves from WaitingPayment to Completed, and your server receives pay_in.completed.

    Your screen can then show the result.

If the deadline passes first, the order becomes Expired and pay_in.expired fires. A payment that arrives late can still be confirmed afterwards, which moves the order from Expired to Completed, so keep handling pay_in.completed for orders you have already marked as expired.

How to start in Argentina

  1. Contact us with your volume and the flows you need.

    We enable Argentina for your account.

  2. Get sandbox keys and build against the Argentina view of the API docs; what works there works in production.

  3. Run a pay-in and a pay-out end to end: transfer, confirmation, webhook.

  4. Move your keys and address to production.

    Limits and terms are agreed before you go live.

FAQ

How can buyers in Argentina pay?

By bank or wallet transfer to the CVU or CBU that ATLAS returns for their order, in ARS.

Can buyers pay from a digital wallet?

Yes. Transfers run between wallet accounts (CVU) and bank accounts (CBU), so a buyer can pay from either. The CVU and CBU page explains the two keys.

Can I use the hosted payment page in Argentina?

No. The pay page covers India and South Korea. In Argentina you show the payment details in your own interface through the H2H API.

What do I need to send a pay-out in Argentina?

The recipient's 22-digit CBU and name, plus the amount in ARS. The CVU and CBU page lists the fields.

Do I have to choose a payment method for each pay-in?

No. paymentMethod is optional in Argentina; without it the order uses the default rail, cvu.

What happens if the buyer pays after the order has expired?

The payment can still be confirmed. The order moves from Expired to Completed and pay_in.completed fires.

Can I contest a completed payment?

Yes. Open a dispute with POST /api/merchant/disputes, for the full amount or part of it, and attach evidence before the deadline.

In what currency am I paid for Argentine payments?

In USDT, paid out to your TRC-20 wallet by auto-settle or on request.