Regra de same-method e retorno à origem

1) Essencial e porquê

• AML/ATF: não converter o retorno em um «túnel payout anônimo» em outro adereço.
• Redução de frod/ODR: Menos controvérsias «dinheiro foi para o lado errado».
• Operacionalização simplificada, menos malas manuais.
• Regras de cartão: conformidade com os requisitos de rede de «credit back to original funding institute».

2) Cartões (Visa/Mastercard/...): como funciona

Void/Autorization Reversal (antes da compensação): revogação da autorização - o dinheiro será «descongelado» no mesmo cartão.
Refund (Credit/Presentment): após a compensação, crédito para o mesmo PAN/DPAN.
Apple/Google Pay: retorno para DPAN/Token de Rede → o emissor é roteirizado para o mapa atual (incluindo a transferência).
Push-to-Card OCT - não igual a um refand: é um pagamento no cartão; Usar apenas se a exclusão for registada e mais KYC.

• Cartão fechado/transferido - o emissor geralmente «redireciona» o crédito para o cartão herdeiro/conta. O retorno é igual ao capacete como refund.
• Reembolso> pagamento de origem - proibido; façam um refund parcial, o restante seja através do relevo payout permitido após a KYC/SoF.
• Split-tender (pagamento de 2 fontes): reembolsos na mesma proporção para cada fonte.

3) A2A bancário (SEPA/ACH/FPS/RTP/PIX)

Ideal: transferência de crédito para a mesma conta IBAN/de onde veio a reposição (ou para UPI/PIX do remetente).
ACH (US): «refund to nature» normalmente é implementado como crédito para o mesmo roting + account; os retornos (códigos R) não são um refand, mas sim uma falha/retorno de um roteiro.
RTP/FPS/PIX: rápidos e finais; se o pagamento inicial para esses trilhos - o reembolso é frequentemente como um novo empréstimo para o mesmo destinatário/alíase (é a implementação normal do same-method).

• A conta fechada/adereço não é válida - é permitido um caminho alternativo após a confirmação do beneficiário (micro-deposit/teste payout) e step-up KYC.
• Cross-border SWIFT: Se o pagamento original for local e o reembolso for x-border - verifique o FX/fee disclosure adicional e o consentimento.

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

Regra: reembolso para a mesma carteira/conta de depósito.
Top up do cartão dentro da carteira: o refand é devolvido para a carteira, não diretamente para o cartão do usuário (política do provedor).
Vales/eCash (Paysafecard, Neosurf, Multibanco-ref): Mais frequentemente não reembolsável para a origem - é feito o crédito em carteira/balanço merchant (ou payout alternativo para KYC).

• Bloqueado/perdido - um caminho alternativo após a EDD/SoF e confirmação da propriedade.
• Limitadores de parcerias (AUP) - O retorno só é possível na forma store-credit/balanço interno.

5) Vales/dinheiro/cash

1. Cancelamento antes da entrega do produto/empréstimo - ok, nada é traduzido.

2. Uma vez depositado, será devolvido para o saldo/carteira interna, com saída posterior apenas para a conta bancária de nome após a KYC/SoF (nenhum «dinheiro de volta»).

Especifique com transparência no ToS: os vales não são voltados para o voucher.

6) Retornos parciais, superlimo e fonte multi

Partial refund: na origem original até o valor do pagamento original. Algumas parciais, é aceitável.
O valor a ser devolvido> a fonte fornecida é o restante através do roteiro payout autorizado (KYC/SoF/Limite).
Várias fontes (por exemplo, cartão de 70% + carteira de 30%): refanda proporcionalmente para as mesmas fontes.

7) Janelas de tempo e prioridades

Prioridade 1: 'void/autorization reversal' (se você ainda puder) é o retrocesso mais «puro».
Prioridade 2: 'refund to fonte' no roteiro original.
Prioridade 3: payout alternativo (somente com exclusão fixada + step-up e auditoria).

8) Motor de soluções (policy engine): como projetar

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

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

2. Caso contrário, ' ' Refund ( ).

3. Se 'n' invalid/closed' Step-Up ( ), você pode oferecer payout rails por uma folha (bancária/Push-to-Card/e-wallet) o logotipo da razão.

4. Se voucher/eCash → crédito interno. equilíbrio; Não é possível reverter diretamente.

5. Split-tender refand para cada « » na sua parte.

6. Hard-deny para sanções/RER/proibições etárias/geo.

Idempotidade ('refundKey'), duto de ganchos da Web, lógica exploratória (por que o método é escolhido), versionização de regras.

9) Estatais, confecções e artefactos

Estados de retorno: 'requested → pending → refunded | failed | canceled'.
Артефакты: `refundId`, `originalPaymentId`, `sourceType/ref`, `amount/currency`, `fxRate`, `UTR/ARN/Trace`, `reasonCode`, `actor`.
Recon: daily auto-recon por PSP/banco + full-recon; alertas: «sucesso sem registro», «duplo refund», «retorno para outra fonte».

10) UX e comunicações

Na tela de retorno, mostre o destinatário: «Retorno ao mapa • • 3456/carteira @ user/conta DE»....
Se necessário, explicamos que "Origem não disponível. Para sua segurança, ofereçamos um retorno à conta bancária com nome após a confirmação dos dados (≈N minutos/horas) ".
Cheques/cartas: soma, data, método, 'refundId', UTR/ARN, ETA (cartões até X dias, A2A - T + 0/1, carteiras instantâneas/T + 1).
FAQ: Os vales não são versíveis; Apple/Google Pay retornam automaticamente ao mapa vinculado.

11) Matriz de exceções (sinais e passos)

12) FX e moeda

Reembolso na moeda de origem da transação; se precisar de conversão - use a mesma fonte FX (PSP/banco) e mostre cursos/comissão.
Não piore a economia do cliente (não devolva em outra moeda sem consentimento explícito).

13) Características para iGaming

Restituição de bónus/frispins: regras do jogo> política de retorno; O dinheiro é apenas parte dos fundos depositados.
Self-exclusion/RG: ao bloquear a conta, a restituição do saldo para a origem; pagamentos alternativos são proibidos até que as verificações sejam concluídas.
Kwazy-cash, proibição rigorosa de transfusão do cartão/voucher para novos adereços disfarçados de refand.

14) KPI e controle

Refund sucess rate (inscrição online → registro).
Median/P95 time-to-refund sobre métodos.
Alternate-payout rate (taxa de exclusão) - manter <X%.
ODR após a devolução (disputas repetidas).
Os erros de confecção são «duplo refund», «origem errada».
Suporte load por devoluções de encomendas/1k.

15) Folha de cheque de implementação

1. Catálogo de fontes (card/A2A/wallet/vocher) e seus estados de validade RTS.
2. Policy engine: regras void→refund→alt -payout, logi explain, versionização.
3. Integração PSP/bancos: 'void/refund', Web Hook (assinatura/NMAS), Idempotidade.
4. Recon: daily + full, alertas para rashinhons e «refund para outra fonte».
5. UX: exibição explícita do destinatário de retorno, ETA, razões das exceções; modelos de cartas/cheques.
6. AML/KYC: step-up para pagamentos alternativos, SoF/SoW, mala deny.
7. Kit de teste: void window, refund parcial, split-tender, cartão fechado/IBAN, voucher, Apple/Google Pay, degradação PSP.

Currículos

A regra same-method/refund-to-nature é a chave para a segurança, a complicação e a previsibilidade. Faça um void → refund → (rigorosamente, se necessário) payout alternativo, mantenha as regras no policy-motion com logs exploradores, garanta idempotidade, webhooks e recon, comunique o destinatário e ETA de forma transparente. Exceções são apenas com step-up KYC/SoF e um rasto de auditoria claro. Assim, você reduz os riscos, os custos de suporte e a quantidade de controvérsia mantendo a confiança dos usuários.