Regla same-method y devolución a la fuente

1) La esencia y por qué es necesario

• AML/ATF: no convertir la devolución en un «túnel de pago anónimo» en otros detalles.
• Disminución del Frod/ODR: menos controversia «el dinero se fue al lugar equivocado».
• Operación: conciliación simplificada, menos casos manuales.
• Reglas de tarjetas: cumplimiento de los requisitos de red «credit back to original funding instrument».

2) Mapas (Visa/Mastercard/...): cómo funciona

Void/Authorization Reversal (antes de la compensación): reversión de la autorización - el dinero se «descongelará» en la misma tarjeta.
Refund (Credit/Presentment): después de la compensación, un préstamo para el mismo PAN/DPAN.
Apple/Google Pay: devuelve el DPAN/token de red → el emisor enruta a la tarjeta actual (incluyendo cuando se reinicia).
Push-to-Card OCT - no es igual a Refand: es un pago a la tarjeta; utilizar sólo en caso de exclusión registrada y dop. KYC.

• Tarjeta cerrada/reenviada - el emisor generalmente «redireccionará» el crédito a la tarjeta/cuenta hereditaria. La devolución sigue siendo un casco como refund.
• Devolución> del pago original - Prohibido; haga un refund parcial, el remanente es a través del riel de pago permitido después de KYC/SoF.
• Split-tender (pago de 2 fuentes): devoluciones en la misma proporción por fuente.

3) Banco A2A (SEPA/ACH/FPS/RTP/PIX)

Ideal: transferencia de crédito a la misma IBAN/cuenta de donde procedía la recarga (o al identificador UPI/PIX del remitente).
ACH (US): «refund to source» generalmente se implementa como un préstamo para el mismo routing + account; devoluciones (códigos R) no es un refando, sino un fallo/retorno de carril.
RTP/FPS/PIX: rápido y final; si el pago original en estos raíles - la devolución a menudo va como un nuevo préstamo al mismo receptor/aliás (esta es la implementación normal de same-method).

• La cuenta está cerrada/los datos no son válidos - se permite un carril alternativo después de la confirmación del beneficiario (micro-depósito/prueba de pago) y el KYC de paso a paso.
• SWIFT Cross-border: si el pago original fue local y la devolución requiere x-border, registre el FX/fee disclosure adicional y el consentimiento.

4) e-wallets y APM (Skrill/Neteller/Payz/PayPal y local)

Regla: devolución a la misma billetera/cuenta desde la que vino el depósito.
Top-up desde la tarjeta dentro de la cartera: el refand vuelve a la cartera, no directamente a la tarjeta del usuario (política del proveedor).
Vales/eCash (Paysafecard, Neosurf, Multibanco-ref): es más probable que no sean reembolsables en la fuente - se hace un crédito en la cartera/balance de merchant (o payout alternativo en KYC).

• Acceso bloqueado/perdido - carril alternativo después de EDD/SoF y confirmación de propiedad.
• Limitadores de afiliados (AUP): los reembolsos sólo son posibles en el formulario store-credit/balance interno.

5) Cupones/efectivo/cuasi caché

1. Cancelación antes de la emisión del artículo/crédito - aprox., no se transfiere nada.

2. Una vez acreditada, devuelve al saldo interno/billetera, seguido de un retiro solo en la cuenta bancaria después de KYC/SoF (sin «efectivo atrás»).

Especificar de forma transparente en ToS: los vales de recarga no se devuelven al cupón.

6) Retornos parciales, ultralimitación y multi-fuente

Referencia parcial: al origen original hasta el importe del pago original. Algunos parciales son admisibles.
Importe a devolver> depositado por la fuente - saldo a través del carril de pago permitido (KYC/SoF/límites).
Varias fuentes (por ejemplo, 70% tarjeta + 30% billeteras): refundiciones proporcionalmente hacia atrás en las mismas fuentes.

7) Ventanas temporales y prioridades

Prioridad 1: 'void/authorization reversal' (si aún se puede) es la reversión más 'limpia'.
Prioridad 2: 'refund to source' en el riel original.
Prioridad 3: payout alternativo (sólo por excepción confirmada + paso a paso y auditoría).

8) Motor de soluciones (motor de políticas): cómo diseñar

Входные данные: `paymentId`, `sourceType` (card/A2A/wallet/voucher), `sourceRef` (PAN token, IBAN, walletId), `amount`, `fx`, `status`, `settlementState`, `kycLevel`, `riskScore`, `beneficiaryId`.

1. Если `canVoid(paymentId)` → Void.

2. De lo contrario, si 'isRefundableToSource (paymentId)' → Refund (sourceRef).

3. Si 'sourceRef invalid/closed' → Step-Up (KYC/SoF) → sugerir payout rails a través de una lista allow (bancaria/Push-to-Card/e-wallet) → el registro de la razón.

4. Si voucher/eCash → crédito dentro. equilibrio; el reverso directo no es posible.

5. Split-tender → un refand para cada 'sourceRef' en su cuota.

6. Hard-deny en sanciones/RR/prohibiciones de edad/geo.

No funcional: idempotencia ('refundKey'), dedoop web hooks, explain-lógica (por qué se selecciona el método), versioning de reglas.

9) Estados, conciliación y artefactos

Estados de devolución: 'requested → pending → refunded | failed | canceled'.
Артефакты: `refundId`, `originalPaymentId`, `sourceType/ref`, `amount/currency`, `fxRate`, `UTR/ARN/Trace`, `reasonCode`, `actor`.
Recon: daily auto-recon por registro PSP/banco + full-recon; alertas: «éxito sin registro», «doble refund», «retorno a otra fuente».

10) UX y comunicaciones

En la pantalla de devolución, muestra al destinatario: «Devolución a la tarjeta • • 3456/billetera @ usuario/cuenta DE»....
Si desea una excepción, explique: "La fuente original no está disponible. Por su seguridad, le ofreceremos una devolución a su cuenta bancaria después de confirmar los datos (≈N minutos/horas) ".
Cheques/cartas: cantidad, fecha, método, 'refundId', UTR/ARN, ETA (tarjetas - hasta X días, A2A - T + 0/1, monederos - instantáneo/T + 1).
Preguntas frecuentes: los vales no son reversibles; Apple/Google Pay regresan automáticamente a la tarjeta enlazada.

11) Matriz de excepciones (señales y pasos)

12) FX y moneda

Devoluciones en la moneda de origen de la transacción; Si necesita una conversión, utilice la misma fuente de FX (PSP/banco) y muestre los cursos/comisiones.
No empeore la economía del cliente (no devuelva en otra moneda sin consentimiento expreso).

13) Características para iGaming

Devoluciones de bonificaciones/giros gratis: reglas del juego> política de devoluciones; el dinero sólo en una parte de los fondos depositados.
Self-exclusion/RG: al bloquear una cuenta, devuelve el saldo a la fuente; se prohíben los pagos alternativos hasta que se completen las inspecciones.
Quasi caché: prohibición estricta de «desbordamiento» de la tarjeta/cupón a los nuevos accesorios bajo la apariencia de refundición.

14) KPI y control

Refund success rate (en línea → inscripción en el registro).
Median/P95 time-to-refund por métodos.
Alternate-payout rate (porcentaje de excepciones): mantenga <X%.
ODR después de la devolución (disputas repetidas).
Errores de conciliación: «doble refund», «fuente equivocada».
Support load por devoluciones/1k pedidos.

15) Lista de verificación de implementación

1. Directorio de fuentes (card/A2A/wallet/voucher) y sus estados de idoneidad para RTS.
2. Motor de políticas: reglas de void→refund→alt -payout, registro explain, versioning.
3. Integración PSP/bancos: 'void/refund', hooks web (firma/NMAS), idempotencia.
4. Recon: daily + full, alertas a los rassincrones y «refund a otra fuente».
5. UX: exhibición explícita del destinatario de la devolución, ETA, razones de las excepciones; plantillas de correo electrónico/cheques.
6. AML/KYC: paso a paso para pagos alternativos, SoF/SoW, casos de deny.
7. Kit de prueba: void window, refund parcial, split-tender, tarjeta cerrada/IBAN, cupón, Apple/Google Pay, degradación PSP.

Resumen

La regla same-method/refund-to-source es clave para la seguridad, el cumplimiento y la previsibilidad. Haga un void → refund → (estrictamente si es necesario) un payout alternativo, mantenga las reglas en un motor de políticas con logs explain, proporcione idempotencia, webhooks y recon, comunique transparentemente al destinatario y a ETA. Excepciones: sólo con un paso a paso KYC/SoF y una pista de auditoría clara. Así que reduce los riesgos, los costos de soporte y el volumen de disputas, manteniendo la confianza de los usuarios.