Devoluciones y Anulaciones

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 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 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