Show the total before payment
Display products, quantities, discounts and delivery terms before payment confirmation. Explain any amount that requires address confirmation. Let customers correct their basket and contact details without losing input. Registration may help repeat purchases, but should not block an initial order without a clear reason.
Separate the order from payment status
A customer returning from a bank page is not sufficient proof of payment. Verify the provider’s server notification, signature, amount and order identifier. Repeated notifications must not duplicate orders or inventory changes. When using a provider-hosted payment page, do not store card details in your own application.
Design the awkward cases
Customers may close the tab, encounter a bank refusal or return later. Provide clear pending, paid and cancelled states with a safe way to continue. Test through the payment provider’s official sandbox, including cancellation and refund scenarios, before accepting real payments.
- Totals and delivery appear in advance.
- Payments are confirmed server-side.
- Duplicate notifications are handled safely.
- Errors explain the next available action.
Project questions
Should an order be created only after payment?
Not always. Often an order starts in a pending state and payment updates it. The right model depends on reservation and fulfilment rules.