Правило 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 при санкціях/РЕР/вікових/гео заборонах.

Нефункціональні: ідемпотентність ('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, гаманці - миттєво/Т + 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', веб-хуки (підпис/НМАС), ідемпотентність.
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 і чітким аудиторським слідом. Так ви знижуєте ризики, витрати підтримки і обсяг суперечок, зберігаючи довіру користувачів.