POST /money_movements_return) — refunding a Colombian payin means initiating a brand new payout with Create a Money Movement (POST /money_movements) that sends the funds back to the original payer.breb_credit — generated when funds are received through a static Cobre Key.r2p_breb_credit — generated when funds are received through a Bre-B Direct Link or Checkout (Request to Pay over Bre-B). It carries the same sender fields plus a money_movement_id referencing the originating r2p_breb money movement.breb_credit or r2p_breb_credit.money_movement that you create back toward the original payer. Concretely, refunding requires:| Action | Endpoint | Purpose |
|---|---|---|
| Identify the original payin | Obtain one Transaction / Obtain one Account Transactions | Read the credit transaction you intend to refund and, for Bre-B, extract sender data from its metadata (breb_credit or r2p_breb_credit). |
| Register the payer as a counterparty | Create a Counterparty | Create a breb_key, cc, ch, or dp counterparty pointing back to the payer. |
| Send the refund | Create a Money Movement | Initiate a Bre-B, Fast Pay, or ACH payout for the refund amount. |
refund movement type and no geo: col variant of /money_movements_return. Any attempt to call the return endpoint for a Colombian credit will not apply.source_id must reference a Virtual Balance (Cobre Balance) or a Connect Account with geo equal to col, with sufficient balance to cover the refund.amount, currency (cop), and — for Bre-B — read the sender details. A refund amount must never exceed the original credited amount.breb_key counterparty is sent over Bre-B. A refund toward a cc, ch, or dp counterparty is sent over Fast Pay (if the destination institution supports it) or ACH (if it does not).POST /money_movements endpoint requires the idempotency header (string, min length 9), valid for 24 hours. Use a deterministic key derived from the original transaction id so retries never double-refund.metadata. This applies to both breb_credit (funds received through a static Cobre Key) and r2p_breb_credit (funds received through a Bre-B Direct Link or Checkout). This is everything you need to register the payer as a counterparty and send the funds back — no external lookup required.breb_credit transaction (static Cobre Key payin) looks like this:{
"id": "trx_4c5cb9b93c355520646ff2d6b24076",
"type": "breb_credit",
"account_id": "acc_8fB1S8wlaF",
"amount": 100000,
"previous_balance": 0,
"current_balance": 100000,
"currency": "cop",
"credit_debit_type": "credit",
"transaction_date": "2026-06-10T20:11:56Z",
"created_at": "2026-06-10T20:11:56Z",
"metadata": {
"sender_account_number": "78110264",
"sender_account_type": "ch",
"sender_bank_code": "1809",
"sender_id": "1018983923",
"sender_id_type": "cc",
"sender_name": "Juan Pérez",
"key_value": "@COBRECOMERCICB1QB6HQ",
"description": "Payin Bre-B"
}
}r2p_breb_credit transaction (Direct Link or Checkout payin) carries the same sender fields, plus a money_movement_id that references the r2p_breb money movement that generated the credit:{
"id": "trx_e340b2a53b5e1d64b25cfa27157f53",
"type": "r2p_breb_credit",
"amount": 100000,
"previous_balance": 0,
"current_balance": 100000,
"currency": "cop",
"credit_debit_type": "credit",
"transaction_date": "2026-05-20T20:43:23Z",
"created_at": "2026-05-20T20:43:23Z",
"metadata": {
"sender_account_number": "78110264",
"sender_account_type": "ch",
"sender_bank_code": "1809",
"sender_id": "1018983923",
"sender_id_type": "cc",
"sender_name": "Juan Pérez",
"key_value": "@CBI964MAQ",
"description": "R2P Bre-B",
"money_movement_id": "mm_InLDaOGhcHczoz"
}
}metadata fields you will reuse are identical across both types:| Bre-B credit field | Meaning | Used for |
|---|---|---|
sender_name | Name of the payer who sent the funds | counterparty_fullname |
sender_id | Payer's identification number | counterparty_id_number |
sender_id_type | Payer's identification type (e.g. cc) | counterparty_id_type |
sender_account_number | Payer's account number | account_number |
sender_account_type | Payer's account type (ch, cc, dp) | counterparty type |
sender_bank_code | Payer's bank code | beneficiary_institution |
key_valuein both transaction types is your receiving key (static forbreb_credit, the dynamic key forr2p_breb_credit), not the payer's. Forr2p_breb_credityou can also usemoney_movement_idto trace the refund back to the originating payin money movement.
The fastest refund path is registering the payer as a breb_keycounterparty and refunding over Bre-B. If you do not have the payer's Bre-B key, register them instead as acc,ch, ordpcounterparty (usingsender_account_typeas thetype) and refund over Fast Pay or ACH — see Scenario 2.
breb_key counterparty:{
"geo": "col",
"type": "breb_key",
"alias": "refund-juan-perez",
"metadata": {
"key_value": "@PAYERKEY123",
"counterparty_email": "juan.perez@example.co",
"counterparty_phone": "+573001112233"
}
}key_value is the only required metadata field for a breb_key counterparty. The response returns a counterparty id with the cp_ prefix.id as the destination_id, your Cobre Balance as the source_id, and the original credited amount (or a lower partial amount) as amount in cents.{
"amount": 100000,
"source_id": "acc_8fB1S8wlaF",
"destination_id": "cp_TRLlPDNQGZ",
"metadata": {
"description": "Refund trx_4c5cb9b93c"
},
"external_id": "refund_trx_4c5cb9b93c"
}breb_key destination, the metadata is the Bre-B variant: description is required (max 40 characters) and is informative only. A successful call returns a money_movement with type: breb, geo: col, currency: cop, and status.state: initiated.Set external_idto a value derived from the original transaction so the refund is traceable back to the payin in reports and reconciliation.
sender_account_number, sender_bank_code, or sender_name to read. To refund, you must obtain the payer's account information through your own channel (for example, from the order record, customer support, or by asking the payer) and then register them as a counterparty.counterparty_id_type, counterparty_id_number).beneficiary_institution, from the Colombian Bank Codes catalog).account_number and account type (cc, ch, or dp).cc, ch, or dp counterparty{
"geo": "col",
"type": "cc",
"alias": "refund-order-9931",
"metadata": {
"counterparty_fullname": "Juan Pérez",
"beneficiary_institution": "1007",
"account_number": "051304546110",
"counterparty_id_type": "cc",
"counterparty_id_number": "1018983923"
}
}cc/ch/dp counterparty, counterparty_fullname, beneficiary_institution, account_number, counterparty_id_type, and counterparty_id_number are all required.{
"amount": 50000,
"source_id": "acc_8fB1S8wlaF",
"destination_id": "cp_KL1CfGa9iO",
"metadata": {
"description": "Refund order 9931"
},
"external_id": "refund_order_9931"
}cc/ch/dp destination the metadata is the Fast Pay variant when the destination institution supports Fast Pay, otherwise the ACH variant. In both, description is required (max 40 characters). The response returns type: fast_pay or type: ach, geo: col, currency: cop.initiated → processing → completed, or failed/rejected). See Notifications & Subscriptions.breb_debit for Bre-B refunds, col_debit for Fast Pay/ACH refunds), offsetting the original credit.external_id. Because the refund is an independent money movement, link it back to the original payin through the external_id you set, and filter via GET /money_movements?external_id=... or in Reports.completed, a refund money movement cannot be undone through the API; a correction would itself be a new money movement.