Cobra en un terminal POS físico y devuelve la transacción que quedó esperando a que el cliente final pase la tarjeta.

El 201 no significa que el cliente pagó: significa que el terminal tomó la venta y todavía tiene que operarla. El resultado del cobro llega por el webhook de transacción —transaction.success o transaction.failed—, que devuelve el external_id con el que la caja correlaciona la operación. Ese mismo estado se puede consultar con GET /transactions/{public_id_transaction}: el cobro POS no tiene un endpoint de estado propio.

Se envía una de tres formas, nunca más de una: ids_invoice, para saldar deudas ya creadas; amount junto con currency e id_account, para cobrar un monto suelto; o invoice_data junto con id_account y un Customer (id_customer o customer_data), para crear la deuda y saldarla en el mismo paso. No se envía medio de pago: la tarjeta la lee el terminal.

Abre una Checkout Session en estado OPEN y despacha la venta al terminal. Esa sesión es el contenedor del intento de cobro y se cierra sola cuando el cobro termina: a diferencia de los demás productos, no es una página que se renderice ni tiene una url a la que derivar al cliente. Si el terminal no toma la venta, la sesión queda EXPIRED y no se cobra nada.

El terminal y las deudas tienen que pertenecer a la organización autenticada, y hoy los únicos terminales habilitados son los chilenos (country_code = cl).

Cualquier campo que no esté en el contrato se rechaza con 422: la caja no cobra distinto de lo que pidió.

Si se envía idempotency_key, ese valor no puede repetirse dentro de la organización: un reintento por timeout se rechaza con 409 en vez de cobrar dos veces.

{
  "id_account": "acc_123abc",
  "id_customer": "cus_123abc",
  "id_pos_terminal": "pos_123abc"
}

{
  "id_checkout_session": "9c1f7f2e-6f4a-4a1e-9d3b-2f8c5b7a1d40",
  "transaction": {
    "expiration_date": "2026-08-12T18:00:00+00:00",
    "id_transaction": "trs_7QpK4mZ0RbS2vXhTyLnE9wJdA3cF6uGx",
    "status": "INITIALIZED"
  }
}