--- title: Devoluciones y Anulaciones slug: devoluciones-y-anulaciones docTags: createdAt: 2026-03-31T11:03:40.619Z --- # Definición El proceso de devoluciones y anulaciones en SUGA permite revertir total o parcialmente una transacción aprobada, devolviendo los fondos al tarjetahabiente a través del circuito adquirente inverso. Este proceso no es una operación simple: implica una interacción coordinada entre la plataforma, el procesador, las marcas (redes de tarjetas) y el banco emisor, y genera un cambio de estado definitivo en el ciclo de vida de la transacción dentro del modelo SmartOperation de SUGA. La distinción entre anulación y devolución no es semántica: tiene consecuencias técnicas, financieras y de estado distintas dentro de la plataforma, y depende del momento en que se ejecuta la operación respecto al cierre del lote de liquidación del día. | **concepto central: anulación vs. devolución** | | ----------------------------------------------------------------------------------------------------------------------- | | Anulación → se ejecuta el mismo día de la transacción (antes del cierre del lote) → estado: 601 Cancelada | | Devolución total → se ejecuta al día siguiente o posterior → estado: 602 Devuelta | | Devolución parcial → solo posible desde el día siguiente → la operación queda en estado: 605 Parcialmente devuelta | | Ambas afectan el circuito adquirente inverso: la marca notifica al emisor para reintegrar los fondos al tarjetahabiente | # Rol dentro del circuito adquirente El esquema adquirente de SUGA define el circuito completo de una transacción de pago entre el tarjetahabiente, el comercio, el adquirente, las marcas y el banco emisor. El proceso de devolución y anulación opera sobre ese mismo circuito, pero en sentido inverso: los fondos que en la operación original fluyeron del emisor hacia el adquirente y luego al comercio, ahora deben fluir de regreso hacia el tarjetahabiente. El adquirente, es quien inicia y procesa la solicitud de reversa hacia el procesador y las marcas. La plataforma abstrae la complejidad de ese circuito inverso y lo expone como una operación simple desde la perspectiva del comercio o el operador. | **actor** | **rol en el pago original** | **rol en la devolución / anulación** | | ---------------------------------- | --------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- | | **Tarjetahabiente** | Inicia el pago. Sus fondos son debitados por el emisor | Recibe el reintegro. El emisor acredita los fondos en su cuenta | | **Comercio** | Solicita el cobro a través de la plataforma | Solicita la devolución o anulación a través de la plataforma. Recibe el débito del monto devuelto en su liquidación | | **SUGA (adquirente)** | Procesa los datos de la tarjeta y envía la solicitud de autorización a las marcas | Procesa la solicitud de reversa y la envía al procesador / marcas. Actualiza el estado del cupón en SmartOperation | | **Marcas (Visa, MC, Cabal, Amex)** | Analiza y monitorea la transacción. Solicita autorización al banco emisor | Recibe la reversa del adquirente y notifica al banco emisor para que reintegre los fondos | | **Banco Emisor** | Aprueba o rechaza la autorización. Debita los fondos del tarjetahabiente | Recibe la instrucción de reversa de las marcas. Acredita los fondos al tarjetahabiente | # Tipos de operación de reversa ## Anulación (mismo día) La anulación se ejecuta cuando la devolución se solicita el mismo día en que se realizó la transacción, antes del cierre del lote de liquidación nocturno. Técnicamente, la operación aún no fue presentada a las marcas para su liquidación, por lo que puede ser cancelada directamente sin generar un movimiento financiero inverso completo. Desde la perspectiva del tarjetahabiente, la anulación del mismo día puede aparecer como que la transacción nunca ocurrió, dependiendo de los tiempos de procesamiento del banco emisor. El estado resultante en SmartOperation es 601 — Cancelada. | **condiciones de la anulación** | | ------------------------------------------------------------------------------------ | | Momento de ejecución → mismo día de la transacción (antes del cierre del lote) | | Estado resultante en SmartOperation → 601 Cancelada | | Impacto financiero → la operación no se incluye en la liquidación del día | | Visibilidad para el tarjetahabiente → puede no reflejarse como cargo en el resumen | ## Devolución total (día posterior) La devolución total se ejecuta cuando la operación ya fue procesada y cerró el lote del día. El adquirente debe iniciar una transacción de reversa hacia las marcas, quienes notifican al banco emisor para que reintegre el importe completo al tarjetahabiente. El estado resultante en SmartOperation es 602 — Devuelta. A diferencia de la anulación, la devolución total genera un movimiento financiero explícito: el comercio verá el débito del monto devuelto en su próxima liquidación. | **condiciones de la devolución total** | | ------------------------------------------------------------------------------------ | | Momento de ejecución → día posterior o días posteriores a la transacción | | Estado resultante en SmartOperation → 602 Devuelta | | Impacto financiero → el monto se descuenta en la liquidación del comercio | | Visibilidad para el tarjetahabiente → aparece como crédito en el resumen de cuenta | ## Devolución parcial La devolución parcial permite reintegrar solo una parte del importe original al tarjetahabiente. Solo es posible desde el día siguiente a la transacción. Si se intenta en el mismo día, la plataforma devuelve un error. El estado resultante es particular: la operación no transita a un estado de devolución completa sino que permanece en estado 200 — Paga, con la información de la devolución parcial registrada. Sin embargo, el cupón queda en estado 605 — Parcialmente devuelta dentro del modelo de estados de SmartOperation. | **condiciones de la devolución parcial** | | ----------------------------------------------------------------------------- | | Momento de ejecución → solo posible desde el día siguiente a la transacción | | Estado resultante del cupón → 605 Parcialmente devuelta | | Estado del webhook → 200 (la operación sigue parcialmente aprobada) | | Impacto financiero → solo el monto parcial se descuenta en la liquidación | | Restricción → no todos los medios de pago soportan devolución parcial | # Estados de SmartOperation relevantes para devoluciones y anulaciones El modelo de estados de SmartOperation define el ciclo de vida completo de una transacción en SUGA. Para el proceso de devoluciones y anulaciones, los estados relevantes son los siguientes. Se incluye también el contexto de los estados previos que habilitan la acción. ## Estados de origen (habilitantes de la reversa) Una operación solo puede ser devuelta o anulada si se encuentra en alguno de los siguientes estados: | **Código** | **Estado** | **Categoría** | **Descripción** | | ---------- | -------------- | --------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | | **200** | **Paga** | Estado de pago | Transacción aprobada por el adquirente. Es el estado desde el que se habilita la devolución total, parcial o la anulación del mismo día | | **300** | **Acreditada** | Estado de liquidación | Fondos acreditados al comercio. La devolución genera un débito en la próxima liquidación | | **301** | **Liquidada** | Estado de liquidación | Transacción incluida en una liquidación cerrada. La devolución afecta la reconciliación del período | ## Estados de cancelación (resultado de anulación) | **Código** | **Estado** | **Categoría** | **Descripción** | | ---------- | -------------------------- | ------------- | ------------------------------------------------------------------------------------------- | | **600** | **Cancelación en proceso** | Cancelada | La anulación fue iniciada y está siendo procesada por el adquirente y las marcas | | **601** | **Cancelada** | Cancelada | Anulación del mismo día completada exitosamente. La transacción queda sin efecto financiero | | **606** | **Cancelado** | Cancelada | Estado alternativo de cancelación según el tipo de operación o canal | ## Estados de devolución (resultado de devolución total o parcial) | **Código** | **Estado** | **Categoría** | **Descripción** | | ---------- | ------------------------- | ------------- | ------------------------------------------------------------------------------------------------------------ | | **602** | **Devuelta** | Devolución | Devolución total completada. El importe completo fue reintegrado al tarjetahabiente. Estado terminal | | **605** | **Parcialmente devuelta** | Devolución | Devolución parcial completada. La operación sigue vigente por el monto restante. El webhook devuelve cod 200 | ## Estados no recuperables relacionados | **Código** | **Estado** | **Categoría** | **Descripción** | | ---------- | ------------------------------------- | -------------- | ---------------------------------------------------------------------------------------------- | | **401** | **Expirada** | No recuperable | El checkout o la operación venció antes de ser pagada. No aplica devolución (nunca hubo cargo) | | **402** | **Abandonada** | No recuperable | El usuario no completó el pago. No aplica devolución | | **604** | **Transacción denegada** | No recuperable | La transacción fue rechazada definitivamente. No hubo cargo, no aplica devolución | | **610** | **Cancelada por operatoria inválida** | No recuperable | Cancelación por regla operativa de la plataforma. No aplica devolución | # Flujo de estados por tipo de operación ::Image[]{src="https://api.archbee.com/api/optimize/wYlzYU9oe8HZjh9BkqeFY/zyUgCWcx79siMVdQLBU-3_image.png" size="64" width="1440" height="1102" position="center" showCaption="false"} El primer diagrama muestra cómo cada tipo de reversa se relaciona con los cuatro circuitos adquirentes. Ahora el segundo: las transiciones de estados de SmartOperation para cada tipo de operación durante el ciclo de vida de la misma. ::Image[]{src="https://api.archbee.com/api/optimize/wYlzYU9oe8HZjh9BkqeFY/pg66Fv_bMkzzA4OU9CUhu_image.png" size="68" width="1440" height="1186" position="center" showCaption="false"} ## Anulación del mismo día | **flujo de estados — anulación (mismo día)** | | ---------------------------------------------------------------------------------------------- | | 2 En espera → transacción creada esperando pago | | 200 Paga → autorización aprobada por adquirente y marcas | | 600 Cancelación en proceso → solicitud de anulación iniciada por el comercio u operador | | 601 Cancelada → anulación completada → estado terminal → no hay impacto en liquidación | ## Devolución total (día posterior) | **flujo de estados — devolución total (día posterior)** | | ------------------------------------------------------------------------------------- | | 200 Paga → transacción aprobada y vigente | | 300 Acreditada → fondos acreditados al comercio en T o T+n | | 301 Liquidada → transacción incluida en liquidación cerrada | | 602 Devuelta → devolución total completada → estado terminal | | → el monto devuelto se descuenta en la próxima liquidación del comercio | ## Devolución parcial (día posterior) | **flujo de estados — devolución parcial (día posterior)** | | ---------------------------------------------------------------------------------------- | | 200 Paga → transacción aprobada y vigente | | 300 / 301 Acreditada / Liquidada → según el momento de la devolución | | 605 Parcialmente devuelta → devolución parcial completada | | → la operación permanece parcialmente vigente → webhook devuelve cod 200 | | → el monto parcial se descuenta en la próxima liquidación del comercio | # Consideraciones operativas ## Compatibilidad de medios de pago No todos los medios de pago soportan devolución o anulación. El comportamiento depende del procesador, la red de tarjetas y el tipo de instrumento utilizado (crédito, débito, prepaga, billetera, QR, efectivo). Antes de exponer la funcionalidad de devolución al comercio, el operador debe validar la compatibilidad de cada medio de pago habilitado. ## Timing crítico: mismo día vs. día posterior La diferencia entre anulación y devolución no la determina el operador: la determina la plataforma en función del momento de la solicitud respecto al cierre del lote del día. El mismo endpoint GET /refund puede resultar en una anulación (601) o una devolución (602) dependiendo exclusivamente del horario de ejecución. El operador debe tener esto en cuenta al diseñar sus flujos de soporte al comercio. ## Devolución parcial en el mismo día Si un operador o comercio intenta ejecutar una devolución parcial el mismo día de la transacción, la plataforma devuelve un error explícito. La devolución parcial solo es habilitada desde el día siguiente. Este comportamiento debe gestionarse en la capa de aplicación del comercio para evitar errores de UX ante el usuario final. ## Impacto en liquidaciones Las devoluciones —tanto totales como parciales— generan un impacto directo en el módulo de liquidaciones de SUGA. El monto devuelto se descuenta del siguiente ciclo de liquidación del comercio. En modelos con split (marketplace), la devolución impacta proporcionalmente en cada entidad receptora según la configuración de refundfee definida en el split original. ## POS y terminal en devoluciones de tarjeta presente Para transacciones originadas en canales de tarjeta presente (SmartPOS, POS), la devolución puede ejecutarse en el terminal original o en un terminal diferente mediante el parámetro terminal. Si el medio de pago requiere presencia del POS y no se envía terminal o se envía null, la plataforma devuelve el error pos\_action\_required, indicando que la acción debe completarse físicamente en el dispositivo.