Phase 5 · Launch acceptance
Test Orders and Launch QA: Walk from Successful Payment to Cancellation and Refund
Under controlled access, freeze the candidate, cover success, failure, discounts, free shipping, tax, notifications, inventory, fulfillment, tracking, cancellation, refunds, and events, then remove protection with first-day monitoring and rollback.
What counts as complete in this lesson
Use Online Store > Preferences, Settings, Products, Orders, Analytics to reach the correct page, then configure, save, verify, and record the result. Completion means you can point to the saved state, verification result, and condition for continuing.
- Admin path
- Online Store > Preferences, Settings, Products, Orders, Analytics
- Lesson output
- A signed launch report with test cases, evidence, blockers, fixes/retests, test-mode closure, password removal, monitoring owner, and rollback conditions.
- Continue when
- Success, failure, and boundary cases have results, the post-order path reconciles, test mode is off, and password removal and monitoring have second-person review.
- Stop when
- Do not launch when a critical case fails, test-mode state is unclear, refunds or inventory cannot restock, or rollback has no owner.
Evidence boundary: One successful test and a sign-off sheet do not prove that all future traffic, devices, markets, payment failures, or third-party interruptions will be safe.
Why this lesson comes now
A store opening and a product adding to cart do not prove launch readiness. Evidence connects one order from market, product, inventory, shipping, tax, payment, notification, fulfillment, tracking, and events through refund; after a failure, repair the responsible setting and rerun the affected path.
Prepare before opening the admin
- Review the first 19 lesson gates and keep the store password-protected or otherwise controlled.
- Prepare desktop, iPhone/Android viewports, Gmail, Outlook, and at least two test addresses.
- Freeze candidate versions for theme, products, policies, payments, shipping, tax, notifications, and pixels.
Follow the English admin step by step
After each step, refresh the admin or verify the storefront. A saved admin state does not automatically prove the customer-facing result.
Freeze the launch candidate
Record versions and times for theme, products, policies, payments, shipping, tax, and pixels. Do not redesign or install Apps in parallel during QA; log every change and mark the cases that need retesting.
Expected result: Have a stable launch candidate and a change record.
Completion standard: A second person can restate the candidate state by version, time, and issue, and testing is not contaminated by unrecorded changes.
If the result is missing or wrong: When an unrecorded change occurred during QA, confirm the current theme/configuration, mark affected cases, and refreeze instead of keeping old results.
Evidence to keep: Keep version, change time, issue, affected cases, owner, and sign-off state.
Browse the storefront and add to cart first
Use desktop and mobile to check home, menus, search, collections, products, variants, inventory, cart, discounts, and policies. Test slow network and incognito browsing so login cache or admin preview does not hide a problem.
Expected result: Have storefront results for real customer entry, product selection, cart, and policy paths.
Completion standard: Key pages open on desktop and mobile, with variant, price, inventory, discount, and policy display matching the candidate.
If the result is missing or wrong: When customers cannot pay after launch, check test mode, provider status, Markets, currency, and checkout; restore password protection and roll back when the stop line is met.
Evidence to keep: Record device, network, storefront URL, product/variant, discount, inventory, policy, and add-to-cart result.
Failure handling: Do not judge usability only in admin preview; repeat the customer path in incognito and on mobile.
Run successful, failed, and boundary orders
Run successful, failed, and cancelled payment, both sides of the free-shipping threshold, discounts, a second-region tax case, and an unsupported address. Record expected result, actual result, order ID, and evidence for every case.
Expected result: Have results for success, failure, cancellation, discount, shipping, tax, and unsupported-address cases.
Completion standard: Every case connects expectation, actual result, order state, inventory, notifications, and issue.
If the result is missing or wrong: When a case fails, preserve the order and logs, identify whether payment, shipping, tax, market, inventory, or notification is responsible, then repair that setting and rerun.
Evidence to keep: Record case ID, order ID, address type, amount, payment state, error, capture, and retest time.
Accept the post-order path
Check Order confirmation, committed inventory, Location assignment, staff alert, payment transaction, and events. Create fulfillment, add tracking, send the notification, and open the tracking link from customer email.
Expected result: Have one complete correspondence from payment through notification, fulfillment, tracking, and events.
Completion standard: Order timeline, inventory location, payment transaction, customer/staff notifications, fulfillment, and tracking link agree.
If the result is missing or wrong: When an order exists but notifications are missing, check trigger, recipient, sender, spam, template, and order state; contact the customer manually if needed and keep an incident record.
Evidence to keep: Keep order ID, transaction, Location, fulfillment, tracking, email Message ID, event ID, and owner.
Failure handling: Do not use an order existing in admin as proof of downstream completion; read customer email, order timeline, and actual inventory separately.
Test cancellation, refund, and restock
Cancel or refund the test order and verify payment record, email, inventory restock, tax, and analytics events. Record fee and payout boundaries without assuming test-store data equals live settlement.
Expected result: Have post-cancellation/refund results for payment, inventory, notifications, tax, and events.
Completion standard: Refund amount, state, inventory restock, tax line, notifications, and analytics changes have evidence rather than only a clicked button.
If the result is missing or wrong: When results disagree, preserve the original order, refund ID, and timeline, then isolate payment, inventory, tax, notification, and event sources before retesting.
Evidence to keep: Record order ID, cancellation/refund type, refund ID, inventory change, tax line, email, event, and fee boundary.
Remove the password and start launch monitoring
After every blocker closes, verify payment test mode is off and the primary domain and Markets are correct, then remove protection under Online Store > Preferences or the current password setting. Monitor checkout, payments, notifications, inventory, events, and support for the first 24 hours; restore protection or the prior theme when rollback criteria trigger.
Expected result: Have second-person confirmation of password state, test mode, launch domain, monitoring owner, and rollback action.
Completion standard: All critical sign-off areas pass, test mode is off, password removal and monitoring window are recorded, and the named owner can execute rollback.
If the result is missing or wrong: When inventory or events duplicate, pause the relevant App or automation, inspect Location adjustments, webhooks, and duplicate pixels by order timeline, then rerun the same case after repair.
Evidence to keep: Keep password-removal time, test-mode state, primary domain/Markets, monitoring owner, observation window, sign-off, and rollback record.
Failure handling: Do not launch when a critical case fails, test-mode state is unclear, refunds or inventory cannot reconcile, or rollback has no owner.
Apply the decision in your store
Freeze the version under password protection, then browse and add to cart on desktop, mobile, and incognito. Use success, failure, boundary, and unsupported-address orders to verify the post-order path, then have a second person confirm test mode, password, primary domain, Markets, monitoring, and rollback.
Use the admin path above, then apply it to one concrete situation.
Use this lesson in your store
By the end, you should have: A signed launch report with test cases, evidence links, blockers, fixes, retests, proof that test mode is off, password-removal time, monitoring owner, and rollback conditions.
Relevant admin path: Online Store > Preferences, Settings, Products, Orders, Analytics
Make the decision before reading the reason
Choose the action that solves the problem first, then read the explanation.
Confirm these items in your store
Check each item against the current store; this checklist does not save settings or run tests.
This screen still cannot tell you: One successful test and sign-off sheet do not prove future traffic, devices, markets, payment failures, or third-party incidents will always pass
Continue when: success, failure, and boundary cases have results, post-order paths reconcile, test mode is off, and password removal/monitoring are second-person checked
Stop when: If any critical case fails, test-mode state is unclear, refund/inventory cannot reconcile, or rollback has no owner, do not launch
Next: After launch, retain and update these cases from real incidents, then continue into operations, data, and growth lessons instead of treating QA as one-time work.
Complete the decision or checks first. When information is missing, a pause is safer than guessing a pass.
Launch sign-off must include the rollback action
Release approval cannot say only “it looks fine.” Every row needs a pass condition, actual evidence, owner, and failure action; every blocker must close before launch or explicitly block it.
| Area | Pass condition | Actual evidence | Rollback action | Owner/decision |
|---|---|---|---|---|
| Store access and password | Desktop/mobile access follows plan; password state is explicit | Access result/time: ________ | Restore password or close release entry | Owner/pass or blocked: ________ |
| Products and inventory | Products, variants, prices, Location, and out-of-stock behavior pass | Product/SKU: ________ | Unpublish affected products | Owner/pass or blocked: ________ |
| Payment, tax, and shipping | Target-market success, failure, and boundary cases pass | Test orders: ________ | Pause the affected market or payment method | Owner/pass or blocked: ________ |
| Policies, notifications, and events | Policies work, key messages arrive, events do not duplicate | URL/email/events: ________ | Restore prior version or disable faulty source | Owner/pass or blocked: ________ |
| Monitoring and rollback owner | Someone owns first-day orders, payment, inventory, notifications, and support | Owner/observation window: ________ | Execute the written action when a trigger is met | Owner/pass or blocked: ________ |
Decisions to make in this lesson
Enter the actual values for this store row by row. Do not treat examples or planned values as completed work. Mark a row passed only when the condition and saved or tested evidence are present.
| Item | Recommended setting | Why |
|---|---|---|
| QA environment | Password-protected release candidate | Prevents tests affecting real customers |
| Launch gate | All blockers closed | Critical issues cannot wait until after launch |
| Evidence | Expected, actual, capture, order ID | Makes issues reproducible and reviewable |
| Rollback | Restore password or prior theme | Limits damage quickly when failure appears |
Do not change these blindly
- Do not run only successful orders or test only in admin preview.
- Do not install Apps or change theme or payment without a QA change record.
- Do not defer a blocker to after launch; write the action to restore password, pause a market, or return to the prior theme first.
FAQ
Can one successful order approve the launch?
No. Cover failure, cancellation, refund, discount, shipping, tax, unsupported address, notifications, fulfillment, tracking, and event boundaries.
Can we keep changing the theme during QA?
Not without control. Freeze the candidate first; log every change and mark affected cases, or old results no longer prove the current version.
Does turning off test mode guarantee live payment?
No. Confirm provider status, market, currency, primary domain, checkout, customer notifications, and live monitoring, with a rollback path for stop conditions.
Conclusion and continue line
Launch QA is not “it looks fine.” Every critical area needs expectation, actual evidence, owner, pass condition, and failure action. Continue only when success, failure, and boundary cases reconcile, test mode is off, and password and monitoring are reviewed.