Start with an order that staff can process
Choose a product with real attributes and an agreed price. The customer should be able to find the right variant, see availability, add it to the cart, and receive clear delivery terms. If a manager determines the shipping cost, the interface should explain this before payment.
Complete a purchase on a phone the team actually uses and on a computer. Check address entry, quantity changes and returning to the product page. A field error should preserve information already entered, and the final amount should match the chosen order contents. If a discount applies, compare the website amount with the payment form separately.
After checkout, a store employee continues the test. They need the items, product variant, customer contact details, address, delivery method and a clear payment status. Ask them to find the order without the developer’s help and carry out the agreed action: confirm it, send it for picking, or print the required document. This tests whether the administrative interface is usable for work.
Payment confirmation must arrive without the customer
First agree a safe test environment with the developer and provider. Final launch separately requires checking the connected live account details; a successful sandbox test does not confirm them. Using real money and issuing a subsequent refund must be agreed by the store owner in advance.
One important scenario is closing the page after payment and checking the order from the store’s side. For example, YooKassa describes server notifications through which an application receives payment state changes. The browser returning to a thank-you page should not be the only way to discover a payment.
Next, test a declined payment and an interrupted attempt. The customer needs a clear next action, and the employee needs a state without false confirmation. Repeated clicks and repeated notification processing must not create an extra order or repeat a financial operation. The developer implements the specific protection according to the chosen payment service’s documentation; the acceptance criterion describes the observable result.
Check cases that change warehouse work
A product with limited stock is useful for acceptance. Record the rule: when a reservation arises, how long it lasts, and how it is released after cancellation. Then run the scenario and compare the available quantity on the website and in the accounting system. If exchange runs on a schedule, assess it within the agreed time limits.
Separately test an address for which delivery is unavailable. The store should show the intended restriction rather than accept payment under unconfirmed shipping conditions. If the delivery service is temporarily unavailable, behaviour should follow the agreement: recalculate, send a request to a manager, or temporarily stop checkout.
A refund is also part of the trading process if it is included in the project scope. Check the order state, the operation’s result at the provider, and staff actions. Changing a button label does not establish that money has been refunded. Include a partial refund in testing when it is part of the agreed implementation.
Reconcile the order with analytics
A counter loading successfully does not yet show that analytics receives purchase contents and value. Yandex Metrica’s ecommerce testing instructions describe checking sent events and observing the data. The developer should demonstrate which action triggers an event and which information is transmitted.
For the control order, compare the identifier, products, quantities and amount. Clarify what the purchase event means: placing an order and confirming payment may occur at different times. Treating them as one metric without explanation will cause advertising reports and cash records to diverge.
The final report should distinguish orders, payments, cancellations and refunds. Analytics helps investigate the customer journey; reconcile the financial status with the order system and provider. This approach allows traffic quality to be discussed after launch using defined metrics.
Record the grounds for launch
A useful testing deliverable is a table with the condition, expected behaviour, actual result and a link to evidence. For a payment, this is the transaction record; for stock, the item state; for an order transfer, a record in the receiving system. Working documents containing personal data remain under restricted access.
Classify discrepancies by their consequences. A lost payment or incorrect amount prevents sales; a small visual imperfection can receive a separate correction deadline. The client decides whether to accept an exception with an understanding of its consequences. Before the store opens, the owner also needs access, a designated contact responsible for enquiries, and an agreed recovery procedure after a failure.
If you are preparing to commission online store development, discuss acceptance at the estimating stage. At pommeDeTerre, you can start with your order journey and identify which outcomes must be demonstrated before launch. Development completion will then be tied to verified store operation, and you can direct advertising traffic to a store that has passed the agreed checks.