Key topics
Related public pages
If you need the product, API or operations page rather than only the article, start with these VPOS.am sections.
Create the order before payment redirect
OpenCart checkout should save order id and pending payment before the customer leaves for the payment page.
For e-commerce, it is safer to create the order before sending the customer to payment. Then the store already has order id, cart, contact data and amount, while the payment attempt is linked to one order.
If order is created only after redirect, successful payments can be lost when the tab is closed, network fails or callback is delayed. Pending payment should be a normal state, not a module error.
- create order in pending payment;
- store amount, currency and order id in payment attempt;
- do not change stock or fulfillment before verified paid;
- allow retry without duplicate order.
Callback endpoint should verify payment, not trust redirect
Final order status should come from a verified server-side flow.
Customer redirect is useful for UX, but it should not be the only source of status. Callback endpoint should verify signature or perform server-side status check, compare amount, currency and order id, then update the order.
Repeated callback must be idempotent. If order is already paid, an old pending or failed callback should not move it backwards. This matters when provider retries events or customer creates another payment attempt.
- verify signature or provider status;
- compare amount, currency and order id;
- do not roll back final statuses with old events;
- log callback payload with secrets redacted.
What to do with refunds, receipts and reconciliation
A payment module closes checkout, but post-payment operations should stay visible to support and accounting.
After successful payment, fiscal receipt, CRM/ERP sync, delivery, partial refund or manual review can start. These operations should not be hidden in one order status, otherwise support cannot see where the issue happened.
Daily reconciliation should compare provider payments, OpenCart orders, refunds and receipts. Exact matches close automatically, while exceptions become tasks with reason and owner.
- store payment status separately from order status;
- keep provider reference for reconciliation;
- support partial refund as a separate record;
- show receipt/fiscal errors separately from paid.
FAQ
Can OpenCart order status become paid after return URL?
Prefer updating status only after callback verification or server-side provider status check. Return URL can be opened without a final payment event.
How should OpenCart handle payment retry?
Create a new payment attempt linked to the same order id. This preserves history and avoids duplicate orders.
Should the OpenCart module handle fiscal receipts?
It can initiate fiscal workflow, but payment status and fiscal status should stay separate so receipt failure does not break successful payment.
