Подключить платёжную форму — только часть задачи онлайн-оплаты. Для интернет-магазина важнее, что происходит с заказом до, во время и после платежа.
Минимально нужно различать четыре состояния: заказ создан, оплата начата, оплата подтверждена, оплата неуспешна или отменена.
Если магазин считает заказ оплаченным только потому, что покупатель вернулся на страницу «спасибо», появляется риск расхождений. Источником истины должен быть подтверждённый статус платёжного провайдера, а повторные уведомления должны обрабатываться идемпотентно — один платёж не должен создавать два изменения заказа.
Вторая часть — способы оплаты. Нет универсального списка «обязательных» методов. Нужны те, которыми пользуется конкретная аудитория и которые поддерживает экономика бизнеса. Для B2C это могут быть карты и быстрые платёжные способы; для B2B — счёт и иной процесс подтверждения. Добавлять десяток методов только ради количества не обязательно.
Третья часть — повторная попытка. Покупатель может закрыть окно, банк может отклонить операцию, может потребоваться дополнительное подтверждение. В заказе должен сохраниться понятный статус, а клиент — получить возможность безопасно повторить оплату без создания нового заказа.
Четвёртая часть — безопасность. PCI SSC отдельно разбирает риски платёжных страниц интернет-магазинов и скриптов, способных повлиять на платёжный процесс. Самый простой путь для малого бизнеса — минимизировать собственную обработку платёжных данных и использовать корректно настроенного провайдера, но это не освобождает сайт от ответственности за собственную платёжную страницу и интеграцию.
Проблема может быть не в оплате. Если пользователи массово не доходят до выбора способа платежа, нужно смотреть предыдущий checkout, цену доставки и ошибки формы.
Практическая проверка: успешно оплатить, получить отказ, закрыть страницу в момент оплаты и затем открыть заказ снова. В каждом случае менеджер и клиент должны одинаково понимать статус.
Если основная модель продаж — B2B со счётом и согласованием, сложный набор мгновенных способов оплаты может вообще не быть приоритетом. Сначала нужно обеспечить понятный статус заказа и оплату, соответствующую реальному процессу клиента.
Можно открыть интерактивное демо PAWNOURISH Market и пройти демонстрационный путь покупателя до оформления заказа. Это не действующий магазин клиента.
При разработке интернет-магазина оплату лучше проектировать вместе с жизненным циклом заказа, CRM и учётом, а не как отдельную кнопку платёжного сервиса.