> ## Documentation Index > Fetch the complete documentation index at: https://docs.cbpayapp.com/llms.txt > Use this file to discover all available pages before exploring further. # Changelog > History of API and documentation changes Every change to the CBPay API and this documentation, most recent first. Breaking changes are announced in advance and flagged as **Breaking**. **Added** * **Compliance controls on outgoing payments** ([payouts guide](/en/guides/payouts), [errors](/en/errors)): payouts, crypto withdrawals with a beneficiary name and collect charges now go through additional compliance controls **before money moves**. Documented errors: `403 compliance_hold` (the operation was held and NOT created — no debit; by policy the exact reason is not disclosed, contact support with the timestamp) and `503 compliance_check_unavailable` (the check could not be evaluated; the operation was NOT created — retry with the **same** `idempotency_key`). **Fixed** * **AML screening person shapes** ([guide](/en/guides/aml)): the screening engine requires `date_of_birth` as a `{year, month, day}` object (the plain `"YYYY-MM-DD"` string returns `422`), `nationality` as an **array** of ISO-3166 codes and `personal_identification[]` as `{ "issuing_country", "number" }` without a `type` field. Guide and spec examples updated with the live-verified shapes. **Added** * **QR Crypto POS — amount-bearing crypto QR charges for processors** ([guide](/en/guides/qr-pos)): company accounts operating physical POS terminals register their merchants as verified merchants (approved third-party KYB/KYC) and generate crypto charges (USDT, USDC, BTC) with an exclusive address and QR per sale. Early payment detection for the POS (`confirming` within seconds), credit with automatic conversion to the settlement asset, per-merchant attribution on charges/webhooks, a reconciliation summary (`GET /v1/pos/summary`) with the informative per-merchant commission and the net to distribute, and refunds over the crypto withdrawal rail with a hard cap (never more than received). New routes under `/v1/pos/*` (QR Crypto POS tag in the API Reference); partial payments accumulate and late payments into an expired charge are still credited. **Fixed** * **Bitcoin crypto QR**: the checkout QR now carries the raw bech32 address (same as TRON/ETH). Exchange apps like Binance rejected the BIP-21 URI (`bitcoin:…?amount=…`) as "invalid QR"; the exact amount remains shown next to it with a copy button. * **Checkout page**: white-label favicon (org symbol) and panel copy no longer splits Spanish words mid-word ("momento" → "moment"/"o") — the aggressive `word-break` now applies only to monospace addresses. **Added** * **Dedicated CLABE per checkout link (Mexico)**: materializing `bank_transfer` MX on a universal checkout link now issues (or takes from a recyclable pool) a CLABE **exclusive to that link**. The payer transfers the exact amount **with no reference**: the deposit is detected and routed to the link automatically by destination account. The materialization payload carries `destination` with `dedicated: true`; if the dedicated account cannot be issued, it degrades to the classic path (merchant account + mandatory `reference` in the transfer description). CLABEs are recycled with a cooldown once the link resolves (paid or expired). **Added** * **Pull collections on the universal checkout link (Venezuela)**: the checkout page now offers methods that charge the payer's account directly (`c2p` and `debito_inmediato` in VE). The payer fills in bank, document, phone or account and the OTP on the same page; the amount is always the one frozen at quote time. New public endpoints: `POST /pay/{token}/collect/otp` (requests the key when the rail sends it on demand) and `POST /pay/{token}/collect` (runs the charge; if the rail confirms synchronously the link is settled in the same call). These methods arrive with `collect: true` in the `GET /pay/{token}/quote` catalog. * **Multi-currency fiat per country**: each country in the quote lists its corridors in `options[]` — one row per method+currency (e.g. Bolivia with QR in BOB **and** USD) with its `local_amount` in `country_quote`. Materializing a method offered in several currencies requires `¤cy=YYY` (the `400 currency_required` error now applies to any method, not just cards). * **Destination account on bank transfers**: when the corridor uses a dedicated deposit account (the CLABE in Mexico), the `bank_transfer` materialization includes `destination` (type, account number and beneficiary) besides the reference — the payer knows where to send the transfer without leaving the page. **Changed** * **SVG flags on the payment page**: country and currency flags are now SVG images (consistent across Windows, macOS and mobile; some systems used to render the country code as plain text). On the Card tab the flag is derived from the **charge currency** (USD → United States flag, even when the acquirer sits in another country). **Fixed** * The checkout page no longer replies `429 too_many_attempts` just for being open: the read, materialization, OTP and collect traffic limits are now independent from each other. **Added** * **Card tab on the universal payment link**: card payments move out of the Fiat tab into their own tab, listed **by charge currency** (today BOB and USD; currencies from future acquirers show up on their own). `GET /pay/{token}/quote` returns the new `cards[]` catalog (country, currency and `local_amount` per option) and `countries[]` no longer lists `card` among the methods. Materializing a card requires the currency: `POST /pay/{token}/methods/card?country=XX¤cy=YYY` — without it the new `400 currency_required` error is returned. Each currency is an independent materialization with its own hosted payment page. **Changed** * **Payment page with a stronger visual identity**: asset logos (USDT, USDC, BTC, GOLD) next to the amount and on the crypto groups, country flags on the Fiat selector and the card rows, per-method icons, and a **prominent expiry timer** (clock pill; under 1 hour it shows a countdown and under 10 minutes it turns red). **Fixed** * The checkout page no longer scrolls by itself to the active panel every few seconds: the automatic refresh re-renders only when the data changed and never moves the scroll (only manually selecting a method brings the detail into view). **Changed** * **Universal checkout payment page redesigned**: the options are now organized into three tabs — **CBPay** (merchant QR + alias, with a copy button), **Crypto** (coins grouped by network; new networks show up on their own once enabled) and **Fiat** (country selector + methods with the quoted local amount). Copy buttons on the alias, addresses, amounts and references. No API changes: the URL, the creation contract and the public endpoints (`/state`, `/quote`, `/methods/{method}`) are the same. **Fixed** * **QR payout — validation before the payout is created**: a `POST /v1/payouts/qr/scan` with an unreadable or dynamic QR now answers `400 invalid_qr_payload` with the concrete reason (it used to return a generic `502`). On the Brazilian confirm, an amount that does not match a fixed-amount PIX QR answers `422` with the payout `failed` and the **refund already applied** — and the QR stays intact so you can retry with the right amount and a new key. * **Static PIX QR is reusable**: the "one QR = one payment" guard no longer applies to Brazilian static PIX QRs (they are paid many times by design); the per-payment protection is your `idempotency_key`, which is mandatory on every Brazilian confirm. **Added** * **PIX QR payout in Brazil (BR/BRL)**: the two-step flow `POST /v1/payouts/qr/scan` → `POST /v1/payouts/qr/confirm` now accepts **static** Brazilian PIX QRs (including the "copia e cola" code) — send `country: "BR"` and `currency: "BRL"`. The scan decodes the BR Code locally (free of charge) and returns the merchant name, PIX key and amount; the confirm pays through PIX with the same pricing as a regular payout. `amount` is always required: fixed-amount QRs demand an exact match (a mismatch answers `422` with the payout `failed` and an automatic refund — the QR is **not** burned). A static PIX QR is **reusable**: each payment carries its own `idempotency_key`. Dynamic or corrupt QRs answer `400 invalid_qr_payload` — use the `pix` method with the beneficiary's key. Available in the test environment with sample QRs and magic values (`.99` amounts fail) — see [Environment & testing](/en/environment-testing#sample-pix-qrs). Details in the [payouts guide](/en/guides/payouts#qr-payout). **Changed** * **Universal checkout link v2 — multi-country + settlement in the asset you choose** (**Breaking** over yesterday's v1 shape): the charge is now denominated in any of your 4 virtual balances via `settlement_asset` (`USDT` default, `USDC`, `BTC`, `GOLD`) with `amount` IN that asset ("50" USDT, "0.001" BTC, "2" g of gold); sending `currency` returns `400` (existing v1 links keep working). The payer sees **every country with a live pay-in corridor** (pick a country → its methods with the local amount quoted and frozen at materialization), the 4 crypto options with a **scannable QR** (`qr_payload` + `qr_png_base64`; BIP-21 for BTC, raw address for TRON/ETH tokens — readable by Trust Wallet, MetaMask, Binance and external wallets), and the merchant's **CBPay QR + alias** to pay instantly from the app (deeplink `cbpay:pay?to=…&checkout=…`; `POST /v1/transfers` accepts `checkout_token` and validates the due server-side). Every payment **auto-converts** into the `settlement_asset` on credit (same asset skips conversion); `conversion_status` is visible on `/state`. New public endpoint `GET {checkout_url}/quote` with the country catalog, crypto dues and CBPay dues. New errors `country_required`, `country_unavailable`, `settlement_asset_disabled` and `checkout_amount_mismatch`. Details in the [payins guide](/en/guides/payins#universal-checkout-link-checkout). **Added** * **Rejection detail on failed active collections**: when an active collection (`collect`, C2P or immediate debit) ends up `failed`, the payin now includes a `failure` object with where the rejection originated (`provider` = the payer's bank, `core` = pre-charge validation), plus the concrete code and message — visible in the synchronous `POST` response, in `GET /v1/payins/{id}` and in the webhook. Previously only the generic `failed` status was exposed. See the [payins guide](/en/guides/payins). **Added** * **Universal checkout link (`checkout`)**: `POST /v1/payins` accepts `method: "checkout"` and returns `checkout_url` — a branded public page where the payer picks how to pay: QR, card, bank transfer or **crypto** (USDT on TRON, USDT/USDC on Ethereum and BTC) with a deposit address exclusive to that charge and accumulation of partial payments. One link \= one charge: the first method that completes the payment wins. State queryable without auth at `GET {checkout_url}/state`; the `payin_credited` of a crypto payment adds `settled_via` and `crypto_amount`. Supports `success_url`, `failure_url`, `expires_in` (10 minutes to 7 days) and idempotency (a retry returns the same link). New errors `already_paid`, `checkout_expired` and `method_unavailable`. Details in the [payins guide](/en/guides/payins#universal-checkout-link-checkout). **Changed** * **Pre-capture authentication filter on card payments**: card charges are only sent to the processor when the 3-D Secure verification ended with a successful or attempted authentication and complete authentication data; an attempt without real authentication is rejected before any funds move and the payer can retry. The payment page also extended device data collection (\~11 s) to improve issuer approval rates. In the test environment, an amount ending in `.44` simulates an attempt rejected by this filter (full table in [Test environment](/en/environment-testing)). **Added** * **Card payments (`card`) on payins**: `POST /v1/payins` accepts `method: "card"` (Bolivia, BOB or USD) and returns `payment_url` — a hosted payment page with your organization's branding where the payer enters their card in secure fields and completes their bank's 3-D Secure verification. Optional fields `customer`, `success_url`, `failure_url` and `expires_at`. A confirmed payment arrives via the `payin_received` webhook and credits the balance like any payin; if nobody pays, `payin_expired` closes the charge. Details in the [payins guide](/en/guides/payins). **Added** * **`account_id` on swaps and address screenings**: the responses of `POST/GET /v1/swaps` and `POST/GET /v1/screenings/addresses` now include `account_id` (the account that owns the operation). Informational for single-account integrations; admin views use it to attribute each record. **Added** * **Bitcoin on-chain (`btc`/`btc`)**: fourth supported network of the crypto product. Every account is now born with **four deposit wallets** (Bitcoin joins, bech32 address `bc1q…`); BTC deposits credit the BTC balance (\~30 min confirmation, 3 blocks) and on-chain withdrawals accept `chain: "btc"` (bech32, taproot and legacy destinations; the network fee is covered by the operation — the recipient receives the exact amount). [Segregated wallets](/en/guides/segregated-wallets) also support the `btc`/`btc` pair (no gas: the fee comes out of the wallet's balance). Travel Rule applies as on the other networks, valuing the amount in USD. Details in the [crypto guide](/en/guides/crypto). **Changed** * **Two-step login also honors the phone binding cooldown**: with login 2FA over SMS/WhatsApp and a recently linked, unverified number, the login code is issued over a stronger factor (authenticator app, then login email) instead of the phone — the effective `channel` comes back in the login response. Without an alternative factor the login responds `403 phone_binding_cooldown` until the cooldown expires. The code is never sent to a number linked from the session itself. Details in the [security and 2FA guide](/en/security-2fa). **Changed** * **OTP challenges with the phone in cooldown fall back to a stronger factor**: with a recently linked number (24 h cooldown), `POST /v1/otp/challenges` no longer blocks if you have the authenticator app enrolled or a verified email — the challenge is issued automatically over that channel (hierarchy totp > email) and the response reports the effective channel. The `403 phone_binding_cooldown` remains only for accounts with no alternative factor. Previously the cooldown blocked every 2FA relaxation (even disabling the email channel) even when stronger factors were available. Details in the [security and 2FA guide](/en/security-2fa). **Added** * **Verified identity as the profile's source of truth**: when your KYC/KYB onboarding is approved, `display_name` (person = first + last name; company = legal name), `tax_id` and `country` are backfilled automatically from the verified identity. Documented in the [KYC guide](/en/guides/kyc) and the [profile guide](/en/guides/profile). **Changed** * **`PATCH /v1/me` locks identity fields once verified**: with `kyc_status: approved`, changing `display_name`, `tax_id` or `country` answers `409 identity_locked` (new code on the [errors](/en/errors) page). `phone` stays editable with its own verification flow. **Added** * **AML screening PDF report**: `GET /v1/aml/screenings/{screeningID}/report` downloads any screening in your history as an executive PDF report with your branding — a cover page with the decision and its risk traffic light, indicators (sanctions, watchlists, PEP, adverse media...), consolidated matches, aliases, a glossary and a final backing section with the international data sources consulted. Trilingual via `lang=en|es|zh` (default English). Pure read, no fee. New section in the [AML guide](/en/guides/aml#screening-pdf-report). * **New error code `invalid_language`** (HTTP 400): the PDF report `lang` is not `en`, `es` or `zh`. Documented on the [errors](/en/errors) page. **Fixed** * **Company fields in the AML screening**: examples and the spec documented `tax_id`/`registration_number`/`country_of_incorporation` as flat fields of `customer.company`, but the screening engine rejects them with `422`. The identifier goes in `registration_authority_identification`, the country in `place_of_registration` and `incorporation_date` is a `{year, month, day}` object. Guide and spec corrected (verified in production). **Added** * **New corridor: Ecuador (USD)** with four payout methods — `bank_transfer`, `deuna` (DeUna wallet), `cash_pickup` (over-the-counter withdrawal, no account needed) and `cnb` (non-bank correspondent). The beneficiary accepts structured names (`given_name`/`first_surname`/...) or automatic splitting from `name`, plus an optional sender block (`sender_name` or its structured fields). Per-method examples in the [payouts guide](/en/guides/payouts) and the spec. * **New error code `channel_unavailable`** (HTTP 503): the corridor's payment channel is temporarily unavailable. Retry later with the same `idempotency_key`. Documented on the [errors](/en/errors) page. **Added** * **Test accounts are born populated**: every new account in the test environment starts with \~6 months of realistic demo history across all products (payouts, payins, transfers, crypto, swaps, cards, banking, contacts...), with play balances, a reconciled statement and analytics ready to explore. Applies to every creation path (registration, social login, admin creation and the dashboard's test/live switch). **Changed** * **Fully independent environments**: test data is no longer refreshed from a production snapshot — nothing is copied between environments. Updated [environments and testing](/en/environment-testing) guide. **Added** * **Official MCP server** at `https://mcp.cbpayapp.com`: connect your AI editor or assistant (Cursor, VS Code, Claude, ChatGPT and any MCP client) to this documentation — search, endpoints with real examples and the error catalog, without leaving your editor. Read-only, no authentication. New [MCP Server](/en/mcp) page with one-click install and per-client setup. **Changed** * **Test environment**: new accounts are now born with `kyc_status: approved` — you can exercise every product immediately, with no onboarding gate. This applies to every creation path (register, social login, admin creation and the dashboard test/live switch); existing test accounts were approved retroactively. **Live** is unchanged: accounts are born unverified and KYC/KYB remains mandatory before money can leave. To test the verification flow in test mode, use third-party KYC/KYB verifications. **Changed** * `PUT /v1/otp/preferences`: enabling 2FA for the `login` action over a phone channel (`sms`/`whatsapp`) now requires the account phone number already **verified** (complete any SMS/WhatsApp OTP challenge first). If the number is not verified the API responds `409 phone_verification_required`. This safeguard prevents a mistyped number from locking you out of your account when enabling login 2FA. **Fixed** * `POST /v1/me/passkeys/register/begin` and `DELETE /v1/me/passkeys/{passkeyID}` now accept a request without a body, as the spec documents (optional body). They previously returned `400 invalid_json`. The current password is still required for accounts that have one (`403 invalid_password` if missing or wrong); social-login-only accounts pass with their session. **Fixed** * `POST /v1/me/totp/enroll` now accepts a request without a body, as the spec documents (optional body). It previously returned `400 invalid_json`. The current password is still required for accounts that have one (`403 invalid_password` if missing or wrong); social-login-only accounts pass with their session. * `PUT /v1/otp/preferences` with channel `email` or `totp` returned a 500 error; fixed — all four channels (`sms`, `whatsapp`, `email`, `totp`) now save correctly. **Changed** * PDF statement: operation statuses are now color-coded (green completed, amber pending, red failed) for quick scanning. **Added — CSV / Excel export on listings** * The `movements`, `payouts`, `payins` and `transfers` listings now accept the `format=csv` or `format=xlsx` parameter to download the rows as an accounting-ready file (up to 10,000 rows per download; the `from`/`to`, `status` and other filters apply the same). ```bash theme={"theme":{"light":"github-light","dark":"github-dark"}} curl -o movements.xlsx "https://api.qbank.cl/platform/v1/movements?from=2026-07-01&to=2026-07-13&format=xlsx" \ -H "Authorization: Bearer pk_…" ``` * Without `format` the response is still the usual paginated JSON — no compatibility changes. **Breaking — Segregated wallets move to `/v1/segregated-wallets`** * Every segregated-wallet route is renamed from `/v1/wallets*` to `/v1/segregated-wallets*`. Same methods, parameters, response shapes, fees and webhooks — only the path prefix changes. There is **no compatibility alias**: the old `/v1/wallets*` routes now respond `404`. * Mapping (the 15 routes follow the same pattern): | Before | Now | | ------------------------------------------------------------------- | ----------------------------------------------------------------------- | | `POST/GET /v1/wallets` | `POST/GET /v1/segregated-wallets` | | `POST /v1/wallets/import` | `POST /v1/segregated-wallets/import` | | `GET /v1/wallets/{id}` (+ `/balance`, `/deposits`, `/transactions`) | `GET /v1/segregated-wallets/{id}` (+ same subroutes) | | `POST/GET /v1/wallets/{id}/sends` (+ `/{sendID}`, `/receipt`) | `POST/GET /v1/segregated-wallets/{id}/sends` (+ same subroutes) | | `GET /v1/wallets/{id}/deposits/{depositID}/receipt` | `GET /v1/segregated-wallets/{id}/deposits/{depositID}/receipt` | | `POST /v1/wallets/{id}/export` · `GET/POST .../auto-forward` | `POST /v1/segregated-wallets/{id}/export` · `GET/POST .../auto-forward` | * The `receipt_url` in responses, webhooks and receipt emails of wallet sends/deposits now points to the new path. * Why: the generic `/v1/wallets` prefix was constantly confused with the **deposit wallets** of the [crypto](/en/guides/crypto) product. Those are untouched and keep living under `/v1/crypto/wallets`. **Added — `type` discriminator on every wallet response** * Deposit wallets (`/v1/crypto/wallets`) now include `type: "deposit"` and `receive_only: true`. * Segregated wallets include `type: "segregated"`. * Use it to tell the two products apart defensively — never by route alone. **Added — `payin_expired` webhook: automatic closure of unpaid collections** * When an active charge (QR or hosted checkout) expires or fails without receiving the payment, the payin now moves automatically from `pending` to `expired` (or `failed`) — previously it could stay pending forever. * New **`payin_expired`** webhook event carrying the `payin_id`, the final status, the corridor and the reference, so you can close the collection on your side without polling. Subscribable via `POST /v1/webhooks/subscriptions`. * No funds move in any case: to retry the collection, create a new payin. **Changed — Redesigned receipts, statement and emails** * Every PDF receipt (`GET .../receipt`) ships a banking-grade redesign: header with logo and receipt number, product icon, hero amount, two-column details, a "Verifiable document" strip with the QR code and an institutional footer. The brand symbol appears as a subtle watermark; non-final operations keep the status watermark. * The statement PDF (`GET /v1/reports/statement?format=pdf`) adds summary cards with icons, a verified-reconciliation badge and per-section icons; the Excel export keeps its structure. * Emails (receipts, verification codes and security notices) now share a branded template with your organization's institutional header and footer. * On fiat payout receipts the beneficiary bank is ALWAYS shown by name: if the operation was created with the catalog `bank_code`, it is resolved to the bank's display name automatically. * No API changes: same routes, same shapes. Only the documents and emails look different. **Added — Refresh tokens for user sessions** * Every login (password, OTP, social, passkey, handoff and register) now returns, alongside the 24-hour `access_token`, a single-use **`refresh_token`** (`rt_…`) to renew the session without re-login: `POST /v1/auth/refresh` issues a fresh pair and rotates the token (30 days per rotation, absolute cap of 90 days from the original login). Details and security rules in [Authentication → Session renewal](/en/authentication#session-renewal-refresh-tokens). * **Strict rotation and theft detection**: exchanging revokes the device's previous access token; presenting an already-exchanged refresh token revokes the entire chain and records a `refresh_token_reuse` event in `GET /v1/me/security/events`. Signing out, revoking sessions or changing the password also invalidates refresh tokens. * New error code: `401 invalid_refresh_token`. API keys `pk_` are unchanged: they never expire and don't use refresh. **Added — Test environment (sandbox) with simulated money** * New **test** environment at `https://cryptobank.qbank.cl/platform`: the same API, with every corridor served by a deterministic internal simulator — always available, no third-party dependency. Operations complete on their own within seconds and **magic values** (`.99`/`.77` amounts, `REJECT` beneficiary, OTP `000000`, etc.) force every other outcome. Full guide in [Environments and testing](/en/environment-testing). * **Per-environment API keys**: test issues and accepts only `pk_test_` keys; live only `pk_`. A key from the other environment returns `401` — impossible to cross environments by mistake. * Every response carries the **`CBPay-Environment`** header (`test` | `live`) and `GET /healthz` exposes `livemode`. * **One-click test/live switch**: `POST /v1/auth/environment-handoff` (live) issues a single-use 60-second token exchanged at `POST /v1/auth/handoff` (test) for a test-environment session, with automatic mirror-account provisioning. **Added — AML screening audit history** * `GET /v1/aml/screenings` and `GET /v1/aml/screenings/{screeningID}` list and retrieve every AML screening (person, company and rescreen) stored locally for audit — subject, risk, fee and full result. * `POST /v1/aml/screenings` and `POST /v1/aml/rescreen` now require `idempotency_key` (the operations charge a fee). Replaying with the same key returns the original record with `idempotency_hit: true` and never double-charges. * `PATCH /v1/aml/monitoring` stores each enable/disable toggle in the same history (`kind: monitoring`); `idempotency_key` is required when the state changes (enable charges a fee). **Added — Travel Rule on on-chain withdrawals (FATF R.16)** * Crypto withdrawals above the configured threshold (default 1,000 USD) now require declaring the beneficiary before moving funds: `wallet_type: "self_hosted"` + `beneficiary_name` for own wallets, or `travel_address` + `beneficiary_name` for destinations at another institution (the data exchange happens inline and the payment address is provided by the receiving institution). Below the threshold nothing changes. * The withdrawal response includes `travel_rule_status` (`not_required` / `self_hosted_attested` / `approved`). * New error codes: `travel_rule_required`, `travel_rule_beneficiary_required`, `travel_rule_address_mismatch`, `travel_rule_rejected`, `travel_rule_pending`, `travel_rule_incomplete_approval`, `travel_rule_unavailable`. Details in the [crypto guide](/en/guides/crypto) and the [errors page](/en/errors). **Added — Banking series in the balance history** * `GET /v1/balances/history` now includes in `assets` the daily series of the banking accounts (`BANK_USD`, `BANK_EUR`), each in its own currency (2 decimals), ready to chart as one more filter next to USDT/USDC/BTC/GOLD. They remain outside the `total_usd` aggregate, which only covers the operational balances. [Analytics](/en/guides/analytics) guide updated. **Added — Country filter on payouts and payins** * `GET /v1/payouts` and `GET /v1/payins` accept the `country` filter (ISO 3166-1 alpha-2, e.g. `?country=MX`), combinable with `status`, `from`/`to` and pagination. [Payouts](/en/guides/payouts) and [payins](/en/guides/payins) guides updated. * The `fees` block of `GET /v1/rates` now returns the **effective** fee configuration (organization defaults resolved against your account's overrides). Accounts without overrides used to see `fees: []` even when operations had a cost; use this block to quote the exact fee before creating an operation. **Changed — Wallet limits per account type** * **Deposit wallets**: every account — person and company — holds exactly **one deposit wallet per supported pair** (`tron`/`usdt`, `eth`/`usdt`, `eth`/`usdc`), provisioned free of charge on registration. `POST /v1/crypto/wallets` now exists only to restore a missing pair; with the pair already provisioned it responds `422 wallet_limit_reached` for every account type (previously companies could create more). * **Segregated wallets**: now also available to person accounts, capped at **1 per network/asset pair** (the second attempt responds `422 wallet_limit_reached`). Company accounts remain unlimited. The `403 company_required` error no longer applies to segregated wallets. * [Crypto](/en/guides/crypto) and [segregated wallets](/en/guides/segregated-wallets) guides, the [persons and companies](/en/concepts/persons-companies) page and [errors](/en/errors) updated. **Added — Continuous transaction monitoring (compliance controls)** * The platform now monitors every operation in real time with bank-grade compliance controls. For the vast majority of clients this is invisible: no flow changes and no perceptible latency. * New error codes documented in [errors](/en/errors): `403 compliance_hold` (operation held by compliance), `403 geo_restricted` (unsupported jurisdiction) and `503 compliance_check_unavailable` (check temporarily unavailable — the operation did not go out; retry with the same idempotency key). **Added — Documentation in 3 languages (English by default)** * This documentation is now fully available in **English** (default language), **Spanish** and **Simplified Chinese**. Switch languages with the selector at the top of the site. * The API Reference is also available in all three languages (same endpoints and examples; only the descriptions change). * The Postman collection and the compiled Markdown guide stay up to date from any language of the site. **Added — Wallet screening (AML risk for blockchain addresses)** * New product: `POST /v1/screenings/addresses` evaluates any blockchain address against global on-chain intelligence — sanctions, exposure to illicit funds — and returns a `Low`/`Medium`/`High`/`Severe` risk level with the full evidence. Fixed fee per scan (`address_screening`, with automatic refund on failure) and mandatory idempotency. History via `GET /v1/screenings/addresses` (+`/{id}`). * **Free automatic protection**: on-chain withdrawals evaluate the destination before signing (severe risk ⇒ rejected with a full refund) and incoming deposits evaluate the sender before crediting (severe ⇒ held for compliance review; high ⇒ credited with an alert). * New webhooks: `crypto_deposit_held` and `crypto_deposit_alert`. * New guide: [Wallet screening](/en/guides/screenings). **Added — Public assets over CDN (avatars, branding, charge QR codes)** * **Avatars over CDN**: `avatar_url` (in `PUT /v1/me/avatar`, `GET /v1/resolve` and contacts) is now an **absolute public URL** that loads without authentication once the image is published to the CDN; `GET /v1/avatars/{accountID}` answers with a `302` redirect to that URL (legacy avatars are still served directly). * **Branding URLs**: `GET /v1/branding` adds `logo_url` and `symbol_url` — public CDN URLs for the logos, so the front end can theme itself without decoding base64 (the `*_png_base64` fields remain). * **Payin QR codes**: QR charges (`POST /v1/payins`, method `qr`) expose `qr_image_url`, the QR PNG published to the CDN, alongside the usual base64 `qr_image`. Perfect for a direct `` tag. Nothing breaks: every existing field is preserved; the URLs are additive. Guides: [Profile](/en/guides/profile) and [Payins](/en/guides/payins). **Added — Compliance catalogs** * New `GET /v1/aml/catalogs`: every catalog you need to build compliance and verification forms (genders, legal entity forms per country, income/wealth sources, industry standards, ISO-3166 countries and subdivisions). This data was previously unavailable through the API. **Changed** * The `asset_prices` block of `GET /v1/rates` and `GET /v1/rates/history` no longer includes the internal `source` field; use `settlement_grade` and `updated_at` to know whether a price is executable and how fresh it is. Guide: [AML screening](/en/guides/aml). **Added — Every account is born with its deposit wallets** * When an account is created (person or company), its three crypto deposit wallets are provisioned automatically and **free of charge**: `tron`/`usdt`, `eth`/`usdt` and `eth`/`usdc`. Right after registration, `GET /v1/crypto/wallets` already returns the three addresses (provisioning runs in the background; querying at the very second of registration may take a few moments). * `POST /v1/crypto/wallets` is now for **additional** wallets (companies); persons already hold each combination's slot since registration. Accounts created before this change were backfilled with any missing wallets. **Changed** * Public account registration is now rate limited per IP (`429 too_many_attempts`). Guide: [crypto](/en/guides/crypto). **Added — Full traceability: banking in the statement, itemized fees and wallet custody** * **Richer statement**: new `card_transactions` (card purchases), `swaps` (balance conversions) and `banking_operations` sections. If you use Banking, your bank accounts reconcile as `BANK_USD`/`BANK_EUR` mirror balances inside the `assets` section. * **Itemized fees**: payouts, payins and crypto withdrawals now split the fee into `fee_percent` and `fee_fixed` (they add up exactly to `fee`); standalone charges carry `fee_model: "fixed"` and are labeled **Fixed Com** in the PDF/Excel. * **New receipts**: `GET /v1/banking/operations/{id}/receipt`, `GET /v1/wallets/{walletID}/sends/{sendID}/receipt` and `GET /v1/wallets/{walletID}/deposits/{depositID}/receipt`. The `banking_operation_status_changed` webhook now includes `receipt_url`. * **Segregated wallet custody**: `custody` field (`cbpay` | `client`) on every wallet; the platform syncs the complete on-chain activity and emits the `wallet_external_movement` webhook (movement signed outside, expected under `client` custody) and `wallet_key_compromise_suspected` (critical alarm). * **Analytics**: `sections.banking.volume` (money moved through your bank accounts, which also adds to `gross_volume`), `sections.verifications.fees_by_kind` (KYC vs KYB spending, separately), `sections.adjustments` and `deposits.wallet_fees_usd`. * **Guaranteed per-wallet accounting** (`cbpay` custody): lifetime reconciliation in the statement and `funding_sources` (deposit→send FIFO attribution) on each send's detail. `BANK_*` mirror balances also show up in `GET /v1/balances` with `custody: "banking"`. Guides: [statement](/en/guides/statement), [banking](/en/guides/banking), [segregated wallets](/en/guides/segregated-wallets), [receipts](/en/guides/receipts) and [analytics](/en/guides/analytics). **Added — Historical series for your dashboard** * **`GET /v1/rates/history`**: the evolution of your account's FX rates (payout and payin side per point), with `day` or `hour` granularity and a signed `change_pct` per currency — ready for the rate chart with its "+3.4% / −3.0%" badge. Includes the USD reference series for BTC and GOLD. * **`GET /v1/balances/history`**: the daily evolution of your balances — one series per asset with each day's closing balance (no gaps), the aggregated USD series valued at each day's historical price, the period's inflows/outflows and the current snapshot — everything needed for the balance card with a chart. * Rate history starts with a \~90-day backfill of daily rates and is recorded continuously going forward. Full examples in [analytics](/en/guides/analytics). **Added — PDF receipts with authenticity verification** * Every transactional product has its **branded PDF receipt**: `GET .../receipt` on payouts, payins, transfers, crypto withdrawals and deposits (new `deposit_id` in `GET /v1/crypto/transactions`), swaps and card purchases. Languages `?lang=es|en`. * **`receipt_url`** on every response of those products and on final-state webhooks: the front end never builds the URL by hand. * **Public authenticity verification**: every PDF carries a signed code with a QR that opens `GET /verify/receipts/{code}` (no credentials) — JSON for APIs and a branded web page for browsers, always showing the **real, current** status and amount, never the beneficiary's personal data. * Receipts of **non-completed** operations carry a diagonal watermark ("PROCESSING" / "FAILED"): an in-flight PDF can never pass as proof of payment. * **Automatic email** with the PDF attached when the operation reaches a final state, with per-account opt-out (`PATCH /v1/me` with `receipt_emails: false`). **Added — Branding** * `GET /v1/branding`: the platform's effective branding (logo, colors, name) so a white-label front end can theme itself from the API. **Changed** * The PDF [statement](/en/guides/statement) now renders with the brand's **real logo** and the Inter typeface (previously a typographic wordmark), and the Excel includes the logo on the summary sheet. Full guide in [receipts](/en/guides/receipts). **Added — Segregated wallets (company accounts only)** * On-chain wallets with **their own balance** (outside the ledger): create (`POST /v1/wallets`), list and get, **import** an external wallet with its key (`POST /v1/wallets/import`), **export** the private key (`POST /v1/wallets/{id}/export`, shared custody) and **send** crypto directly from the wallet (`POST /v1/wallets/{id}/sends`). * Live on-chain queries: `GET .../balance` (includes gas), `.../deposits` and `.../transactions`; configurable **auto-forward** (`GET`/`POST .../auto-forward`). * Send **gas** is on the client: without gas the send returns `422 insufficient_gas`. Import and export require a signed-in user session with 2FA. * New fees: `wallet_import`, `wallet_export`, `wallet_send`. * New webhooks: `wallet_deposit_received`, `wallet_send_status_changed`, `wallet_key_exported`. New service flag: `wallets`. * The [statement](/en/guides/statement) and [dashboard](/en/guides/analytics) include a segregated wallets section. Full guide at [segregated wallets](/en/guides/segregated-wallets). **Added — Account profile, credentials and security** * **Password**: self-service change (`POST /v1/me/password`, revokes all other sessions) and code-based recovery (`POST /v1/auth/password/forgot` → `POST /v1/auth/password/reset`) via email or verified phone. Forgot always returns 200 (never reveals whether the account exists). * **Login email**: verified change (`POST /v1/me/email/change` → `confirm` with the code sent to the **new** email) and verification of the current one (`POST /v1/me/email/verify`). * **Permanent alias** (`PUT /v1/me/alias`) and **profile QR** (`GET /v1/me/qr`): identify your account to **receive** transfers. Transfers accept `to_alias` and `to_qr_token`; `GET /v1/resolve` previews the recipient before sending. * **Profile photo**: `PUT`/`DELETE /v1/me/avatar` and `GET /v1/avatars/{id}`. * **Self-service 2FA** (`GET`/`PUT /v1/otp/preferences`): enable and pick the channel per action — now also **email** and **authenticator app (TOTP)** in addition to SMS/WhatsApp. Harden freely; weakening requires verification. * **Authenticator app (TOTP)**: `POST /v1/me/totp/enroll` (QR) → `confirm` (returns 10 one-time backup codes), `DELETE`, and `POST /v1/me/totp/recovery-codes` to regenerate them. * **Passkeys (WebAuthn)**: passwordless sign-in with the device's biometrics (Face ID, Touch ID, Windows Hello, security keys). Registration (`/v1/me/passkeys/register/begin|finish`), management (`GET`, `DELETE`) and login (`/v1/auth/passkey/login/begin|finish`). * **Sessions and activity**: `GET /v1/me/sessions` + revoke one or all, and `GET /v1/me/security/events` (account security history). * Email alerts on sensitive events (password or email change, factor added/removed). **Added — Reusable verified identity (unified KYC/KYB)** * A customer's approved KYC/KYB verification becomes their **single identity** inside CBPay: their data and documents are reused across the other products without re-typing or re-uploading. Guide: [reusable identity](/en/guides/kyc#one-verification-for-everything-reusable-identity). * **Cards**: your account's first issuance auto-fills the cardholder's identity and documents **from your approved verification** — you only send `occupation` and `salary_usd`. Explicit fields still win. * **Compliance report (KYB)**: `GET /v1/kyb/submissions/{id}/report` downloads the verification's signed compliance report (PDF). **Changed — Breaking** * **`POST /v1/banking/third-parties`** now requires the `verification_id` of an **approved** verification of the third party. The `type` comes from the kind (KYC ⇒ INDIVIDUAL, KYB ⇒ COMPANY), identity auto-fills and the already-validated documents are re-delivered to the banking provider (`documents_synced`). Existing third parties keep operating. * **`POST /v1/cards`** for designated persons (company accounts) now requires `cardholder.verification_id` of that person's **approved** KYC; their identity and documents come from the verification. * New errors: `422 verification_required`, `422 verification_not_approved`, `422 verification_kind_mismatch`, `422 verification_invalid`. **Added — Account summary (analytics) + third-party banking users** * **`GET /v1/analytics/summary`**: in a single call, every series and statistic of your account to build your dashboard — gross volume (in/out), transactions and new users per period (day/week/month, with comparison vs the previous period), global per-country view, and a section for EVERY service (payouts, payins, deposits, withdrawals, transfers, swaps, cards, banking, KYC/KYB, AML, contacts) with their dimensions (country, currency, method, status, chain, merchant). Plus `spending` (what you consumed in fees per service) and USD-valued `balances`. New guide: [Your account summary](/en/guides/analytics). * **Third-party banking users (companies only)**: `POST/GET /v1/banking/third-parties` (+documents, submit, accounts, balance) to register your end clients as separate banking users, with their own identity/KYC and accounts in their name. Isolated per account. * **New limit**: person accounts can hold at most 1 bank account (`409 banking_account_limit`). **Changed — Bolivia and Venezuela rates** * The USD→BOB and USD→VES rates in `GET /v1/rates` now reflect the market we actually operate your payments with (previously a reference rate was published that did not match the applied value). * If one of those rates is temporarily unavailable, the country is omitted from `GET /v1/rates` and operations in that currency return `422 currency_not_supported` until it is back — we never quote with an incorrect rate. We recommend checking `GET /v1/rates` (or subscribing to the rates webhook) before quoting payments in `BOB` or `VES`. **Added — Swaps: convert between your balances** * New `swaps` product: convert between `USDT`, `USDC`, `BTC` and `GOLD` instantly, without the money leaving your account — any pair, including direct `BTC` ↔ `GOLD`. `POST /v1/swaps` (synchronous, with `idempotency_key`), `GET /v1/swaps/quote` (free indicative quote) and `GET /v1/swaps` (+`/{id}`) for history. * The quoted rate is your account's execution rate: quoted = received, no separate fees. Live BTC/GOLD prices (if the price is not fresh the swap is rejected with `503 pricing_unavailable`). * Conversions touching BTC/GOLD share the per-operation and 24h volume limits with payouts and card purchases (`GET /v1/settlement`). New guide: [Swaps](/en/guides/swaps). **Added — Contacts and sending by phone number** * **Contact book** (`/v1/contacts`): full CRUD with search and favorites. Every send (transfer, payout, crypto withdrawal) **saves its destination as a contact automatically** — deduplicated; opt out with `"save_contact": false`. * **Phone address book import** (`POST /v1/contacts/import`, up to 1,000 per request): normalizes phones to E.164 and tells you which contacts **already have CBPay** (`has_cbpay`, matching only within your operator). * **Transfer by phone**: `POST /v1/transfers` accepts `to_phone` (only accounts with an **OTP-verified** phone; ambiguity answers `422 recipient_ambiguous`) and `to_contact_id`. * **Quick send to contacts**: `beneficiary_contact_id` on payouts (uses the contact's saved beneficiary) and `to_contact_id` on crypto withdrawals (uses its saved address). New guide: [Contacts](/en/guides/contacts). **Added — KYC/KYB identity verification (hosted wizard, OCR documents and video liveness)** * **Mandatory onboarding**: every new account must approve its identity verification (person ⇒ KYC, company ⇒ KYB) before operating. Until then it can only **fund** (payins, crypto deposits, incoming transfers) and read; everything else answers `403 verification_required`. Request your link with `POST /v1/me/verification/link` and check your state with `GET /v1/me/verification` — approval updates your `kyc_status` automatically. Existing accounts were grandfathered as approved. * **Third-party verification (company accounts only)**: generate hosted links (`POST /v1/kyc/links`, `POST /v1/kyb/links`) or send data through the API (`POST /v1/{kyc,kyb}/submissions`), upload documents with presign + OCR and close the liveness check with liveness links. New fixed fees `kyc_verification` / `kyb_verification` billed at creation (mandatory `idempotency_key`, automatic refund on failure). * 7 new webhooks: `kyc/kyb_verification_status_changed`, `kyc/kyb_link_completed`, `kyc/kyb_document_validated`, `kyc_liveness_completed`. Full guide at [KYC and KYB verification](/en/guides/kyc). **Changed (BREAKING) — Screening becomes AML** * `POST /v1/kyc`, `POST /v1/kyc/rescreen` and `PATCH /v1/kyc/monitoring` were **removed**: list screening now lives at `POST /v1/aml/screenings`, `POST /v1/aml/rescreen` and `PATCH /v1/aml/monitoring` (same semantics, same `compliance_*` fees). The `no_kyc` error becomes `no_screening` and screening no longer touches your `kyc_status`. New `aml_screening_updated` webhook and new `aml` service flag (the `kyc` flag now gates identity verification). Guide: [AML screening](/en/guides/aml). **Fixed — Banks catalog without `method` in countries with several methods** * `GET /v1/payouts/banks?country=VE` answered `400` asking for `method`, and `?country=BO` answered `400 payout_corridor_unsupported`. The catalog **without `method` now returns the union of every payout method's banks for the country** (deduplicated by code), as this documentation promises; passing `method` scopes it to a single channel (parameter now documented in the reference). **Added — Card purchases from BTC and GOLD (at-the-moment conversion)** * `spending_asset` now also accepts **BTC and GOLD**: purchases convert at the **effective price of the moment of each event** (the same one in the `settlement` block of `GET /v1/rates`). * **Authorization**: the equivalent is reserved plus a small cushion (not a charge; returned at settlement). If the execution price is unavailable, the purchase is declined with `pricing_unavailable` — your balance is never converted with an untrustworthy price. * **Settlement**: the final amount is re-quoted at the capture moment's price and the cushion's excess returns automatically. **Reversal** of an authorization: exact amount returned, no conversion. **Refunds/adjustments** after capture: re-converted at the price of the event's moment (your balance takes the price variation). * BTC/GOLD purchases share the account's volatile-asset limits with payouts: per operation (`settlement_limit_exceeded`) and 24h volume (`settlement_daily_limit_exceeded`). **Added — Choose which balance your cards spend from (USDT or USDC)** * Each card now has a **spending asset** (`spending_asset`): its purchases debit the account's USDT or USDC balance, 1:1 with the USD and with no conversion fee. USDT by default (identical to the historical behavior). * Set it when creating the card (`spending_asset` in `POST /v1/cards`) or change it any time with `PATCH /v1/cards/{cardID}`. The change only applies to future purchases: in-flight authorizations keep (and refund to) the asset they debited. * Card transactions now expose `spend_asset` and `spend_amount` (the balance and amount actually debited); `amount_usd` / `amount_usdt` remain the USD reference value. Per-card limits are still measured in USD. * New errors: `400 spending_asset_unavailable` (BTC/GOLD are not available for card purchases) and `spending_asset_disabled` authorization declines if your operator disables the asset. **Changed — Multi-asset settlement hardening** * Payments from BTC/GOLD now have, on top of the per-operation limit, a **rolling 24h per-account volume cap** (`422 settlement_daily_limit_exceeded`). It shows in `GET /v1/settlement` as `volatile_daily_limit_usdt`. * **Card** fees (issuance, cancellation and the monthly fee) are now also debited from your default settlement balance, like every other service. Card **purchases** still settle in USDT. **Added — Pay payouts and services from any balance (multi-asset settlement)** * Payouts and service fees (KYC, wallet creation, banking) can now be debited from **any of your four balances** (USDT, USDC, BTC, GOLD). Pricing is still quoted in USDT; the total translates to the chosen asset at the effective settlement price of the moment. Details in the [money model](/en/concepts/money-model#choose-which-balance-pays). * New `GET/PUT /v1/settlement`: set your account's **default balance** (`default_settlement_asset`). Per-operation override with `settlement_asset` in `POST /v1/payouts` and in the QR confirm. * The payout response now records `settlement_asset`, `settlement_amount` (the exact amount debited — also the amount refunded on failure, never re-quoted) and `settlement_rate`. * `GET /v1/rates` adds a `settlement` block with the effective price per enabled asset, and `asset_prices` now carries `source`, `updated_at` and `settlement_grade` (whether the price is fit to execute). * New errors: `503 pricing_unavailable` (BTC/GOLD execution price unavailable), `400 settlement_asset_disabled`, `400 invalid_settlement_asset` and `422 settlement_limit_exceeded` (per-operation limit for volatile assets). **Changed — Short reference for announced bank transfers** * `POST /v1/payins` with `method: "bank_transfer"` now returns a **short 12-character alphanumeric `reference`** (e.g. `CBW4N8R2T6P9`) instead of the UUID: bank concept fields have hard limits (Paraguay/SIPAP caps them at 20 characters with no special characters) and the UUID never fit. * Automatic matching accepts the new reference **and** keeps accepting the UUID from old announcements — existing `pending` payins are unaffected. The amount+currency fallback is unchanged. * `GET /v1/payins` and the detail expose the announce reference in `reference` while the payin is `pending`. **Added — Payins in Paraguay (announced bank transfer)** * New collection corridor `PY`/`PYG`/`bank_transfer`: announce the deposit with `POST /v1/payins`, your payer transfers (SIPAP or an internal transfer at the receiving bank) with the `reference` in the concept, and the credit arrives automatically in USDT at your `payin_rate`, like in every country. Guide in [payins](/en/guides/payins). * Guaraníes use no decimals: announce the **exact integer amount** (e.g. `"596000"`). The amount+currency fallback match applies as usual. * The corridor shows up in `GET /v1/payins/methods` with `delivery: polling`. **Added — Multi-currency virtual balances (USDT, USDC, BTC, GOLD)** * Every account now holds **four independent virtual balances**: `USDT` (the operating currency), `USDC`, `BTC` (8 decimals, satoshis) and `GOLD` (grams of fine gold, 6 decimals, custodian-backed). They never mix and are never converted automatically. Details in [money model](/en/concepts/money-model). * **`GET /v1/balances`** always returns all four balances (zeros if you have not used that currency) and `GET /v1/movements` filters by currency with `?asset=`. * **Multi-currency internal transfers**: `POST /v1/transfers` accepts `asset` (`USDT` default, `USDC`, `BTC`, `GOLD`) — always between balances of the **same currency**, with no conversion and no fee. * **On-chain USDC**: create `eth`/`usdc` wallets, deposit and withdraw USDC over Ethereum. Every deposit credits its own asset's balance. Guide in [crypto](/en/guides/crypto). * **Reference prices**: `GET /v1/rates` includes `asset_prices` with each currency's USD reference price (BTC per unit, GOLD per gram) — for valuation only, no conversion and no spread. * **Multi-currency statement**: new `assets` section with each non-USDT balance reconciled independently (opening/inflows/outflows/closing and its own `balanced` flag), also in the PDF and Excel exports. * Payouts, payins, cards and service fees keep operating **exclusively against the USDT balance**. **Added — Social login (Google, Apple, Microsoft, Meta)** * **Passwordless sign up and sign in** with Google, Apple, Microsoft and Facebook via token exchange: your front end gets the credential with the provider SDK and exchanges it at `POST /v1/auth/oauth` for the CBPay session. Full guide in [social login](/en/guides/social-login). * **New endpoints**: `POST /v1/auth/oauth` (unified login + registration), `GET /v1/auth/oauth/providers` (enabled providers, public), `GET/POST /v1/me/identities` and `DELETE /v1/me/identities/{provider}` (link/unlink providers from the session). * **Integrates 2FA**: if the account enforces OTP on login, social login also returns `otp_required` + `pending_token`. * **Multi-method**: one account can have a password and several providers; auto-linking by email only happens if the provider returns it verified. * New error codes in the [catalog](/en/errors): `invalid_provider`, `provider_not_configured`, `invalid_credential`, `email_conflict`, `identity_taken`, `last_login_method`. **Fixed** * The "Collection updated" stamp on the Postman page now correctly shows how long ago it was updated (it previously left an empty indicator). **Added — OTP/2FA over SMS and WhatsApp** * **Two-step verification for sensitive actions**: your operator can require a one-time code (over SMS or WhatsApp) before login, payouts, crypto withdrawals, transfers, banking operations, revealing a card, issuing API keys, adding members or changing the phone. Full guide in [security and 2FA](/en/security-2fa). * **New endpoints**: `POST /v1/otp/challenges` (sends the code), `POST /v1/otp/challenges/{id}/verify` (returns the single-use `otp_token` for the `X-OTP-Token` header), `GET /v1/otp/challenges` (+ detail) and `GET /v1/otp/settings` (your effective policy). * **Two-step login**: with OTP active on `login`, `POST /v1/auth/login` returns `otp_required: true` + `pending_token`, and the session is issued at `POST /v1/auth/login/otp`. * **User sessions only**: `pk_` API keys are exempt — your server-to-server integrations do not change. * New error codes in the [catalog](/en/errors): `otp_required`, `otp_invalid`, `phone_required`, `phone_binding_cooldown`, `too_many_attempts` and more. **Documentation — person vs company and unified guides** * **New [persons and companies](/en/concepts/persons-companies) page**: ALL the differences between the two account types (wallets, cards, members, KYC/KYB) in a single table, with the errors each limit produces. * **Cards guide reorganized by account type**: "Person account" and "Company account" tabs, each with its complete flow (first card, subsequent ones, and for companies both corporate and employee issuance) — no more assembling the flow from scattered notes. * **Country examples back in their guides**: the per-corridor requests/responses for payouts and payins live INSIDE each product's guide again (one page per product, no jumping to a separate reference). Old URLs redirect. * **Postman with live freshness**: the Postman page now shows how long ago the collection was updated (seconds/minutes/days), on top of the date and version. * The compiled MD now includes the full endpoint reference and the documentation version. **Documentation — full site redesign** * **New navigation**: Getting started → Concepts → Integration flows → Products → Integration → Resources, with per-page icons and breadcrumbs. * **New pages**: [environment and testing](/en/environment-testing) (webhook tunnel for local dev + go-live checklist), [enabled services](/en/concepts/services), [statuses and lifecycle](/en/concepts/statuses) (including the failed payout `status_code` catalog), [movements and reconciliation](/en/concepts/movements-reconciliation) and [integration flows](/en/flows) with end-to-end diagrams. * **Payouts and payins split**: general guide + country reference with the real request and response of every corridor. * **Expanded guides**: quickstart closes the loop with webhooks; profile (`PATCH /v1/me`) and members with roles; complete idempotency endpoint table; webhook retry schedule; on-chain confirmation times; EUR banking accounts; banking errors in the catalog; FAQ with limits, cancellations and reconciliation. * **Cards: when to send `cardholder`, clarified.** The guide and spec now explain that an account's **first issuance** creates and verifies the holder (full data + mandatory documents) and that **subsequent** cards reuse it with no data — the minimal example previously implied data was never required. **Added** * **`payin_rate` in `GET /v1/rates`**: each country now carries your two rates — `rate` for payouts (dispersals) and `payin_rate` for payins (fiat collections/deposits). Quoted = credited, always. **Changed** * **Payin pricing now works like payouts**: a payin's FX pricing lives in your `payin_rate` (the credit converts at exactly that rate) and the payin fee becomes a **fixed amount per operation** — no separate percentages. Each payin's `fx_rate` field records the rate applied. See [fees](/en/concepts/fees) and the [payins guide](/en/guides/payins). * Credit conversions round down to the micro-USDT (debits keep rounding up), with at most 1 micro-USDT of difference. **Documentation** * **KYC/KYB: full identity field reference.** The `customer` object has always accepted many more optional fields than the examples showed (date of birth, nationalities, documents with issuing country, aliases, residences, company registry data…) and sending them makes the screening more precise. The [KYC guide](/en/guides/kyc) now documents every field, with full-identity examples and the deduplication rule. **Added** * **Card catalogs**: `GET /v1/cards/catalog/occupations` and `GET /v1/cards/catalog/business-activities` (searchable with `?q=`) to populate pickers. When designating a person, `occupation` must be a catalog **code**; for a company, so must `kind_of_business`. An out-of-catalog value is rejected with `400 invalid_occupation` / `400 invalid_kind_of_business` before reaching the issuer. See the [cards guide](/en/guides/cards). **Added** * **`GET /v1/services`**: effective map of the services enabled for your account (`payouts`, `payins`, `transfers`, `crypto`, `banking`, `kyc`, `cards`) — use it to decide what to show in your UI. Services are enabled per account according to your commercial agreement; when one is off, its actions answer the new `403 service_disabled` error (reads and money in flight are never blocked). **Added** * **Virtual and physical cards** that spend straight from the account's USDT balance, with no prefunding: every purchase is authorized in real time against the available balance and the card's limits. Persons: 1 virtual + 1 physical; companies: unlimited, for the company or for designated persons (e.g. employees). New endpoints `POST/GET /v1/cards`, `GET/PATCH /v1/cards/{id}` (limits and freeze/unfreeze), `POST /v1/cards/{id}/activate|cancel|reveal` and `GET /v1/cards/{id}/transactions`. See the [cards guide](/en/guides/cards). * **New billable services** (fixed, configurable, can be 0): `card_creation_virtual`, `card_creation_physical`, `card_monthly` (with no balance the card is frozen — no debt) and `card_cancellation`. * **New webhooks** `card_transaction` (authorized/annulled/adjusted) and `card_status_changed` (state changes, including automatic freezes). * **New ledger movement types**: `card_debit`, `card_refund`, `card_fee`, `card_fee_refund`. **Added** * **Chile: hosted payment page (`method: "fintoc"`)** on `POST /v1/payins`. The response carries a `payment_url` the payer opens to transfer from **any Chilean bank or wallet** (Banco Estado, Santander, Mach, Tenpo, Mercado Pago, among others); the deposit is detected, validated and credited automatically in USDT with the usual `payin_credited` webhook. Supports an optional `idempotency_key`: a retry returns the same payin and the same URL without opening a second payment session. See the [payins guide](/en/guides/payins). **Added** * **`from`/`to` date filters on every list endpoint**: `/v1/movements`, `/v1/payouts`, `/v1/payins` and `/v1/crypto/transactions` now accept `from`/`to` (YYYY-MM-DD, UTC, inclusive), on top of the usual pagination (`page`, `page_size` up to 200). Invalid dates return `400 invalid_range`. * **Query transfers**: `GET /v1/transfers` (list with pagination and date filters) and `GET /v1/transfers/{id}` — previously they could only be created. * **List webhook subscriptions**: `GET /v1/webhooks/subscriptions`. * **Idempotency on active collections**: `POST /v1/payins/collect` now requires `idempotency_key` (it executes a real charge; a retry never re-charges the payer). Same hardening for wallet creation (no double fee on retries) and admin adjustments. * Uniform pagination added to `members`, `crypto/wallets`, `deposit-accounts` and (admin) `orgs`. * **Account statement** (`GET /v1/reports/statement`): consolidates every movement of the period — payouts, payins, crypto, transfers and fees — into one auditable document with an exact accounting reconciliation (`opening + inflows − outflows = closing`, verified against the ledger). Three formats from the same endpoint: **JSON** for your web, **PDF** with CBPay branding and a multi-sheet **Excel** with numeric cells, filters and a movements sheet for auditors (`format=json|pdf|xlsx`, `lang=es|en`). The org admin can generate any of its accounts' statements. See the [guide](/en/guides/statement). **Improved** * **Visual flow diagrams across the documentation**: the money map in the introduction (everything entering and leaving the USDT balance), the payout lifecycle with debit/hold/refund, the two-step QR flow, the four payin modes converging into the credit, crypto deposit and withdrawal, the full banking lifecycle, KYC states, webhook delivery and retries, and the idempotency decision rule ("which key do I retry with?"). **Changed** * **New base URL: `https://api.qbank.cl/platform`** (previously `exchange.qbank.cl/platform`). The old domain keeps working as an alias, so no existing integration breaks — but use `api.qbank.cl` for everything new. All documentation, the spec and the Postman collection already point to the new URL. **Added** * **Banking**: real bank accounts for your account — receive, hold and send money over international banking rails (SEPA, SWIFT, ACH depending on the currency). 14 new endpoints under `/v1/banking/*`: * Banking profile: create, fetch, upload documents and submit for verification. * Accounts: open per currency, list and check live balances. * Beneficiaries: register, list and attach destination accounts. * Payments: quote (`prepare`, free) and execute `TRANSFER`/`WITHDRAW` with idempotency. * New webhooks: `banking_customer_status_changed` and `banking_operation_status_changed`. * New fees (fixed, configurable, refunded if the operation fails): `banking_customer`, `banking_account`, `banking_operation` — the `banking_fee` field on each response shows what was charged. * Full [Banking guide](/en/guides/banking) with the end-to-end flow and examples for every operation. **Improved** * **Fully localized API Reference**: titles, descriptions, fields and sidebar groups are now translated when browsing the documentation in Spanish (previously only the UI chrome switched languages). * Payouts guide reorganized: Brazil PIX now lives only under "Examples by country" (the duplicated section was removed); QR stays as the single separate flow section since it is a distinct flow (scan + confirm). * Webhooks: sample payload for **each of the 5 events**. * Quickstart: registration examples for both person **and** company. * **Postman collection expanded to 53 requests**: endpoints with several use cases now ship one request per case (a payout per country and method, payins per mode, person/company KYC, etc.), each with a ready-to-send body. * **Payins guide restructured by country**, matching payouts: a corridor matrix with each country's mode plus Chile / Peru / Mexico / Venezuela / Bolivia / Brazil tabs with their complete examples. * **New [FAQ page](/en/faq)**: sandbox, initial funding, pre-payout cost estimation, rate guarantees, arrival times, safe retries, deposits without a reference and more — day-one questions answered inside the docs. * Quickstart opens with the **key facts** table (base URL, auth header, slug, amount format, environment) and the `GET /v1/rates` response example with the cost-estimation formula. * Payouts: response examples for the methods and banks catalogs, plus a status table with the effect on your balance. Payins: catalog response example with the meaning of `delivery`. **Improved** * **Complete per-use-case examples across the documentation**: * Payouts: an example for every country and method with its real `beneficiary` and response (Chile, Peru CCI + Yape, Mexico CLABE + debit card, Venezuela Pago Móvil + bank transfer, Bolivia ACH, Brazil PIX, Paraguay). * Payins: Bolivia and Brazil QR side by side, active collection `c2p` and `debito_inmediato` with the OTP response, dedicated deposit account. * KYC/KYB: person, company and minimal autofilled requests, with the screening, rescreening and monitoring (enable/disable) responses. * Transfers: by email, by `account_id`, company→person (payroll) and idempotent replay. * Crypto: person vs company wallet creation, and the `wallet_limit_reached` error. * API Reference: selectable named examples on every endpoint (10 payout corridors, 3 payin modes, person/company KYC…). **Added** * **Brazil (BRL) with PIX** documented for payouts and payins: * `pix` payout by key (CPF/CNPJ, phone, email or `evp` random key) via `POST /v1/payouts`. * Payout to a PIX QR (static or "copia e cola") via the `qr/scan` + `qr/confirm` flow with `country: "BR"`. * Payin with a dynamic PIX QR via `POST /v1/payins` (`method: "qr"`, `country: "BR"`), carrying the QR image and the "copia e cola" code. * Payin by announced bank transfer (`method: "bank_transfer"`). Corridor enablement is gradual; the catalog (`GET /v1/payouts/methods`, `GET /v1/payins/methods`) reflects availability at any given time. **Added** * **Every collection (payin) method now available through the API**: * `POST /v1/payins` now accepts `method`: `qr` (QR charge, as before) or `bank_transfer` (announce an incoming deposit and get the reference the transfer must include to be credited automatically). * `POST /v1/payins/collect` — active pull collection in corridors that support it (e.g. Venezuela `c2p` / `debito_inmediato`), with synchronous crediting; `POST /v1/payins/collect/otp` for the prior OTP when the method requires it. * `POST /v1/payins/deposit-accounts` — fixed dedicated deposit account (e.g. a Mexican CLABE) bound to your account: everything arriving to it is credited automatically. `GET /v1/payins/deposit-accounts` to list them. * Full corridor and method matrix for payouts in the guide (Chile, Peru with `yape`, Mexico SPEI, Venezuela with `pago_movil`, Bolivia with `qr`, Paraguay). * Venezuela (VES) joined the `GET /v1/rates` quotes. **Added** * **Bolivia QR payout**: pay any Bolivian collection QR in two steps — `POST /v1/payouts/qr/scan` (free, returns the recipient's data) and `POST /v1/payouts/qr/confirm` (charged like a regular payout: your rate + fixed fee, with a synchronous final result and automatic refund on failure). * Bolivia (BOB) joined the `GET /v1/rates` quotes. **Added** * New **[Postman](/en/postman)** page: official downloadable collection with all 25 endpoints, example bodies and pre-configured authentication. Regenerated with every API version. **Changed** * The Fees page and payout examples now reflect the current pricing model: payouts are charged **at your rate + a fixed fee per operation** (no separate percentage). Dispersing the equivalent of 100 USDT debits 100 USDT plus your configured fixed fee. **Improved** * `GET /v1/rates` now returns **your account's own exchange rate** per country: the same rate your operations execute at (`local_amount / rate = USDT`), with no difference between what is quoted and what is charged. **Removed (Breaking)** * `GET /v1/crypto/deposit-address` (the alias deprecated in v1.4) was removed for good. Use `POST /v1/crypto/wallets` to create wallets and `GET /v1/crypto/wallets` to list them. **Added** * **Multiple wallets for companies**: company accounts can now create **unlimited wallets per network** (persons keep 1 per network). * New endpoints: `POST /v1/crypto/wallets` (create a wallet, with an optional `label` to tell them apart) and `GET /v1/crypto/wallets` (list my wallets). Every creation bills the fixed `wallet_creation` fee when configured. * New `422 wallet_limit_reached` error when a person tries to create a second wallet on the same network. * Wallet responses now include `wallet_id` and `label`. **Changed** * The Crypto guide was reorganized into: **create wallet, view my wallets, deposit, transfer and movements**. * `GET /v1/crypto/deposit-address` remains as a deprecated legacy alias: use the wallet endpoints instead. **Fixed** * Copy and translation polish in both languages; the movements table now includes the `wallet_creation_fee` and `wallet_creation_refund` entry types. **Improved** * Professional-grade API Reference: all 25 endpoints now include request and response examples for **every case** (success, idempotency replay, and each possible error with its real body), ready to try from the docs playground. * The 5 webhooks are now documented inside the API Reference itself (standard OpenAPI Webhooks section), with schema and example payload for each event. * Methods and banks catalogs documented with the system's real response shapes. * `GET /healthz` endpoint documented (service status). * The Crypto guide adds **"Wallet balance and activity"**: how to check your balance, on-chain activity with `tx_id`, and the accounting history. * Brand-voice copy: the whole documentation now speaks as **CBPay** (it previously used generic wording like "your operator" or "the organization"). * Identity verification is now named **KYC/KYB** across the documentation (KYC for persons, KYB for companies). * Internal transfers: explicitly documented that they work between **any combination** of accounts (person↔person, person↔company, company↔company) and are **always free**. **Added** * New `wallet_creation` fee service: the first creation of a deposit address on each chain may carry a fixed charge configured by CBPay (0 = free, the default). The `GET /v1/crypto/deposit-address` response now includes `creation_fee`, and the movements history adds the `wallet_creation_fee` and `wallet_creation_refund` entry types. Fetching an existing address remains always free; if creation fails, the charge is refunded automatically. * New **Changelog** page (this page) with the version history of the API and documentation. **Changed** * The Crypto guide now has an explicit **"Create your wallet"** section explaining per-network creation (201 on first call with `creation_fee`, free 200 afterwards), and the API Reference renames the endpoint to "Create or get my wallet (deposit address)". **Added** * Per-operation compliance fees: `compliance_person`, `compliance_company`, `compliance_rescreen` and `compliance_monitoring` (fixed per-call charge; 0 = free). KYC responses now include `compliance_service` and `compliance_fee`. * `POST /v1/kyc/rescreen` and `PATCH /v1/kyc/monitoring` endpoints (disabling monitoring is free). Both require a prior KYC (`409 no_kyc`). **Changed** * Official CBPay brand identity applied across the documentation. * Administration documentation moved to CBPay's internal portal; this site now covers the account API only. **Initial release** * Public CBPay API documentation, bilingual (Spanish and English): authentication (JWT sessions and `pk_` API keys), USDT money model, fees, idempotency, multi-country fiat payouts, payins, internal transfers, crypto (on-chain funding and withdrawals), KYC, signed webhooks and the full error catalog. * Interactive API Reference generated from OpenAPI 3.1.