Ключевые темы
Связанные публичные страницы
Если нужен не только разбор, а страница продукта, API или операционного сценария, начните с этих разделов VPOS.am.
Заказ лучше создавать до перехода на оплату
OpenCart checkout должен сохранить order id и pending payment до того, как клиент уйдет на платежную страницу.
Для e-commerce безопаснее создавать заказ до перехода клиента на оплату. Тогда у магазина уже есть order id, корзина, контактные данные и сумма, а платежная попытка привязывается к конкретному заказу.
Если создавать заказ только после redirect, можно потерять успешные оплаты при закрытой вкладке, сетевой ошибке или задержанном callback. Pending payment должен быть нормальным состоянием, а не ошибкой модуля.
- создать заказ в pending payment;
- сохранить amount, currency и order id в payment attempt;
- не менять stock/fulfillment до verified paid;
- разрешить повторную попытку без дубля заказа.
Callback endpoint должен проверять платеж, а не доверять redirect
Финальный статус заказа должен приходить через проверенный server-side flow.
Пользовательский redirect удобен для UX, но не должен быть единственным источником статуса. Callback endpoint должен проверять подпись или делать server-side status check, сверять сумму, валюту и order id, а затем менять статус заказа.
Повторный callback должен быть идемпотентным. Если заказ уже paid, старый pending или failed callback не должен откатывать его назад. Это особенно важно при retry со стороны провайдера и ручных повторных попытках оплаты.
- проверять подпись или статус у провайдера;
- сверять amount, currency и order id;
- не откатывать финальные статусы старыми событиями;
- логировать callback payload с редактированием секретов.
Что делать с возвратами, чеками и сверкой
Payment module закрывает checkout, но операции после оплаты должны быть видны поддержке и бухгалтерии.
После успешной оплаты могут начаться фискализация, передача заказа в CRM/ERP, доставка, частичный возврат или ручной review. Эти операции лучше не прятать внутри одного order status, иначе поддержка не поймет, где именно возникла проблема.
Ежедневная сверка должна сопоставлять платежи провайдера, OpenCart orders, возвраты и чеки. Совпадения закрываются автоматически, а исключения становятся задачами с причиной и ответственным.
- хранить payment status отдельно от order status;
- сохранять provider reference для сверки;
- поддерживать partial refund как отдельную запись;
- показывать receipt/fiscal ошибки отдельно от paid.
FAQ
Можно ли менять статус OpenCart-заказа на paid после return URL?
Лучше менять статус только после callback verification или server-side проверки статуса у провайдера. Return URL может быть открыт без финального платежного события.
Как обрабатывать повторную попытку оплаты в OpenCart?
Создавать новую payment attempt, но привязывать ее к тому же order id. Это сохраняет историю и не создает дубль заказа.
Нужно ли модулю OpenCart заниматься фискализацией?
Он может инициировать фискальный workflow, но payment status и fiscal status лучше хранить отдельно, чтобы сбой чека не ломал успешную оплату.
