Правило same-method и возврат на источник

1) Суть и зачем это нужно

• AML/ATF: не превращать возврат в «анонимный payout-туннель» на другой реквизит.
• Снижение фрода/ODR: меньше споров «деньги ушли не туда».
• Операционка: упрощенная сверка, меньше ручных кейсов.
• Карт-правила: соответствие сетевым требованиям «credit back to original funding instrument».

2) Карты (Visa/Mastercard/…): как это работает

Void/Authorization Reversal (до клиринга): откат авторизации — деньги «разморозятся» на той же карте.
Refund (Credit / Presentment): после клиринга — кредит на тот же PAN/DPAN.
Apple/Google Pay: возврат на DPAN/сетевой токен → эмитент маршрутизирует на текущую карту (в т.ч. при перевыпуске).
Push-to-Card OCT — не равен рефанду: это платеж на карту; использовать только при зафиксированном исключении и доп. KYC.

• Закрыта/перевыпущена карта — эмитент, как правило, «перенаправит» кредит на наследующую карту/счет. Возврат все равно шлем как refund.
• Возврат > исходного платежа — запрещено; делайте частичный refund, остаток — через разрешенный payout-рельс после KYC/SoF.
• Split-tender (оплата из 2 источников): возвраты в той же пропорции на каждый источник.

3) Банковские A2A (SEPA/ACH/FPS/RTP/PIX)

Идеал: кредитовый перевод на тот же IBAN/счет, откуда пришло пополнение (или на UPI/PIX-идентификатор отправителя).
ACH (US): «refund to source» обычно реализуется как кредит на тот же routing+account; возвраты (R-коды) — это не рефанд, а отказ/возврат рельса.
RTP/FPS/PIX: быстрые и финальные; если исходный платеж по этим рельсам — возврат часто идет как новое кредитование тому же получателю/алиасу (это нормальная реализация same-method).

• Счет закрыт / реквизит недействителен — допускается альтернативный рельс после подтверждения бенефициара (micro-deposit/test payout) и step-up KYC.
• Cross-border SWIFT: если исходный платеж был локальным, а возврат требует x-border — зафиксируйте дополнительный FX/fee disclosure и согласие.

4) e-wallets и APM (Skrill/Neteller/Payz/PayPal и локальные)

Правило: возврат в тот же кошелек/аккаунт, с которого пришел депозит.
Top-up из карты внутри кошелька: рефанд возвращается в кошелек, а не напрямую на карту пользователя (политика провайдера).
Ваучеры/eCash (Paysafecard, Neosurf, Multibanco-ref): чаще невозвратны на источник — делается кредит в кошелек/баланс мерчанта (или альтернативный payout при KYC).

• Заблокирован/потерян доступ — альтернативный рельс после EDD/SoF и подтверждения владения.
• Партнерские ограничители (AUP) — возврат возможен только в форме store-credit/внутреннего баланса.

5) Ваучеры/наличные/квази-кэш

1. Отмена до выдачи товара/кредита — ок, ничего не переводится.

2. После зачисления — возврат в внутренний баланс/кошелек с последующим выводом только на именной банковский счет после KYC/SoF (никаких «наличные назад»).

Прозрачно указать в ToS: ваучерные пополнения возвращаются не на ваучер.

6) Частичные возвраты, сверхлимит и мульти-источник

Partial refund: в исходный источник до суммы исходного платежа. Несколько частичных — допустимо.
Сумма к возврату > внесенного источником — остаток через разрешенный payout-рельс (KYC/SoF/лимиты).
Несколько источников (например, 70% карта + 30% кошелек): рефанды пропорционально назад на те же источники.

7) Временные окна и приоритеты

Приоритет 1: `void/authorization reversal` (если еще можно) — самый «чистый» откат.
Приоритет 2: `refund to source` по исходному рельсу.
Приоритет 3: альтернативный payout (только по зафиксированному исключению + step-up и аудит).

8) Движок решений (policy engine): как проектировать

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

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

2. Иначе если `isRefundableToSource(paymentId)` → Refund(sourceRef).

3. Если `sourceRef invalid/closed` → Step-Up (KYC/SoF) → предложить payout rails по allow-листу (банковский/Push-to-Card/e-wallet) → лог причины.

4. Если voucher/eCash → кредит внутр. баланс; прямой реверс невозможен.

5. Split-tender → рефанд на каждый `sourceRef` в своей доле.

6. Hard-deny при санкциях/PEP/возрастных/гео запретах.

Нефункциональные: идемпотентность (`refundKey`), дедуп веб-хуков, explain-логика (почему выбран метод), версионирование правил.

9) Статусы, сверка и артефакты

Статусы возврата: `requested → pending → refunded | failed | canceled`.
Артефакты: `refundId`, `originalPaymentId`, `sourceType/ref`, `amount/currency`, `fxRate`, `UTR/ARN/Trace`, `reasonCode`, `actor`.
Recon: daily auto-recon по реестрам PSP/банка + full-recon; алерты: «успех без реестра», «двойной refund», «возврат на иной источник».

10) UX и коммуникации

На экране возврата показывайте адресата: «Возврат на карту ••3456 / кошелек @user / счет DE…».
Если требуется исключение — объясняем: «Исходный источник недоступен. Для вашей безопасности предложим возврат на именной банковский счет после подтверждения данных (≈N минут/часов)».
Чеки/письма: сумма, дата, метод, `refundId`, UTR/ARN, ETA (карты — до X дней, A2A — T+0/1, кошельки — мгновенно/T+1).
FAQ: ваучеры нереверсивны; Apple/Google Pay возвращаются на привязанную карту автоматически.

11) Матрица исключений (сигналы и шаги)

12) FX и валюта

Возврат в исходной валюте транзакции; если нужна конверсия — используйте тот же источник FX (PSP/банк) и покажите курсы/комиссии.
Не ухудшайте для клиента экономику (не возвращайте в иной валюте без явного согласия).

13) Особенности для iGaming

Возврат бонусов/фриспинов: правила игры > политика возврата; деньги только в части внесенных средств.
Self-exclusion / RG: при блокировке счета — возврат остатка на источник; альтернативные выплаты запрещены до завершения проверок.
Квази-кэш: строгий запрет «перелива» с карты/ваучера на новый реквизит под видом рефанда.

14) KPI и контроль

Refund success rate (онлайн → зачисление по реестру).
Median/P95 time-to-refund по методам.
Alternate-payout rate (доля исключений) — держать < X%.
ODR после возврата (повторные споры).
Ошибки сверки: «двойной refund», «не тот источник».
Support load по возвратам/1k заказов.

15) Чек-лист внедрения

1. Каталог источников (card/A2A/wallet/voucher) и их статусы пригодности для RTS.
2. Policy engine: правила void→refund→alt-payout, explain-логи, версионирование.
3. Интеграция PSP/банков: `void/refund`, веб-хуки (подпись/HMAC), идемпотентность.
4. Recon: daily + full, алерты на рассинхроны и «refund на иной источник».
5. UX: явный показ адресата возврата, ETA, причины исключений; шаблоны писем/чеков.
6. AML/KYC: step-up для альтернативных выплат, SoF/SoW, deny-кейсы.
7. Тест-набор: void window, частичный refund, split-tender, закрытая карта/IBAN, ваучер, Apple/Google Pay, деградация PSP.

Резюме

Правило same-method / refund-to-source — ключ к безопасности, комплаенсу и предсказуемости. Делайте void → refund → (строго при необходимости) альтернативный payout, держите правила в policy-движке с explain-логами, обеспечьте идемпотентность, webhooks и recon, прозрачно коммуницируйте адресата и ETA. Исключения — только с step-up KYC/SoF и четким аудиторским следом. Так вы снижаете риски, расходы поддержки и объем споров, сохраняя доверие пользователей.