Skip to main content

Simulate ARS Deposit (Sandbox)

In sandbox, ARS deposits are simulated end-to-end — you do not need to actually send an Argentine bank transfer to finish the flow. This page explains how the simulation works so you can run through the full ARS → crypto journey without touching real rails.

info

This behavior is sandbox only. In production the user must open their banking app and complete the actual ARS bank transfer to the destination CVU returned at ticket creation for the ticket to move beyond UNPAID.

What happens when you create an ARS ticket in sandbox

  1. Quote + ticket — you call GET /v2/account/quote/fixed-rate and then POST /v2/account/tickets/ exactly like in production. The flow is identical from an API consumer perspective.
  2. Destination CVU — the ticket response includes a cvu, bankName, and expiration. The cvu is a mock value in sandbox (a fixed-test CVU). Do not expect it to receive a real transfer — it exists only to mirror the production response shape.
  3. Auto-settlement (async) — a background job dispatches the equivalent of a payin_status_changed = COMPLETED webhook straight into the processing pipeline, without waiting for a real bank transfer.
  4. Ticket lifecycle completes — the ticket transitions UNPAID → PROCESSING → PAID, mock tokens are credited to the specified wallet, and the usual TICKET-CREATED, DEPOSIT-PROCESSING, DEPOSIT-SUCCESS, and TICKET-COMPLETE webhooks fire, matching production.

Typical end-to-end time: about 70 seconds between ticket creation and PAID (the bulk is the async token-mint step, not the deposit itself).

Amount limits

The simulation fires for ARS deposits up to 10,000,000 ARS. Amounts above that cap are still accepted by the ticket API, but the auto-settlement is skipped — tickets stay UNPAID until manually completed. Keep test amounts under the cap.

Example

1. Quote

curl -X GET "https://api.sandbox.avenia.io:10952/v2/account/quote/fixed-rate?inputCurrency=ARS&inputPaymentMethod=BANK-TRANSFER&inputAmount=12000&outputCurrency=USDC&outputPaymentMethod=INTERNAL&inputThirdParty=false&outputThirdParty=false&blockchainSendMethod=PERMIT" \
-H "Authorization: Bearer eyJhdXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"

2. Ticket

curl -X POST "https://api.sandbox.avenia.io:10952/v2/account/tickets/" \
-H "Authorization: Bearer eyJhdXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" \
-H "Content-Type: application/json" \
-d '{
"quoteToken": "eyJhdXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
"ticketArsInput": {
"senderAccountNumber": "0000003100010000000001"
},
"ticketBlockchainOutput": {
"walletAddress": "0xabcdefabcdefabcdefabcdefabcdefabcdefabcd"
}
}'

Sample response:

{
"id": "9355e9b9-9637-4dba-8ce5-09c6ce3b92c2",
"cvu": "0000003100010000000001",
"bankName": "Banco Mock (ARS)",
"expiration": "2026-06-22T16:30:10.888Z"
}

3. Poll the ticket

Nothing else is required. Poll the ticket until it reports PAID:

curl -X GET "https://api.sandbox.avenia.io:10952/v2/account/tickets/9355e9b9-9637-4dba-8ce5-09c6ce3b92c2" \
-H "Authorization: Bearer eyJhdXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"

You should see the status transition from UNPAIDPROCESSINGPAID within roughly a minute.

Simulating ARS payouts

Crypto → ARS payouts are simulated as well:

  • Create the ticket with outputCurrency=ARS&outputPaymentMethod=BANK-TRANSFER and reference a beneficiary registered via POST /v2/account/beneficiaries/bank-accounts/ars/ (ticketArsOutput.beneficiaryArsBankAccountId). The ticket reaches PAID within a second.

No real payout is executed and no real ARS is sent. Minimum amount remains 5 USDC.

What is not simulated

The following still hit the real staging rails and behave exactly as production would:

  • Creating ARS beneficiaries (POST /v2/account/beneficiaries/bank-accounts/ars/)
  • Listing supported ARS banks (GET /.../ars/supported-banks)
  • KYC approval for new accounts

If any of those endpoints return an unexpected error in sandbox, it reflects a real issue with the upstream staging rail — not with the simulation.