Крипто-казино
Torrent Gear
Как работает обратный депозит (reversal payout)
Reversal payout («обратный депозит», «reverse/return to source», «closed-loop reversal») — это возврат средств тем же методом и на тот же инструмент, с которого пришёл депозит. Идея проста: если игрок пополнял баланс картой/банком/кошельком, возврат делается назад по исходной транзакции, а не «на новые реквизиты». Такой подход минимизирует AML-риски, упрощает свёрку и снижает нагрузку на саппорт.
Термины и отличия (важно не путать)
Reversal payout (обратный депозит): инициируется оператором, деньги возвращаются по исходному платёжному следу (ссылка на исходный платёж/референс).
Refund (возврат): логическая «отмена» покупки/депозита целиком или частично. На картах — кредитовая запись к исходному дебету. На A2A/локальных схемах — специализированная операция «devolução/return».
Payout (обычная выплата): исходящий перевод на новые реквизиты (карта по OCT, банковский счёт, кошелёк и т. д.).
Chargeback (чарджбэк): спор клиента у эмитента/банка; инициируется не мерчантом, а держателем и идёт по регламенту платёжной сети/банка.
Зачем это нужно операторам (плюсы)
1. AML и responsible gambling: соблюдение «closed-loop» → ниже риск обналичивания и претензий регулятора.
2. Простая свёрка: возврат привязан к исходному `payment_id`/референсу, меньше «потерянных» транзакций.
3. Меньше споров: игрок «видит» деньги там же, откуда платил; меньше тикетов «куда пришёл возврат».
4. Гибкость частичных возвратов: можно вернуть часть депозита, сохранив остаток в балансе/на выигрыше.
5. Комиссии и SLA: часто дешевле и быстрее, чем отдельный payout на новые реквизиты.
Как работает по основным рельсам
1) Карты (Visa/Mastercard/др.)
Механика: мерчант инициирует refund/credit reversal к исходному дебету (AFT/покупка).
Скорость: авторизационный ответ мгновенно; фактическое зачисление — обычно 1–5 банковских дней (зависит от эмитента).
Лимиты: нельзя превысить исходную сумму (суммарно по частям). Возможны окна по времени (refund-window).
Особенности: это не OCT/push-to-card; чарджбэк-правила здесь вторичны, т. к. это возврат, а не спор.
2) A2A / банковские мгновенные платежи
SEPA Instant/FPS: операции return/recall по исходному SCT/SCT Inst/FPS-платежу, зависят от схемы и банков.
PIX (Бразилия): Pix Devolução — целевой возврат на источник по исходному `e2eId`.
PayID/NPP (Австралия): возврат/корректировка на исходный платёж с привязкой к PayID/Osko-референсу.
Скорость: от секунд до часов/суток (по схеме/банку).
Ограничения: окна по времени, требования к описанию/референсам.
3) Кошельки и альтернативы
Механика: API-refund на исходный кошелёк/аккаунт провайдера (Skrill/Neteller и т. п.).
Плюсы: мгновенно «внутри экосистемы», чёткая привязка.
Минусы: экосистемные лимиты/комиссии, KYC на стороне кошелька.
4) Криптовалюты
Строго не «reversal» в сетевом смысле. Реально — возврат на исходный адрес/кошелёк, зафиксированный в журнале.
Риски: адрес может быть биржевым/одноразовым; волатильность и комиссии сети; важно сохранять ончейн-ссылки.
Защита: адресный риск-скоринг, подтверждение адреса игроком, дедупликация транзакций.
Когда выбирать reversal payout вместо обычной выплаты
Возврат депозита (ошибка, отмена, self-exclusion, технический инцидент).
Ответственная игра: вернуть невостребованный депозит/остаток туда же.
AML-политика: запрещены выводы на новые реквизиты до определённых проверок (SoF/SoW).
Снижение затрат и тикетов: минимизация вопросов «куда пришли деньги».
Жизненный цикл reversal payout
1. Идентификация исходного платежа
Найти в леджере `original_payment_id`, метод, сумму, доступный остаток для возврата.
2. Проверки риска/комплаенса
Санкции/PEP-рескрининг по аккаунту, RG-флаги, лимиты возвратов, «источник средств».
3. Блокировка и расчёт суммы
Проверить, сколько можно вернуть (частично/полностью), удержания/бонусные условия.
4. Отправка запроса
В провайдера по специализированному API возврата (refund/devolução/return). Приложить референс исходной транзакции.
5. Статусы и вебхуки
`accepted → processed/settled → failed`. Возможны асинхронные обновления.
6. Обновление леджера
Двойная запись: уменьшение доступного баланса, фиксация возврата, линк на `original_payment_id`, идемпотентность.
7. Уведомления
Показ «Возврат оформлен», ожидаемое окно зачисления, номер операции/референс.
Леджер и свёрка: на что обратить внимание
Идемпотентность: ключ `refund_id` на запрос, защита от повторов/таймаутов.
Привязка к источнику: поле `original_payment_id` + внешний `provider_ref`.
Частичные возвраты: храните агрегированную сумму `refunded_amount` и остаток к возврату.
Трёхсторонняя сверка: леджер ↔ вебхуки провайдера ↔ банковские/сетевые отчёты.
Аномалии: «зависшие» возвраты, дубликаты, расхождения по комиссиям/валютам.
Риски и ограничения
Окно по времени/сумме: не всегда можно вернуть через долгое время или сверх исходной суммы.
Разные рельсы у депозита: часть пришла картой, часть — A2A; возвраты нужно разбивать пропорционально источникам.
Фрод и мулы: массовые маленькие депозиты → быстрый возврат на те же источники. Нужны velocity-лимиты и антибот-слой.
Курс и комиссии (FX/crypto): корректно информируйте о сумме кредита на стороне получателя.
Регуляторика: отдельные юрисдикции требуют мотивировку/журналы причин возврата (RG/AML/операционные).
UX и коммуникация
Пишите куда вернём: «на вашу карту 1234 / PayID / кошелёк».
Показывайте сроки: «обычно до N дней/часов» с пояснением, что зависит от банка/сети.
Давайте референс операции и короткое описание причины («отмена депозита», «лимит RG», «техн. ошибка»).
Поддержите частичные возвраты и историю по каждой исходной оплате.
Архитектурные паттерны
Refund-API поверх оркестратора: единый интерфейс для всех провайдеров/рельс.
Saga/Outbox: согласованность между леджером и внешними отправками.
Retry с backoff: только для временных ошибок, с идемпотентностью.
Kill-switch по провайдерам: быстрое переключение канала возвратов при деградации.
Правила разбиения: если один депозит покрывал несколько чеков — пропорциональное распределение возврата.
Чек-лист внедрения
1. Описать политику closed-loop и случаи, когда допускаются иные методы.
2. Свести рельсы возвратов по каждому методу (карта/A2A/кошелёк/крипто) и их окна/лимиты.
3. Реализовать идемпотентный Refund-API, хранить `original_payment_id` и агрегаты по частичным возвратам.
4. Настроить AML/RG-гейт перед отправкой возврата (санкции, velocity, причины).
5. Подключить вебхуки и поллинг, мониторинги «зависших» статусов.
6. Построить дашборды: p95 времени кредита, доля ошибок/ретраев, % возвратов с первого раза.
7. Обучить саппорт (скрипты сроков и статусов, плейбук споров).
8. Регулярно проводить фин/тех-сверку и аудит причин возвратов.
Частые ошибки
Путаница с OCT/payout: отправляют «на новые реквизиты», нарушая closed-loop и повышая AML-риск.
Нет учёта частичных сумм: многократные возвраты превышают исходный депозит.
Отсутствие идемпотентности: дубли при таймаутах/повторах.
Слабая коммуникация сроков: всплеск тикетов «где деньги?».
Непрозрачные причины: игрок не понимает, почему именно возврат и зачем на тот же инструмент.
Mini-FAQ
Можно ли сделать reversal, если исходный метод недоступен?
Если окно/канал закрыт (истёк срок, карта закрыта), используйте альтернативный payout с усиленным AML и логом причин.
Чем reversal лучше обычной выплаты?
Проще свёрка, ниже AML-риск, понятнее клиенту. Но не всегда быстрее: зависит от рельс/банка.
Можно ли вернуть больше исходной суммы?
Нет. Возвраты суммарно не превышают депозит по данному платёжу. Выигрыш выводят отдельным payout’ом по правилам.
Как быть с мульти-депозитом?
Возвращать в привязке к каждому `original_payment_id` (пропорционально или точечно, согласно политике).
Обратный депозит (reversal payout) — базовый инструмент «чистых» финансовых потоков в казино и финтехе. Он возвращает средства по исходному следу, снижая риски и расходы на поддержку, упрощая леджер и соответствие регуляторике. Успех внедрения держится на трёх вещах: жёсткий closed-loop, правильные рельсы возврата по каждому методу и дисциплина учёта/свёрки с прозрачной коммуникацией сроков и причин для клиента.