¿Pruebas de integración? En el ambiente de test (
https://cryptobank.qbank.cl/platform, keys pk_test_) el firewall se comporta igual que en producción cuando tu org lo activa. Detalles en Ambientes y pruebas.Qué verás
Cuando una operación tuya queda retenida:- El estado cambia a
in_review— la operación no se ejecuta todavía. ElPOSTque la creó responde202 Acceptedconreview_id. - Recibes un webhook
txn_review_status_changedcon el estado nuevo. - Si te piden información, recibes un email con el motivo y un enlace para subir documentos.
Esto es normal. El firewall transaccional es una capa de control que tu organización activó para cumplir con políticas de compliance. La mayoría de las revisiones se resuelven en minutos u horas.
Consulta tus revisiones
Lista las operaciones tuyas que están o estuvieron en revisión:Filtros
?status=—in_review,info_requested,released,rejectedoall(vacío = abiertas:in_review+info_requested). Otro valor ⇒400 invalid_status.?from=/?to=— rango de fechas (YYYY-MM-DD, zona horaria de tu organización, ambos inclusive). Fecha inválida ⇒400 invalid_range.?page=/?page_size=— paginación (default 50, máximo 200).
Detalle de una revisión
404 not_found (nunca 403, para no filtrar existencia). Cuando la revisión fue rechazada, el detalle incluye decision_note (el mismo texto del email de rechazo) y decided_at.
Estados de una revisión
Rechazo automático por plazo. Si tu organización configuró un plazo de revisión, una revisión que nadie decide dentro de esa ventana (contada desde su último cambio de estado — subir evidencia reinicia el reloj) queda automáticamente rechazada por un barrido horario: la operación se cancela, los fondos retenidos vuelven a tu saldo y recibes el mismo email y webhook
txn_review_status_changed que con un rechazo manual. En el detalle, el decision_note lleva el aviso estándar de plazo vencido. Las revisiones de solicitudes jamás se auto-rechazan: una solicitud banking o de tarjeta retenida siempre espera una decisión humana, sin plazo.Solicitudes retenidas (banking y tarjetas)
Si tu organización activó la revisión de solicitudes (dos toggles separados, uno para banking y otro para tarjetas), estas llamadas también pueden quedar retenidas antes de procesarse:POST /v1/banking/customer— apertura de tu propio perfil bankingPOST /v1/banking/third-parties— registro de un tercero para bankingPOST /v1/cards— emisión de una tarjeta (virtual o física)
202 Accepted en vez de 201:
idempotency_key devuelve el mismo 202 con idempotency_hit: true — jamás abre una segunda revisión.
- El fee de la solicitud se cobra al retenerla. Si la revisión se rechaza, el fee se reembolsa automáticamente; si se aprueba, el perfil o la tarjeta se crean en ese momento.
- Sigue el resultado con el webhook
txn_review_status_changed(elkindserábanking_applicationocard_application) o consultandoGET /v1/me/txn-reviews. - La revisión también puede pedir información (
info_requested) — sube los documentos igual que en una revisión transaccional.
Sube documentos cuando te los pidan
Si tu revisión está eninfo_requested, sube los archivos de respaldo. El body es el binario crudo del archivo, el nombre viaja en el query param name y el tipo en el header Content-Type:
201 — al subir un archivo la revisión vuelve a in_review para que el equipo la re-evalúe:
- Tipos permitidos: PDF, PNG, JPEG, WEBP, TXT, CSV, DOC(X), XLS(X) — se valida por el header
Content-Type. - Tamaño máximo: 50 MB por archivo.
- Máximo 20 archivos por revisión.
Descarga tus propios archivos
Content-Type original (los archivos de otras cuentas responden 404 not_found).
Webhook txn_review_status_changed
Cada vez que el estado de una revisión tuya cambia, recibes este webhook:
El payload del webhook es neutro por diseño: incluye el estado y el resumen de la operación, pero jamás el motivo interno de la revisión ni notas de compliance.Para revisiones de solicitudes (
kind: banking_application / card_application) el payload omite amount y asset; method lleva el flujo de la solicitud (self/third_party) o el tipo de tarjeta (virtual/physical).Errores propios
Catálogo completo en Errores.
Preguntas frecuentes
¿Por qué mi operación quedó retenida?
¿Por qué mi operación quedó retenida?
Tu organización activó el firewall transaccional, una capa de control que retiene ciertas operaciones para revisión manual antes de ejecutarlas. Los criterios exactos dependen de la política de compliance de tu organización.
¿Cuánto tarda la revisión?
¿Cuánto tarda la revisión?
La mayoría de las revisiones se resuelven en minutos u horas. Si tu revisión lleva más de 24 horas sin respuesta, tu organización recibe una alerta automática. Si tu organización configuró un plazo de decisión, la revisión se rechaza automáticamente cuando el plazo vence — subir la evidencia pedida reinicia ese reloj.
¿Qué pasa si rechazan mi operación?
¿Qué pasa si rechazan mi operación?
La operación se cancela. Si había fondos retenidos (por ejemplo, en un payout), se devuelven automáticamente a tu saldo disponible. Recibes un email con el motivo del rechazo.
¿Puedo cancelar una operación que está en revisión?
¿Puedo cancelar una operación que está en revisión?
No directamente. Si necesitas cancelarla, contacta al equipo de compliance de tu organización — ellos pueden rechazarla desde su panel.
¿Por qué no veo el motivo de la retención?
¿Por qué no veo el motivo de la retención?
Por seguridad y para no comprometer investigaciones de compliance, el motivo interno nunca se expone al usuario final. Solo verás el mensaje de información solicitada cuando te pidan documentos.
Creé un perfil banking o una tarjeta y recibí un 202 — ¿qué pasó?
Creé un perfil banking o una tarjeta y recibí un 202 — ¿qué pasó?
Tu organización activó la revisión de solicitudes: la llamada quedó retenida antes de procesarse. Todavía no se crea nada — cuando compliance apruebe la revisión, el perfil o la tarjeta se crean automáticamente y recibes el webhook
txn_review_status_changed con status: released. El fee de la solicitud se cobró al retenerla; si la revisión se rechaza, el fee se reembolsa a tu saldo automáticamente.