Проверка вариантов платёжной интеграции
- До
- Подтверждённого пути через нативное платёжное расширение нет
- После
- Составлена карта из 21 эксперимента
Торговля на ShopifyРабота для клиента
Я описал 21 эксперимент с платёжными интеграциями и сделал оплату на странице провайдера с серверной проверкой. Тесты в песочнице и приёмка продавцом описаны отдельно.
Задача
Продавцу на Shopify нужен был провайдер, которого нельзя подключить обычным поддерживаемым способом. Сначала нужно было проверить доступные места интеграции и выяснить, как безопасно обновлять заказ Shopify после внешнего платежа.
Я начал с исследования реализуемости (spike). Затем сделал переход к оплате и бэкенд её подтверждения.
Знакомо?
Расследование
Я описал 21 эксперимент: нативные платёжные расширения, интеграции в чекауте и после него, страницы оплаты провайдера и запасные архитектуры. В матрице есть недоступные варианты и варианты, которые только исследовались. Успех всех 21 эксперимента я не заявляю.
При тестировании обнаружилось ограничение: доступные магазины разработки Shopify не давали пройти чекаут с ручной оплатой. Я проверил подтверждение платежа на неоплаченных заказах с ручным способом оплаты, созданных через Admin API. Полный путь покупателя в магазине продавца этим не проверен.
Передача
Акт передачиСдано Пилотный бэкенд задокументирован в работе в сентябре 2026; приёмка у продавца не подтверждена
В выбранном варианте сначала создаётся неоплаченный заказ Shopify с ручным способом оплаты. Блок на странице «Спасибо» или странице статуса заказа открывает страницу оплаты провайдера. Данные карты остаются у провайдера.
Сервер проверяет платёж перед изменением статуса заказа Shopify. Возвращения покупателя по ссылке недостаточно. Сервер запрашивает текущий статус у провайдера и только после подтверждения отмечает заказ оплаченным. Затем повторно читает заказ Shopify и проверяет сохранённый статус.
Проверку оплаты могут запустить подписанный вебхук, возвращение покупателя или сверка по расписанию. Все три пути используют одну логику. Общая защита от повторной обработки не даёт несколько раз записать статус «оплачен».
В документации описаны настройки терминала, получение статуса платежа для автоматизаций, повторные попытки и ограничения интеграции. Возврат у провайдера не создаёт возврат в Shopify автоматически. Решение остаётся за продавцом.
До → после
Работа для клиента Сделано для реальных клиентов. Данные клиентов обезличены.
Проверка вариантов платёжной интеграции
Одновременные попытки подтвердить оплату в тесте в песочнице
| Объём | Наблюдаемый результат | Проверено |
|---|---|---|
| Работа по реализуемости | Матрица из 21 эксперимента; доступ к нативному расширению заблокирован | сентябрь 2026 |
| Проведение оплаты в песочнице | Подтверждённый платёж у провайдера, затем обратное чтение статуса оплаты в Shopify | 11 сентября 2026 |
| Тест на повторное проведение оплаты | 48 параллельных попыток оператора плюс обработка вебхука и возврата дали одно обновление «оплачен» | 11 сентября 2026 |
| Обработка сбоев | Отклонённые, истёкшие и отменённые платежи остались неоплаченными; повторные вебхуки не вызвали ещё одного обновления «оплачен» | 11 сентября 2026 |
| Релиз бэкенда | Проверки состояния и работающего кода записаны на развёрнутом бэкенде | 15 сентября 2026 |
Заметка Данииладо того, как вы решите
В исследовании платежей важно проверить доступный маршрут и описать его ограничения. Я отдельно проверяю место интеграции, подтверждение платежа, сохранение статуса в Shopify и приёмку продавцом.
Даниил
Я разобрал потери атрибуции у магазина товаров для безопасности дома в США: разделил влияние согласия, офлайн-продажи и лишние события покупки Meta. Восстановление проверил по заказам.
Здравствуйте, я Даниил.
Я сам разбираюсь в задаче, выполняю работу и передаю результат. Все вопросы вы обсуждаете напрямую со мной. Общаюсь на русском и английском. На испанском могу переписываться с помощью переводчика.
Отвечу в течение одного рабочего дня. Первый ответ бесплатный. Или напишите напрямую: next@taskfordaniel.com