Интеграция интернет-магазина: оплата, доставка, склад

Интеграция интернет-магазина помогает разным системам за витриной согласованно работать с одним заказом. Если деньги списаны, а заказ ожидает оплаты, или посылка отправлена без уведомления клиента, проблема часто не в отсутствии подключения, а в неполном описании процесса. Для владельца бизнеса важно не только какие системы соединят, но и какое событие запустит следующее действие. Вместо одной строки «оплата, склад, доставка» составьте с подрядчиком полный жизненный цикл заказа.

Три записи об одном заказе

Платёжный провайдер учитывает движение денег, магазин — заказ клиента, склад — движение товара. Для связи нужны номер заказа и идентификаторы операций. Следует согласовать значения даты, суммы и статуса. Дата операции у провайдера может отличаться от времени создания заказа в магазине. Если панель показывает эту разницу, при обращении клиента проще найти нужную запись. Проектирование интеграции начинается с этих связей, а не с копирования всех записей в одну базу.

Результат оплаты нельзя определять только по возврату клиента

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

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

Для остатков выберите один источник истины

Если количество независимо меняют складская программа, ERP-система и панель магазина, возникают конфликты. Зафиксируйте, какая система учитывает физические остатки и как часто передаёт их другим. Доступное количество не равно всему запасу на складе: зарезервированные, повреждённые и ожидающие проверки товары не должны продаваться. Обязательно сопоставьте артикулы вариантов. Передача количества основного товара не решает учёт по размерам и цветам.

Для резерва заказа, ожидающего оплаты, определите срок и условия снятия. Увеличение остатков до проверки возврата может привести к ошибочной продаже. Если сайт и маркетплейс используют один запас, отдельно оцените последствия задержки. Мгновенный обмен нужен не всем, но его периодичность должна соответствовать скорости продаж и оставшемуся количеству. Выбирайте её не только по техническим возможностям, но и по последствиям продажи отсутствующего товара.

Интеграция доставки — не только печать этикетки

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

Как продолжать работу при сбое связи?

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

• Кто просматривает ошибки и когда передаёт их технической команде?
• Как сохраняется ручное исправление при следующем обмене?
• Кто обновит подключение после смены ключа доступа провайдера?
• Как в конце дня сверяются суммы платежей и заказов?

Принимайте разработку по рабочим сценариям

До начала проекта подготовьте договоры с провайдерами, техническую документацию, тестовые доступы и артикулы. Не смешивайте ответственность разработчика с ответственностью платёжной или транспортной компании. В предложение должны входить сопоставление данных, экраны исключений, обучение и передача исходного кода, а не только подключения. Для интеграции систем с HazırSoft передайте примеры успешного заказа, неудачной оплаты, разделённой отправки и частичного возврата. Тогда разработка будет ориентирована на целостность процессов, а не только на первое установление связи.