CVU payments in Argentina, with CBU pay-outs

Accept peso transfers to a CVU or CBU and pay out to a CBU through the ATLAS API. The buyer gets a 22-digit CVU or CBU to pay, a pay-out needs one 22-digit field, and you are credited in USDT.

Contact us Read the API docs
CVU/CBU Transfer details
Amount payable ARS 5,000.00
  • CVU 0000 1775 0105 7000 1896 25
  • Account holder Demo Receiver
CVU/CBU Transfer details
Amount payable ARS 5,000.00
  • CVU 0000 1775 0105 7000 1896 25
  • Account holder Demo Receiver

CVU and CBU: what a merchant needs to know

Argentina identifies every account receiving a transfer by a 22-digit key. A CBU, the Clave Bancaria Uniforme, belongs to an account at a bank. A CVU, the Clave Virtual Uniforme, belongs to an account at a payment service provider, such as a digital wallet. Transfers run between the two in both directions, so a buyer with a bank account can pay a CVU and a wallet user can pay a CBU. Both keys also have a human-readable alias.

For your integration the difference mostly disappears. ATLAS returns the destination in one field, cbu, whichever kind of key it is, and you show it as it comes. The amount is in pesos with two decimals.

CVU/CBU Argentina

paymentMethod cvu

PI00000997
  1. WaitingPayment 22-digit CVU or CBU sent to the buyer
  2. Bank notification Matches the transfer to the order
  3. Completed Credited to your USDT balance

How a buyer pays to a CVU through ATLAS

  1. Create an ARS order

    Your server creates a pay-in in pesos, with the amount to two decimal places.

  2. Get a CVU or CBU back

    The response carries the 22-digit key, the bank and the account holder, plus a QR image when the account has one.

  3. Show the 22 digits

    The buyer sees the key, the holder and the exact amount on your payment screen.

  4. The buyer pastes the key

    From their bank or wallet app the buyer pastes the 22 digits, checks the holder name the app shows, and sends the amount.

  5. The bank notification closes it

    The receiving bank's notification confirms the transfer, the order completes and the completion webhook arrives.

Example: a CVU order and its webhook
POST /api/merchant/pay-in 
{  "amount": 5000.00,  "currency": "ARS",  "geo": 1,  "expiresIn": 900,  "merchantOrderId": "order-12345",  "clientReference": "customer-7781"}
Webhook: pay_in.completed 
{  "event": "pay_in.completed",  "payInId": "1c75c312-93f3-4b34-903e-10fb38a56bec",  "displayId": "PI00000997",  "merchantOrderId": "order-12345",  "status": "Completed",  "geo": "Argentina",  "utr": null}

The fields that matter

In Argentina paymentMethod is optional; leave it out and the order uses the market's default rail. The code is cvu, listed as "CVU transfer" by GET /api/merchant/payment-methods?geo=Argentina, and a code your account doesn't have returns METHOD_NOT_CONTRACTED.

The create response holds only the keys that apply to the order: the destination in cbu, the holder in ownerName, the institution in bankName and the payable amount. qrImageBase64 appears only when the account carries a QR, so check for the key before you draw it. requiresManualConfirmation tells you whether the order waits for a trader to confirm it.

Example: a CVU pay-in
POST /api/merchant/pay-in 
{  "amount": 5000.00,  "currency": "ARS",  "geo": 1,  "expiresIn": 900,  "merchantOrderId": "order-12345",  "clientReference": "customer-7781",  "paymentMethod": "cvu"}
201 Created 
{  "displayId": "PI00000007",  "geo": "Argentina",  "ownerName": "Demo Receiver",  "cbu": "0000177501057000189625",  "amount": 5000.00,  "expiresAt": "2026-04-14T13:28:36.837Z"}

Your payment screen, over the API

The hosted and embedded payment page covers India and South Korea, so in Argentina you render the payment yourself over the H2H API. Keep it plain: the 22 digits with a copy button, the holder's name so the buyer can compare it with what their app shows, the amount and the time left before expiresAt.

You don't relay a reference afterwards. The UTR endpoint applies to India and South Korea, and a pay_in.completed for an Argentine order carries utr: null. Track the order through GET /api/merchant/pay-in/{payInId}/status or the webhooks, and use merchantOrderId as the idempotency key when you retry a create call.

Limits, expiry and late transfers

Your account has a minimum and a maximum per order, and an amount outside them is refused with AMOUNT_BELOW_MINIMUM or AMOUNT_ABOVE_MAXIMUM. You choose how long an order stays open with expiresIn, in seconds; when that runs out, pay_in.expired fires.

A transfer can still land after expiry. In that case the order can be confirmed by hand and moves from Expired to Completed with isManualConfirmation: true, so keep listening for pay_in.completed on expired orders. And when a buyer sends less than the order asked for, support can close it on the sum received: amount and requestedAmount then show what arrived and what you are credited for, while originalAmount keeps your request.

CBU pay-outs

Argentina has a single pay-out rail, so the recipient object never changes. Send recipientCbu, a 22-digit key that passes the standard CBU checksum, with recipientName, the amount in ARS and the common fields. Nothing else goes in the recipient object; any other recipient field returns 400 VALIDATION_ERROR, and paymentMethod is ignored. A request without the key fails with "recipientCbu is required for Argentina".

The pay-out draws on your USDT balance, moves from Pending through Claimed and PendingValidation to Completed, and pay_out.completed echoes recipientCbu. A pay-out sent before the balance is funded waits as AwaitingFunds until you top up. The pay-outs page covers the rest of the flow.

Example: a CBU pay-out
POST /api/merchant/pay-out 
{  "recipientCbu": "0000177501057000189625",  "recipientName": "Demo Receiver",  "amount": 5000.00,  "currency": "ARS",  "geo": 1,  "expiresIn": 1800,  "merchantOrderId": "payout-67890",  "clientReference": "customer-7781"}
201 Created 
{  "payOutId": "660e8400-e29b-41d4-a716-446655440111",  "displayId": "PO00000001",  "amountFiat": 5000.00,  "currency": "ARS",  "expiresAt": "2026-04-14T16:00:00Z"}
400 Bad Request 
{  "error": "VALIDATION_ERROR",  "message": "recipientCbu is required for Argentina"}

From a peso transfer to USDT on your balance

A CVU pay-in waits in WaitingPayment until the bank notification matches the transfer, then ends in Completed, Expired or Failed with a signed webhook, and the completed status also returns payerName. The webhook signatures and retries apply to every event.

Each peso order carries its USDT value, fixed when it is created, and a completed order adds it to your balance. Auto-settle or a withdrawal on request takes it to your TRC-20 wallet. The market overview is on payments in Argentina.

FAQ

What is the difference between a CVU and a CBU?

A CBU identifies a bank account and a CVU an account at a payment service provider. Both are 22 digits, and transfers work between them.

Do I need to tell ATLAS whether the buyer pays from a bank or a wallet?

No. The pay-in returns one destination in cbu, and the buyer pays it from whichever app they use.

What does a CBU pay-out need?

recipientCbu, 22 digits with a valid CBU checksum, plus recipientName and the common fields.

Can I pay out to an alias instead of the 22 digits?

The pay-out field takes the 22-digit key, checked against the CBU checksum. Resolve aliases on your side before you send.

Is paymentMethod required in Argentina?

No. Leave it out for the default rail, or send the code from GET /api/merchant/payment-methods?geo=Argentina.

Is there a hosted payment page for Argentina?

No. The hosted page covers India and South Korea. In Argentina you show the details on your own screen.