Saltar al contenido principal
En esta página

Reembolsos Parciales Múltiples (MPR) permite a un comerciante enviar varias solicitudes de reembolso parcial mientras DEUNA envía un reembolso acumulado al procesador. Es el modo de compatibilidad gestionado por DEUNA para conexiones que no pueden recibir múltiples operaciones de reembolso o para las que el procesamiento de reembolsos requiere agregación.

MPR se configura por conexión con procesador. Es diferente del soporte nativo de múltiples reembolsos: con soporte nativo, cada reembolso elegible puede enviarse al procesador de forma independiente; con MPR, las solicitudes no finales permanecen almacenadas en DEUNA hasta que se completa la secuencia.

Ciclo de vida de MPR#

  1. Comience con un pago con un importe reembolsable confirmado, por ejemplo processed, capturedo partial_captured.
  2. Envíe una solicitud de reembolso parcial.
  3. DEUNA valida la solicitud en función del saldo reembolsable acumulado y la almacena sin llamar al procesador.
  4. Mientras se almacenan uno o más importes de reembolso, el pago es partial_refunding.
  5. DEUNA cierra la secuencia cuando se cumplen las siguientes condiciones:
    • El importe solicitado acumulado alcanza el importe reembolsable total.
    • Una solicitud incluye "final_refund": true.
    • Se alcanza el límite de reembolso guardado.
  6. DEUNA envía el importe acumulado almacenado al procesador como una única operación de reembolso.
  7. Si el importe confirmado devuelve el saldo total reembolsable, el pago se convierte en refunded. Si devuelve solo parte de ese saldo, se convierte en partial_refunded.

Una solicitud en cola registra la intención de reembolso; no prueba que los fondos se han devuelto al cliente.

Límites de tiempo y de corte para reembolsos#

El corte de MPR tiene las siguientes reglas:

  • Configurar un número entero de 1 a 45 días calendario.
  • El reloj comienza cuando la primera solicitud de reembolso no final se ha encolado.
  • DEUNA guarda la fecha límite absoluta en refund_cutoff_at . Los reembolsos parciales posteriores no la extienden ni la restablecen.
  • El plazo es el final del día calendario de destino, no el mismo momento del reloj después de un número fijo de días.
  • Modificar la configuración de conexión no reescribe una fecha límite ya guardada en un pago existente.
  • Cuando se alcanza el corte guardado, el pago se vuelve elegible para que el trabajador de corte envíe la cantidad acumulada de reembolso. El procesamiento no está garantizado en el segundo final exacto del día, por lo que no confíe en un período de gracia para otro reembolso de un comerciante.

Por ejemplo, con un corte de un día, una primera solicitud no final encolada el lunes es elegible para el procesamiento del corte después del final del martes. No está programado para el mismo momento del martes.

Cerrar la secuencia a través de la API#

Use final_refund para enviar la solicitud actual y todas las cantidades acumuladas sin esperar al corte. Envíe como un booleano JSON:

JSON
{
  "amount": 100,
  "reason": "Item returned",
  "final_refund": true
}

Al alcanzar el importe reembolsable total, la secuencia también se cierra automáticamente; final_refund no es necesario en ese caso.

Monto y reglas de secuencia#

  • La cantidad acumulada solicitada de reembolso no puede exceder el importe reembolsable confirmado.
  • DEUNA incluye los reembolsos previamente encolados al validar cada nueva solicitud.
  • Una operación de reembolso final cierra la secuencia MPR. Las solicitudes posteriores de reembolso para esa secuencia se rechazan.
  • DEUNA no impone un límite en el número de solicitudes encoladas de MPR. El saldo reembolsable y el corte son los límites efectivos de la plataforma.
  • No calcule el saldo restante únicamente a partir de la última respuesta. Utilice la última transacción, su historial de operaciones y los importes confirmados, especialmente cuando las solicitudes pueden superponerse.
  • Si la actividad de captura aún está pendiente, la elegibilidad para el reembolso es específica de la conexión. No reembolse una cantidad no confirmada a menos que DEUNA haya aprobado un comportamiento concurrente de captura y reembolso para la conexión.

Estado y manejo de errores#

EstadoSignificado en un flujo MPRAcción del comerciante
processed, capturedo partial_capturedUn importe confirmado puede ser elegible para el reembolso.Calcule el reembolso contra el saldo reembolsable confirmado.
partial_refundingUna o más cantidades de reembolso están en cola o en proceso.Mantenga el reembolso sin resolver y espere la confirmación.
refundingEl saldo reembolsable total o restante se está procesando.Espere el resultado definitivo.
partial_refundedSe ha confirmado una cantidad parcial por parte del procesador.Registre la cantidad devuelta confirmada y reconcilie el saldo restante.
refundedSe ha devuelto el saldo reembolsable total.Registre la finalización definitiva del reembolso.

Si el procesamiento del corte o la llamada al procesador fallan, no marque el pago como reembolsado localmente. DEUNA puede reintentar el trabajo de corte elegible, mientras que los fallos sin resolver repetidos requieren una revisión operativa. Obtenga la información de pago y consuma los webhooks hasta que la operación alcance un estado confirmado. Un tiempo de espera por sí solo no es un resultado final de reembolso.

Para la tabla de transición completa, consulte Flujo de trabajo y estados de pago. Para solicitudes superpuestas, consulte Captura y reembolso simultáneo.

Configurar MPR#

Trabaje con su representante técnico de DEUNA para configurar la conexión:

ConfiguraciónRequisito
Estado de la funcionalidadMPR habilitado para la conexión del procesador seleccionada
Corte de reembolsoRequerido: 1–45 días calendario
Capacidad del procesadorSoporte de reembolso para la cantidad acumulada final

En la administración, utilice el detalle del pedido e historial de la operación de reembolso para supervisar las solicitudes en cola, la cantidad acumulada de reembolso, el importe reembolsable restante y el corte programado, si está disponible.

MPC y MPR se pueden habilitar en la misma conexión. Sus cortes de captura y reembolso son independientes; actualizar uno no afecta al otro.