KNOWLEDGE BASE
How do you test payment, shipping, and return flows in e-commerce?
Table of Contents — English
What environment should be prepared before testing?
You need the payment provider's test account, a safe trial facility from the shipping service, and test products that support return scenarios. It must be verified that test operations do not generate real shipments or charges. Use the test data found in the provider's documentation; real card details must not be entered into records.
For each test, write down the initial order status, the expected payment status, the stock impact, and the external system record. A successful result is not just a message on the screen. The financial record, the order history, and the integration record must all show the same transaction.
Which scenarios test the payment flow?
1. Verify separate order outcomes for a successful payment and a payment declined by the provider. Whether the order waits or is closed after a failed transaction depends on the business rule.
2. Have the user close the window before returning from the bank to the store. The result must not depend only on the browser return; it should be checked against the provider's verified transaction record.
3. Send the same payment notification again. A duplicate order confirmation, stock deduction, or notification must not occur. Stripe's webhook guide explicitly addresses repeated events and out-of-order delivery; examine your own provider's policy separately.
4. Try a notification delay and an amount mismatch. If the check of order ID, currency, and expected amount fails, the transaction should be set aside for review.
Why is a shipping label not proof of delivery?
A label being created does not show that the product was handed to the carrier or reached the customer. Evaluate label creation, pickup, and delivery events separately. If a single order can be split into multiple packages, the relationships between items and packages must be preserved.
How are shipping and return tests carried out?
Trigger a timeout while the shipping record is being created, then retry. The first request may already have been processed on the target; the second attempt must not generate a new label. The outcome of the operation should be reconciled using the carrier's identification and query capabilities. When status updates arrive in reverse order, a delivered package must not revert to an earlier status.
In return testing, treat the request, physical receipt, quality control, and refund as separate stages. For cases such as partial returns, discounted items, and shipping fees, the calculation rule must be clearly defined. What is tested here is the technical flow; the business's return policy and the relevant legislation are assessed separately.
How are the results reconciled?
Look for consistency among the order total, the amount collected, the amount refunded, and the remaining amount. Stock should be reopened only under the defined physical receipt rule. A customer must not be sent an "your refund is complete" message while the payment refund has failed.
For each error, record the transaction ID and the external system response; mask sensitive data. The test report should include expected and actual results, the evidence record, and the responsible person. This report provides direct input to the go-live decision.
Frequently asked questions
What is the next step?
List the payment and delivery exceptions you encounter most often; build the end-to-end test scope with PROJX Digital.
