Автовыдача заказов на FunPay: магазин, который отгружает заказы ночью

Проблема, которую решает автовыдача

На FunPay продавец вручную высылает товар после каждой оплаты. Днём это терпимо. Ночью покупатель платит, ключ не приходит — я сплю. Он ждёт, нервничает, открывает спор, ставит холодный отзыв. Магазин, который отгружает только пока продавец в сети, теряет выручку прямо по расписанию моего сна.

Я продаю Prism Pro на FunPay и хотел простого: оплатил — сразу получил рабочий ключ, в любой час. Дальше разбираю схему, которую собрал и гоняю в проде под именем QoLab.

Почему нельзя просто дёрнуть API

Первая мысль — «сделаю вебхук на оплату и буду слать ключ». Не выйдет. У FunPay нет ни официального API, ни вебхуков. Площадка не пришлёт вам событие «заказ оплачен». Классический путь интеграции здесь закрыт.

Рабочий способ один — бот на cookie-сессии вашего аккаунта, который сам следит за чатами и заказами, как это делали бы вы руками. Я взял FunPayCardinal. Это открытый бот: логинится вашей сессией и ловит новые оплаченные заказы.

Как устроена схема QoLab

Цепочка простая, четыре шага:

1. Match. FunPayCardinal видит оплаченный заказ и определяет, что это мой лот Prism Pro.
2. Mint. Мой плагин plugins/qolab_delivery.py чеканит свежий ключ через POST https://api.qolab.space/admin/keys. Ключ генерируется под конкретный заказ прямо сейчас — никакого заранее забитого списка.
3. Message. Плагин отправляет ключ покупателю прямо в чат FunPay.
4. Dedup. Проверка, чтобы один заказ не выдал два ключа. Бот иногда видит одно событие дважды. Без защиты от повторов второй ключ уходит бесплатно.

Отдельно про динамический ключ. Многие магазины держат готовый склад кодов и отдают по одному из файла. У меня ключ рождается в момент покупки через мой же admin-эндпоинт. Склад не кончится посреди ночи и не протухнет. Каждый код привязан к своей продаже.

Что держит всё под контролем

Автовыдача — денежный путь, и на аккуратности здесь я не экономлю. Ядро схемы (match, mint, message, dedup) покрыто тестами. Логика, которая решает «мой это лот или чужой» и «выдавали уже этот заказ или нет», должна ломаться в тесте. На живом покупателе — недопустимо.

Почему это принципиально:

• Ошибка в match — бот выдаёт Prism Pro тому, кто купил другой лот.
• Ошибка в mint — покупатель оплатил, ключ не сгенерировался, и он ждёт молча.
• Ошибка в dedup — один заказ вытягивает несколько ключей, магазин раздаёт товар в минус.

Весь стек мой: бот на моём аккаунте, плагин мой, эндпоинт чеканки ключей мой. Между FunPay и покупателем нет чужого посредника, который в любой момент поменяет правила.

Что нужно, чтобы повторить

Хотите собрать похожее для своего магазина — порядок такой:

• Поднять FunPayCardinal и залогинить его cookie-сессией своего аккаунта FunPay.
• Написать плагин, который срабатывает на оплаченный заказ нужного лота.
• Завести источник товара: склад ключей или, как у меня, свой эндпоинт, который чеканит код на лету.
• Обязательно добавить защиту от повторной выдачи по одному заказу.
• Прогнать тестами денежную логику до того, как включать её на живых продажах.

Что это даёт на практике

Магазин перестаёт зависеть от того, в сети я или сплю. Покупатель платит в три ночи и через секунду видит ключ в чате. Отзывы теплеют, споров из-за ожидания почти нет, а сам я больше не заложник уведомлений на телефоне.

Схема не универсальна. Она держится на cookie-сессии, поэтому её надо поддерживать и приглядывать за аккаунтом. Официального пути FunPay не даёт — это осознанный компромисс. Для магазина цифровых товаров с постоянным потоком заказов такая автовыдача окупается первой же спасённой ночной продажей.