DigiSeller API: автоматизация оплаты и выдачи товара

Digiseller — это в первую очередь движок приёма оплаты и автоматической отгрузки, а уже потом витрина. Вся ценность для реселлера появляется тогда, когда карточку товара обслуживает не человек и не залитый файл с кодами, а ваш сервис, который в момент оплаты идёт к оптовому поставщику и возвращает покупателю рабочий код. Разберём, из чего складывается такая интеграция, где она ломается и как это чинить.

Если вы ещё не работали с площадкой, начните с базового разбора — как продавать на Digiseller.

Что покрывает Digiseller API

Формально API площадки делится на четыре смысловых блока. Названия методов и их параметры сверяйте в актуальной документации Digiseller — она живая и меняется, а мы здесь говорим о логике.

Отдельно стоит блок переписки с покупателем — он не автоматизирует продажу, но пригодится, если вы строите поддержку поверх площадки.

Токен — не константа

Токен живёт ограниченное время и подписывается хешем от вашего секрета и метки времени. Практический вывод: не запрашивайте токен на каждый вызов и не кешируйте его вечно. Правильный паттерн — хранить токен с временем истечения, обновлять за минуту-две до конца срока и делать один принудительный перезапрос, если пришёл ответ об истёкшей авторизации.

Поток оплата → выдача, шаг за шагом

Опишем цепочку так, как её видит ваш backend.

1. Покупатель оплачивает на витрине Digiseller или на Plati.Market. Деньги фиксируются на стороне площадки, продавцу они ещё не принадлежат окончательно.
2. Площадка сообщает о продаже. Либо вы получаете уведомление на свой URL, либо ваш сервис сам опрашивает API по заказу. Уведомление быстрее, опрос надёжнее — на практике нужны оба.
3. Вы проверяете подлинность. Не верьте телу уведомления на слово: сделайте обратный вызов к API по номеру заказа и убедитесь, что продажа существует, сумма совпадает и товар тот самый.
4. Ищете заказ в своей базе. Если запись уже есть и код выдан — возвращаете сохранённый код. Если нет — создаёте запись со статусом «в работе».
5. Идёте к оптовому источнику. Ваш сервис делает заказ у поставщика на конкретный SKU и получает код.
6. Отдаёте контент покупателю и отмечаете доставку на стороне площадки.
7. Пишете результат в свою базу — код, стоимость закупки, идентификатор заказа поставщика, время.

Шаги 4 и 7 люди чаще всего пропускают, а именно они превращают интеграцию из демо в рабочую систему. Подробнее логика состояний разобрана в статье про жизненный цикл заказа в API.

Внешний поставщик за карточкой товара

Смысл конструкции простой: карточка на площадке — это витрина, а склад находится у оптовика. В момент продажи ваш слой-посредник переводит SKU площадки в SKU поставщика, оформляет заказ и отдаёт полученный код.

Что для этого нужно:

• Таблица маппинга. Один товар площадки → один товар поставщика, плюс регион и номинал. Без явного региона активации вы получите поток возвратов.
• Проверка наличия перед продажей. Периодически сверяйте доступность у поставщика и снимайте товар с продажи, если позиции нет, — это дешевле, чем отменять оплаченный заказ.
• Резервный источник. Второй поставщик на ходовые SKU снимает большую часть рисков стокаута.
• Контроль закупочной цены. Цена у оптовика меняется; если вы не обновляете витрину, вы какое-то время продаёте в минус.

Идемпотентность — не заголовок, а ваша база данных

Самое дорогое, что может произойти, — покупка одного и того же кода дважды по одному заказу. Причины банальны: повторное уведомление от площадки, таймаут на вашем вызове к поставщику, перезапуск воркера.

Не рассчитывайте, что вас спасёт заголовок идемпотентности на стороне поставщика — в FoxReload API, например, отдельного заголовка Idempotency-Key нет, и повторный POST создаст второй заказ. Работает другой паттерн:

• перед вызовом поставщика запишите намерение в свою базу — идентификатор продажи площадки, SKU, время, статус pending;
• при неоднозначной ошибке (таймаут, обрыв, 5xx) сначала проверьте статус — запросите список последних заказов у поставщика и найдите свой по SKU и времени;
• создавайте новый заказ только тогда, когда убедились, что предыдущий не создался;
• уникальный индекс по идентификатору продажи площадки в вашей таблице — последняя линия обороны.

Подробный разбор паттерна — в материале про идемпотентность и безопасные ретраи.

Ретраи и очередь

Разделяйте ошибки по типу и реагируйте по-разному.

Паузы делайте растущими и с небольшим случайным разбросом, иначе после сбоя все ваши воркеры пойдут на поставщика одной волной. Число попыток ограничивайте: заказ, который не закрылся за разумное время, должен уходить на ручной разбор, а не крутиться вечно.

Сверка — то, что отделяет прибыль от иллюзии

Автоматизация без сверки создаёт красивую, но неверную картину. Минимальный ежедневный набор:

• Продажи площадки против ваших заказов. Каждая продажа должна иметь ровно один заказ у поставщика.
• Заказы поставщика против выданных кодов. Купленный, но не выданный код — это ваш убыток и потенциальный спор.
• Деньги. Выручка площадки минус её сборы минус закупка минус сборы за вывод. Только это и есть маржа.
• Зависшие заказы. Всё, что дольше N минут висит в pending, попадает в отчёт.

Расхождения бывают всегда — важно, чтобы они находились автоматически, а не через жалобу покупателя.

Где брать товар под такую интеграцию

Схема работает ровно настолько, насколько надёжен источник за карточкой. Оптовый каталог FoxReload закрывает эту роль: 900+ SKU по игровым ключам, gift-картам, top-up и подпискам, один REST API вместо десятка разрозненных поставщиков, автоматическая выдача. Это позволяет держать за витриной Digiseller один интеграционный слой и не переписывать код каждый раз, когда меняется поставщик по конкретной позиции.

Смежные материалы: автоматизация выдачи цифровых кодов, вебхуки по заказам и подключение СБП к Digiseller.