Skip to main content

​
Overview

Argentina is HG.Cash’s primary market for bank transfers in ARS. HG.Cash assigns banking accounts to your users in the platform. When money moves on those accounts—cash-in (inbound) or cash-out (outbound)—HG.Cash notifies your backend at the webhook URL you configure in account settings. For cash-outs, you initiate instant banking transfers with the API. For cash-ins, you do not create inbound payments through the API; HG.Cash detects movements on your assigned accounts and delivers them to your webhook. For a hosted payment page where the payer transfers to your CVU/alias and enters an 8-digit DNI, use Hosted checkout (country: AR) instead of webhook-only detection alone.

​
How it works

  1. Accounts — HG.Cash provisions ARS accounts (CBU/CVU) linked to your user. Use GET /api/v1/accounts and GET /api/v1/account/{id}/balance to list balances and status.
  2. Cash-in — Incoming transfers to those accounts are recorded by HG.Cash and sent to your webhook URL (ledger / account movement payloads).
  3. Cash-out — Call POST /api/v1/transactions to request an instant outbound transfer to a recipient CBU or CVU. Status updates are sent to your webhook (and optionally a per-request webhookUrl).
Configure your default webhook URL and signing secret in HG.Cash Settings before going live. See Receiving webhooks for payload shapes, HMAC verification, and retries.

​
Cash-outs (instant transfers)

Outbound payments are transaction requests to a recipient CBU or CVU. HG.Cash processes eligible requests as instant banking cash-outs when your account and limits allow it.

​
Prerequisites

  • Bearer API token with access to the ARS account
  • Recipient CBU or CVU (22 digits)
  • Sufficient net balance on the source account for the transfer amount plus the outbound fee
HG.Cash calculates the outbound fee when you create a transaction request (dashboard or POST /api/v1/transactions). The request is rejected if amount + outboundFee exceeds netBalance (balance - pendingFees from GET /api/v1/account/{id}/balance). For example, with netBalance of 1,000,000 ARS and a 1% outbound fee, the maximum you can withdraw in one request is 990,000 ARS — not the full balance. If the account cannot cover the amount and fee, the API returns 409 with code: INSUFFICIENT_NET_BALANCE and a details object that includes outboundFee, requiredTotal, netBalance, and maxWithdrawableAmount.

​
Flow

  1. Optional: confirm balance with GET /api/v1/accounts or GET /api/v1/account/{id}/balance
  2. POST /api/v1/transactions — accountId, amount, and toCBU or toCVU
  3. Track status with GET /api/v1/transaction/{id}/status, your dashboard webhook, or an optional webhookUrl on the request
  4. Once processing completes, resolve the ledger row with GET /api/v1/transaction-requests/{id}/transaction-id (returns { "transactionId": "<uuid>" } or null while still unlinked) or wait for the Transaction request associated webhook (topic TRANSACTION_REQUEST, eventType transaction_associated)

​
Example request

The response includes a request id and initial status (for example PENDING). Use webhooks or polling until the request reaches a terminal state (DONE, ERROR, CANCELLED, and others in the API reference).

​
Insufficient balance error

When the requested amount plus the outbound fee exceeds netBalance, HG.Cash returns 409:
Use maxWithdrawableAmount from the error (or pre-check with the balance endpoint) before retrying with a lower amount.
  • GET /api/v1/transaction-requests/{id}/transaction-id — linked ledger transaction ID for a completed cash-out request (null while still processing)
  • GET /api/v1/alias-lookup — resolve alias to CBU/CVU before sending (when enabled for your account)
  • GET /api/v1/transaction-statuses and GET /api/v1/transaction-types — reference data (no auth required)