Crear un reembolso

Reembolsa un intent. Usa intent_id con el ID unificado in_… para cualquier tipo compatible. payment_intent_id sigue aceptándose como alias legado para integraciones existentes.

Para pagos electrónicos, devuelve los fondos al método de pago original del cliente. Para un pago con Balance Recurrente (balance), el monto completo regresa al instante al balance del pagador. Para una venta en efectivo (cash), registra la devolución que realiza el comercio por fuera de Recurrente, sin mover dinero. El intent solo se cancela cuando los reembolsos acumulados cubren el total. Envía amount_in_cents para solicitar un reembolso parcial en CyberSource, Visa CyberSource o efectivo (cash). Si omites el monto, se reembolsa todo el saldo pendiente. Puedes enviar varios reembolsos parciales hasta cubrir el total. Otros proveedores solo admiten el saldo pendiente completo.

Si la venta tiene una factura certificada por Recurrente, cada parcial genera una nota de crédito por el monto correspondiente y conserva la factura original. Un reembolso del total original intenta anularla primero; usa nota de crédito si el período cerró o la factura ya tiene una nota. Esto aplica también a cash_sales. Un refund exitoso no garantiza que la corrección fiscal haya terminado: puede fallar o requerir reintentos. Las facturas emitidas fuera de Recurrente las corrige el comercio.

Para reembolsar un cobro de una cuenta conectada, envía su ID en el header X-ACCOUNT-ID; la API key debe permitir movimientos de dinero. Envía refund_application_fee: true para regresar a la cuenta dueña del cobro todas sus comisiones de plataforma antes de solicitar el reembolso al procesador. El valor predeterminado es false y las distribuciones con purpose: fund_split nunca se revierten por este parámetro.

Recurrente reserva los movimientos y el balance del comercio sin mantener bloqueos durante la llamada externa. Si el procesador rechaza el reembolso, crea movimientos compensatorios. Una factura fiscal de comisión se puede anular cuando todas sus líneas pertenecen a este reembolso; un documento que agrupa otros pagos hace fallar la solicitud antes de contactar al procesador. Si otra solicitud ya está procesando el mismo reembolso, responde 202 y no vuelve a llamar al proveedor. Si el resultado del proveedor queda indeterminado, el reembolso permanece pending con failure_reason: provider_outcome_unknown; Recurrente conserva la reserva, no reintenta automáticamente y un POST posterior responde 422 con el refund_id para consultar y reconciliar el caso.

Usa un Idempotency-Key único por reembolso. Cuando una solicitud parcial responde 202, las repeticiones con la misma llave y cuerpo reproducen esa respuesta con el mismo refund_id; consulta ese ID antes de enviar otro monto.