Интернет-магазин в Узбекистане: оплата и доставка
Архитектура checkout: платёжный провайдер, статусы заказа, webhooks, идемпотентность, доставка, возвраты, безопасность и приёмка.
Главное за 30 секунд
Checkout готов не тогда, когда прошла одна тестовая оплата. Магазин должен корректно пережить повторный webhook, задержку провайдера, отмену, частичный возврат, изменение доставки и повторное открытие страницы. Источником истины служит серверный статус заказа.
Сначала модель заказа
- Уникальный номер, состав, цена, скидка, валюта и доставка.
- Статусы создаётся, ожидает оплаты, оплачен, отменён, возвращён.
- История переходов с временем и инициатором.
- Контакты и адрес с минимально необходимыми данными.
- Связь с оплатой, отправлением, CRM и учётом.
Интеграция оплаты
Платёж создаётся на сервере по неизменяемой сумме заказа. После возврата пользователя нельзя считать оплату успешной только по параметру URL: backend проверяет подписанное уведомление или статус у провайдера.
Payme Merchant API, например, описывает серверный обмен JSON-RPC через HTTPS. Конкретный протокол, способы и договорные условия проверяют непосредственно перед внедрением.
Идемпотентность
- Присвоить операции стабильный внешний идентификатор.
- Сохранять входящее событие до бизнес-обработки.
- Повтор одного уведомления не создаёт второй платёж.
- Конфликт суммы или заказа уходит в ручную проверку.
- Ответ провайдеру формируется по его текущему протоколу.
Доставка
- Зоны, тарифы, сроки и недоступные направления.
- Самовывоз с реальным адресом и графиком.
- Вес, габариты и ограничения категории.
- Передача заказа оператору и tracking ID.
- Отмена, перенос, недоставка и возврат отправления.
Checkout UX
Показывайте полную сумму до подтверждения, объясняйте срок и способ связи. Не заставляйте создавать аккаунт, если бизнес-процесс этого не требует. Ошибка оплаты должна сохранять корзину и предлагать безопасную повторную попытку.
Форма проверяется на телефонах, медленной сети и повторном нажатии. Кнопка блокируется только с понятным состоянием, а заказ не исчезает при закрытии вкладки.
Безопасность и privacy
- Не хранить данные карты, если это не предусмотрено сертифицированной архитектурой.
- Секреты провайдера находятся только на сервере.
- Проверять подпись, сумму, валюту и принадлежность заказа.
- Ограничивать доступ сотрудников к контактам и возвратам.
- Логировать события без лишних персональных данных.
Приёмочные сценарии
Протестируйте успешную и отклонённую оплату, возврат пользователя без оплаты, повторный webhook, таймаут, отмену, частичный возврат, смену адреса и недоступную доставку. Сверьте магазин, провайдера и учёт по идентификаторам и суммам.
После запуска настройте ежедневную сверку оплаченных заказов, возвратов и неопознанных операций. Несовпадение должно создавать задачу с владельцем, а не исправляться ручным изменением статуса без следа. Перед релизом перепроверьте актуальные договорные и технические условия каждого провайдера.
Документируйте ручной резервный процесс на случай недоступности оплаты или доставки. Пользователь должен получить честный статус, а команда — способ завершить или отменить заказ без дубля.
Первичные источники и документация
Следующий шаг
Если хотите применить схему к своему проекту, спроектируйте checkout и интеграции магазина. Сначала зафиксируем исходные данные и критерии готовности, затем оценим объём работ.
Посчитайте стоимость под вашу задачу
Ориентир. Финальная смета — после брифа по задачам.
Бесплатная диагностика за 24–48 часов: посмотрим ситуацию, скажем что даст результат, дадим смету.
