> ## Documentation Index > Fetch the complete documentation index at: https://docs-api.kravata.co/llms.txt > Use this file to discover all available pages before exploring further. # Go Network settlements > Send stablecoins to Kravata through BitGo Go Network with payment instructions in the settlement notes, and receive COP in a Bre-B key or a bank account. If your company has **BitGo Go Network** enabled, you can fund an off-ramp by sending a stablecoin settlement to Kravata through Go Network. You write the payment instructions in the **notes** of the settlement. Kravata checks the people involved, converts the funds to COP and pays the beneficiary in Colombia, either to a **Bre-B key** or to a **bank account**. Kravata then answers with a response settlement that tells you the result. You do not call the Kravata API to create these payments. Everything travels in the settlement. ## How it works **1. Kravata enables Go Network for your company** Request it in [Company sign-up](https://docs-api.kravata.co/stack/company-signup.md) under **Products that require Kravata**. Kravata reviews the request and enables it. Ask your Kravata point of contact which Go account to send to. **2. You send the settlement** From your Go Network account, create a settlement to Kravata's Go account with one stablecoin transfer and put the payment instructions in the settlement notes as a JSON object (see [Notes fields](#notes-fields)). Authorize the settlement on your side: Kravata waits for your authorization and rejects the payment if it does not arrive in time. **3. Kravata checks the notes and the people** Kravata validates the notes and registers the **ordering customer** (who sends the money) and the **beneficiary** (who receives the COP), if they do not exist yet. Both must pass KYC. While KYC is pending, the payment waits. **4. Kravata checks the payout destination** The Bre-B key or the bank account must exist and belong to the beneficiary. **5. Kravata creates the off-ramp in COP** When the checks pass, Kravata accepts the settlement and creates the off-ramp. Once the funds are settled, the COP payout is made to the beneficiary. **6. Kravata answers** Kravata sends you a response settlement with a [receipt or a rejection](#the-response-you-receive), matched to your payment by `end_to_end_id`. > [!NOTE] > > Send exactly **one** asset transfer per settlement, in an asset Kravata accepts for your company. Any other settlement is rejected with `UNSUPPORTED_ASSET`. ### Quote and rate `quote_id` is **optional**. If you send it, it must be a valid quote UUID issued to your company and still valid, and the off-ramp uses that quote. If it is not valid or has expired, the payment is rejected with `QUOTE_EXPIRED_OR_MISMATCH`. If you leave it out, Kravata creates the off-ramp without a pre-agreed quote. The receipt always shows the amount paid and the resulting `rate`. ## Notes fields The notes must be a **JSON object** (a JSON string). Keys are lowercase with underscores. | Field | Required | Meaning | Accepted values | | - | - | - | - | | `ordering_customer_id` | Yes | Document number of the ordering customer. It may start with the document type, for example `CC129876528`. | `CC` and `NIT` numbers: digits, dots and dashes only. Passport numbers may contain letters, and must contain at least one digit. | | `ordering_customer_name` | Yes | Full name of the ordering customer. | Free text. | | `ordering_customer_id_type` | No | Document type of the ordering customer. Default: `DNI`. | See [Document types](#document-types). | | `ordering_first_name` | No | First name. If omitted, Kravata derives it from the full name. | Free text. | | `ordering_first_surname` | No | First surname. If omitted, Kravata derives it from the full name. | Free text. | | `ordering_country` | No | Country of the ordering customer. | Country code, for example `PE`. | | `beneficiary_customer_id` | Yes | Document number of the beneficiary. Same format rules as the ordering customer. | See above. | | `beneficiary_customer_name` | Yes | Full name of the beneficiary. | Free text. | | `beneficiary_customer_id_type` | No | Document type of the beneficiary. Default: `CC`. | See [Document types](#document-types). | | `beneficiary_first_name` | No | First name. If omitted, Kravata derives it from the full name. | Free text. | | `beneficiary_first_surname` | No | First surname. If omitted, Kravata derives it from the full name. | Free text. | | `beneficiary_country` | No | Country of the beneficiary. | Country code, for example `CO`. | | `beneficiary_bank_account` | Yes | The Bre-B key, or the bank account number when the payout is a bank transfer. | Bre-B key, or digits only (spaces and dashes are removed). | | `beneficiary_account_type` | No | Selects the payout destination. Absent means Bre-B key. | See [Payout destination](#payout-destination). | | `beneficiary_bank_code` | Only for bank transfers | Code of the beneficiary's bank. | See [Bank codes](#bank-codes). | | `end_to_end_id` | No (recommended) | Your own reference for this payment. Kravata returns it in the response so you can match it. A reference that belongs to another payment that was not rejected is refused with `DUPLICATE_PAYMENT_REFERENCE`. | Free text. | | `quote_id` | No | Quote to apply. See [Quote and rate](#quote-and-rate). | UUID. | Names are split by Spanish convention when the first name and surname fields are missing: `Ana Pérez` gives first name `Ana` and surname `Pérez`; `Juan Carlos Pérez Gómez` gives `Juan` and `Pérez`. Send the explicit fields when the name does not follow that convention. ### Document types | You send | Kravata registers it as | | - | - | | `CC` | Colombian citizen ID (`CC`) | | `CE`, `DNI`, `FOREIGN_CC` | Foreign ID (`FOREIGN_CC`) | | `PA`, `PP`, `PAS`, `PASSPORT`, `PASAPORTE` | Passport | | `NIT` | `NIT` | If you leave out `*_customer_id_type`, Kravata uses the type written in front of the number (for example `CC129876528`). If there is none, it uses `DNI` for the ordering customer and `CC` for the beneficiary. If the prefix and the type field disagree, the message is invalid. A `CC` or `NIT` number with letters is also invalid. ## Payout destination ### Bre-B key (default) The payout goes to a Bre-B key when `beneficiary_account_type` is absent or has a Bre-B value: `BREB`, `BRE-B`, `LLAVE`, `LLAVE_BREB` or `KEY`. Put the key in `beneficiary_bank_account`. The key must exist and belong to the beneficiary. ```json theme={"dark"} { "ordering_customer_id": "A1234567", "ordering_customer_id_type": "PP", "ordering_customer_name": "Maria Quispe Rojas", "beneficiary_customer_id": "1012345678", "beneficiary_customer_id_type": "CC", "beneficiary_customer_name": "Carlos Gomez Diaz", "beneficiary_bank_account": "@carlosgomez", "end_to_end_id": "E2E-2026-000123" } ``` ### Bank transfer The payout is a bank transfer when `beneficiary_account_type` is `SAVINGS` or `CHECKING` (also accepted: `AHORROS` and `CORRIENTE`). In that case: * `beneficiary_bank_code` is **required**. See [Bank codes](#bank-codes). * `9999` is refused as a bank code: it is the Bre-B entry of the catalog, not a bank. For a Bre-B payout, leave `beneficiary_account_type` out. * `beneficiary_bank_account` is the account number, **digits only**. Spaces and dashes are removed before validating. * The account must belong to the beneficiary: the holder is checked against the beneficiary's document. Any other `beneficiary_account_type` value makes the message invalid. ```json theme={"dark"} { "ordering_customer_id": "A1234567", "ordering_customer_id_type": "PP", "ordering_customer_name": "Maria Quispe Rojas", "beneficiary_customer_id": "1012345678", "beneficiary_customer_id_type": "CC", "beneficiary_customer_name": "Carlos Gomez Diaz", "beneficiary_account_type": "SAVINGS", "beneficiary_bank_code": "1007", "beneficiary_bank_account": "123-456-7890", "end_to_end_id": "E2E-2026-000124" } ``` ## Bank codes Take the `code` of the bank from [Get Banks](https://docs-api.kravata.co/stack/api-reference/accounts/get-banks.md) (`GET /api/v1/admin/banks`, default `type=cashout`) of the Stack API, in the environment you are using. ```bash theme={"dark"} curl https://test-api-kore.kravata.co/api/v1/admin/banks \ -H "Authorization: Bearer ACCESS_TOKEN" ``` * Use the `code`, not the numeric `id`. * Banks that are not active are not accepted. * A code that is not in the list is rejected with `BANK_NOT_SUPPORTED`. ## The response you receive Kravata sends one response settlement per payment, with a small fixed transfer and a JSON message in its notes. The `notes` text is machine readable: `received= ; ref=; ramp=` for a receipt and `rejected=; ref=` for a rejection. Match the response to your payment with `end_to_end_id`. ### Receipt Sent when the COP payout is completed. ```json theme={"dark"} { "type": "RECEIPT", "status": "PAID", "notes": "received=4150000.00 COP; ref=E2E-2026-000124; ramp=7d1f0c3a-5b2e-4a9c-8e61-0f3b9a2c4d55", "ref": "E2E-2026-000124", "end_to_end_id": "E2E-2026-000124", "settlement_ref": "SETTLEMENT_REFERENCE", "settlement_external_id": "SETTLEMENT_EXTERNAL_ID", "ramp_id": "7d1f0c3a-5b2e-4a9c-8e61-0f3b9a2c4d55", "amount_sent": "1000.0", "asset_sent": "USDC", "amount_received": "4150000.00", "currency_received": "COP", "rate": "4150.0000", "destination_amount": "4150000.00", "destination_currency": "COP" } ``` | Field | Meaning | | - | - | | `ref` | Your `end_to_end_id`. If you did not send one, the settlement identifier. | | `ramp_id` | Kravata identifier of the off-ramp. Keep it for support requests. | | `amount_sent`, `asset_sent` | Amount and asset you sent. | | `amount_received`, `currency_received` | Amount paid to the beneficiary and its currency. | | `rate` | `amount_received` divided by `amount_sent`, 4 decimals. | | `destination_amount`, `destination_currency` | Amount paid with the decimals of the currency, dot separator and no thousands separator. | ### Rejection Sent when the payment cannot be completed. Nothing is credited to the beneficiary, so `destination_amount` is `0.00`. ```json theme={"dark"} { "type": "REJECTION", "status": "REJECTED", "notes": "rejected=BANK_NOT_SUPPORTED; ref=E2E-2026-000124", "ref": "E2E-2026-000124", "end_to_end_id": "E2E-2026-000124", "settlement_ref": "SETTLEMENT_REFERENCE", "settlement_external_id": "SETTLEMENT_EXTERNAL_ID", "reason": "BANK_NOT_SUPPORTED", "destination_amount": "0.00", "destination_currency": "COP" } ``` When a payment is rejected before it is accepted, Kravata also rejects the settlement on Go Network, so your funds are not taken. Fix the cause and send a new settlement. A rejected `end_to_end_id` can be used again. ### Rejection reasons The `reason` is a fixed code. It never includes details about the people involved. | Reason | Meaning | What to do | | - | - | - | | `INVALID_PAYMENT_MESSAGE` | The notes are not valid JSON or a field is missing or not accepted (for example an unsupported `beneficiary_account_type`, `beneficiary_bank_code` `9999`, an account number with letters or a document with the wrong format). | Fix the notes following [Notes fields](#notes-fields) and send again. | | `UNSUPPORTED_ASSET` | The settlement has more or fewer than one transfer, the asset is not accepted for your company, or the quantity is not valid. | Send one transfer in an accepted asset. | | `KYC_ORDERING_REJECTED` | KYC of the ordering customer was rejected or canceled. | Contact your Kravata point of contact. | | `KYC_BENEFICIARY_REJECTED` | KYC of the beneficiary was rejected or canceled. | Contact your Kravata point of contact. | | `KYC_PENDING_TIMEOUT` | KYC of one of the two people was not approved in time. | Ask the person to complete KYC, then send again. | | `PARTY_REGISTRATION_FAILED` | Kravata could not register the ordering customer with the data sent. | Check the document and name data and send again. | | `BREB_KEY_NOT_FOUND` | The Bre-B key does not exist or is not active. | Confirm the key with the beneficiary. | | `BREB_KEY_OWNER_MISMATCH` | The Bre-B key does not belong to the beneficiary. | Use a key owned by the beneficiary. | | `BANK_NOT_SUPPORTED` | The `beneficiary_bank_code` is not in the bank list of your company, or the bank is not active. | Take the code from [Bank codes](#bank-codes). | | `BANK_ACCOUNT_OWNER_MISMATCH` | The bank account does not belong to the beneficiary. | Use an account owned by the beneficiary, with the matching document. | | `PAYOUT_ACCOUNT_REJECTED` | Kravata could not accept the payout account for another reason (for example an invalid account number). | Check the account data and send again. | | `EXTERNAL_WALLET_REJECTED` | The sending wallet could not be registered. | Contact your Kravata point of contact. | | `QUOTE_EXPIRED_OR_MISMATCH` | The `quote_id` is not valid, expired or does not match the payment. | Request a new quote or send without `quote_id`. | | `OPERATION_REJECTED` | The off-ramp could not be created. | Contact your Kravata point of contact. | | `OPERATION_NOT_READY_TIMEOUT` | The off-ramp was not ready in time. | Send again; if it repeats, contact your Kravata point of contact. | | `TIER_LIMIT_EXCEEDED` | The amount exceeds the limit of the ordering customer's tier. | Send a smaller amount or ask for a higher tier. | | `COMPLIANCE_REJECTED` | The payment did not pass the compliance checks. | Contact your Kravata point of contact. | | `COUNTERPARTY_CANCELED` | The settlement was canceled or failed on Go Network before it completed. | Create a new settlement if you still want to pay. | | `COUNTERPARTY_NOT_AUTHORIZED` | You did not authorize the settlement in time. | Create a new settlement and authorize it. | | `DUPLICATE_PAYMENT_REFERENCE` | Another settlement with the same `end_to_end_id` was not rejected. | Use a new `end_to_end_id` for each payment. | | `PAYOUT_FAILED` | The COP payout failed after the funds were received. Kravata returns the funds in the response settlement. | Check the payout data and send again. | Payments that need a person at Kravata, for example a manual compliance review, stay pending until they are resolved and you receive the response afterwards. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.