Skip to main content

Simulate MXN Deposit (Sandbox)

In sandbox, MXN deposits are simulated end-to-end — you do not need to actually send a Mexican bank transfer to finish the flow. This page explains how the simulation works so you can run through the full MXN → 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 MXN bank transfer to the destination CLABE returned at ticket creation for the ticket to move beyond UNPAID.

What happens when you create an MXN 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 CLABE — the ticket response includes a clabe, bankName, accountHolder and expiresAt. In sandbox the clabe is the fixed mock value 012180001234567899 and the bankName is Banco Mock (MXN). 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 completed-deposit 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.

Most of the end-to-end time is the async token-mint step, not the deposit itself.

Amount limits​

The simulation fires for MXN deposits up to 4,000 MXN. 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=MXN&inputPaymentMethod=BANK-TRANSFER&inputAmount=1000&outputCurrency=USDC&outputPaymentMethod=INTERNAL&inputThirdParty=false&outputThirdParty=false&blockchainSendMethod=PERMIT" \
  -H "Authorization: Bearer eyJhdXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"

2. Ticket​

MXN payins take no rail-specific ticket block — there is no sender account to declare.

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

Sample response:

{
  "id": "3f21c5b8-2f19-4a0a-9a1c-8e0d5c2b7a41",
  "clabe": "012180001234567899",
  "bankName": "Banco Mock (MXN)",
  "accountHolder": "Avenia LLC",
  "expiresAt": "2026-08-12T16: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/3f21c5b8-2f19-4a0a-9a1c-8e0d5c2b7a41" \
  -H "Authorization: Bearer eyJhdXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"

You should see the status transition from UNPAID → PROCESSING → PAID.

Simulating MXN payouts​

Crypto → MXN payouts are simulated as well:

  • Create the ticket with inputCurrency=USDC, outputCurrency=MXN and outputPaymentMethod=BANK-TRANSFER, referencing a beneficiary registered via POST /v2/account/beneficiaries/bank-accounts/mxn/ (ticketMxnOutput.beneficiaryMxnBankAccountId).

No real payout is executed and no real MXN is sent. The 5 USDC minimum for MXN payouts still applies in sandbox.

Beneficiary registration is also mocked​

warning

MXN differs from ARS and COP here. Creating an MXN beneficiary (POST /v2/account/beneficiaries/bank-accounts/mxn/) does not reach the rail in sandbox — the CLABE and bankId are validated locally and the beneficiary is stored, but no counterparty is created upstream. ARS and COP beneficiary registration does hit the real staging rail even in sandbox, so an error there means a real upstream problem; an MXN registration that succeeds in sandbox has not been checked against the rail.

What is not simulated​

The following still behave exactly as production would:

  • KYC approval for new accounts, including MXN KYC
  • bankId validation against the supported MXN banks list
  • CLABE format and Modulo-10 check-digit validation

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