Independent Store Pre-Launch Checklist: Orders, Checkout, and Tracking

Before removing a store password, inviting outside buyers or sending the first traffic, follow one purchase path through entry, order, notices and exception handling. Record what happened, where it can be checked and who will retest it. That gives the team a basis for continuing, narrowing or holding the proposed opening.

Define what this QA run can establish

Launch QA joins pages, checkout, orders, email, fulfillment, policies, data and support in one path. It catches visible faults before buyers do, checks that the journey reaches its notices, and gives operations, support and the reviewer the same state. Correct-looking admin settings are the starting point for that test.

Here, PDP means product detail page; CTA (call to action) is a button or link asking the buyer to take the next step; and GA4 means Google Analytics 4.

UTM parameters label an entry link with source, medium or campaign information so reports can show how a visit arrived. ROAS (return on ad spend) compares revenue attributed to ads with ad spend; it is not profit.

The old page saved only its evidence record. This page separates work into six records: each Save, Restore or Clear button applies to its own record. Reading choices, the main-path/mobile examples and eight manual notes can now be saved separately; they are not answers imported from the old snapshot. The quick question remains transient and must be answered again after refresh. Copying or downloading current notes is different from saving a record JSON.

Choose the path most likely to break first

Select the path that concerns you now, then read what must work, which evidence it needs and what should stop if it fails. User, order, fulfillment, data and exception paths have different closeout standards. A total score cannot describe all of them.

The selection appears in the working note. Run the actual or permitted test path it calls for, then return with evidence. Choosing it has not verified it.

Reconcile the tumbler promise, order and event

Keep the same product, address, device and time while comparing three layers: the promise a buyer sees, the order Shopify records, and the event the analytics or ad system receives. The free-shipping threshold and delivery wording need a consistent basis on the PDP, Shipping Policy and checkout. Do not wait for buyers to ask about the $18 rate.

Open the homepage, main collection, primary PDP, FAQ, policies and Contact. Follow navigation and footer links. Check title, media, price, variants, stock, delivery promise and contact information, then compare language, currency and market presentation with the intended opening scope.

Look for default policy templates, a CTA leading to the wrong or unavailable product, misplaced mobile text and media, edge targets that are hard to tap, and horizontal overflow. A working preview URL does not establish the production domain, HTTPS, canonical, robots or internal route.

Here, canonical identifies the preferred URL for a page; robots and noindex directives affect crawling or indexing. Check the production page is not pointing elsewhere or being excluded.

Follow the test order through notices and cleanup

Keep at least one reviewable test-order trail, one refund or cancellation-path check, and a full retest on the same phone. An order record, payment authorization, capture, provider settlement and bank arrival are different states. Simulation does not establish real collection or payout. An initiated real refund may be irreversible; it is not a cost-free classroom button.

Authorization approves a payment attempt but does not mean the charge was captured; capture charges the customer. For Shopify Payments, settlement is the interval after capture until funds are available for payout, payout is the transfer toward the merchant's bank, and bank arrival is the bank's later posting. Other providers can use different states and timing, so compare the relevant admin and bank records instead of treating checkout success as cash received.

First check store type, paid-plan requirements, provider setup and the test method permitted for this run. Available routes include Shopify’s Test payment gateway (formerly Bogus Gateway), Shopify Payments test mode or the provider’s own test environment, each with its own test data. Test mode affects live ordering and should not be switched on casually in a production store. The original real small-order route remains a separate action requiring authority and fee/refund review; it is not this lesson’s default.

Record ordinary cards, Shop Pay, Apple Pay, PayPal Wallet, Installments and subscriptions separately. Current Shopify Payments guidance permits Shop Pay credit-card tests on a store with that test mode active, using a test card whose nickname starts with test_card. It excludes Installments; PayPal Wallet is also outside that test-mode coverage. A visible button, passing ordinary card or successful desktop test cannot stand in for another method. Mark a store-specific route unverified until it is checked.

Before testing, identify automatic fulfillment, inventory, email and third-party app effects. Do not buy shipping labels or perform real fulfillment for simulated orders. Preserve shipping-notice and tracking checks through an appropriate permitted sample, sandbox or already authorized record. Afterward, read back the actual provider and mode in Settings › Payments and restore the intended setup; disabling one switch does not prove the prior provider is active again. Review payment/cancel/refund/retention state, stock, notices, tags and automation. Archiving tidies open orders; deletion has type and state restrictions. Neither replaces payment or fulfillment review.

Payment success still leaves handling time, transit time, shipping email, first scan, tracking link and exception ownership to check. Leave unopened markets untested. If a rate or duties result cannot be explained, narrow that path first rather than rewriting a verified primary-market promise.

The original opening example records entry and product: 2/6. These editable manual example states do not establish completed work in your store. Read each evidence requirement and change the rows to describe the present work. This board cannot tick the independent five evidence checks below.

The original example records only CTA: 1/4. It is independent of the main-path board and the five evidence checks. Change each row from evidence for this run rather than treating a default as acceptance.

Do not tick everything to improve the progress display. Another reviewer should be able to find the evidence for the same path. A count cannot supply a missing order, email or refund record.

Check phone inputs, overlays and return paths

Record a real phone model, OS, browser, network and entry. A mobile viewport can reveal layout faults early, but it does not cover a real keyboard, wallet, redirect, return or network. After desktop review, repeat home, collection, PDP, cart, checkout and thank you/order status on the phone.

Check that price, product image, variant, shipping and trust information are available without excessive scrolling, and that the first-screen CTA is easy to tap. Open the keyboard and change country, province/state, postal code, phone and payment method before reviewing field guidance, button placement and scrolling. Signup popups, chat, sticky bars, reviews, images, tables and apps can overlap controls or widen the page.

Seeing a button is only the start: select the main SKU, add it to cart, enter an address, use the available payment route and return to order status. Hold a blocked purchase path; schedule minor non-purchase styling separately.

Reconcile purchase and source with one order

Order facts, analytics events and ad attribution answer different questions. Identify where each event is generated, where it can be inspected and what a mistake would affect. Before testing, check the integration, consent choices and available debugging method. Do not install another script simply to make an event appear.

CAPI does not provide permission to bypass privacy choices. Recheck collection conditions for the actual integration, platform and market. Attribution assigns credit, and reported revenue has not subtracted all product, shipping, advertising, refund and fee costs. Neither establishes profit, bank cash or independently measured incremental sales.

Write down the amount basis before reconciling values. Google’s purchase example defines value as item price multiplied by quantity, with tax and shipping separate. Shopify’s Meta integration documentation describes an order total that includes duties, taxes and discounts. Match order identity, items, currency and each platform’s correct amount; a documented basis difference is not automatically a missing order.

If the order and email exist but purchase does not, Hold and inspect firing, transaction_id, value, currency, items and page/integration scope. Do not scale from ROAS or revenue in unaccepted data. Report delay does not establish that an event fault was repaired.

Give the buyer a way forward after failure

In a permitted environment, check failed payment, invalid address/unsupported region, zero stock/unavailable variants, invalid coupon, delayed email and broken contact. Each branch should tell the buyer what can change and who can help. Support also needs a lookup route. One ideal order cannot test that.

Keep the error, value rollback, order state or alternative lookup route, then retest under the same conditions. Stock and expired-discount cases also need consistent storefront, cart and checkout behavior.

Make issues reproducible and closable

Build an issue closeout table for pages/navigation, checkout/payment and data/support. List critical pages and paths, walk them on desktop and mobile, then repeat after the repair. Memory and “checked” are not a closeout method.

Screenshots and recordings help communication, but an authorized reviewer should still be able to locate the same order, report or email tomorrow. Orders need payment/refund state, stock change and email subject. Fulfillment needs a redacted representative-address reference, rate, tax/duty display, free-shipping threshold and policy URL. Data needs parameters, UTM and test event. Mobile needs device, browser, entry, failure point, lead and retest time. Keep sensitive originals in an appropriate location you control; use non-sensitive summaries here.

After a page/navigation repair, regress both desktop and mobile. Checkout/payment needs a complete reviewable test-order trail. Data, order-status and support issues need an accountable lead, status, retest time and evidence of closure. “Fixed” alone cannot close them.

Rank issues by their effect on the buyer

Separate blockers, fixes required before launch, minor deferrable faults and issues needing observation. Payment failure and helper copy deserve different priorities. A Watchlist item still needs a metric, window and trigger action.

Write the selected rule with its impact, lead and retest method. Someone able to coordinate the repair must close a blocker. Put minor styling in the first-week fix pool; review issues requiring real orders within their agreed window.

Four launch situations that invite the wrong call

Read each signal beside the tempting action, safer decision and first evidence. The same successful payment screen can coexist with a mobile overlay, shipping surprise or incompatible tracking.

Here, 3PL means third-party logistics provider: an outside business handling fulfillment work. Its timing still needs confirmation for the route being tested.

Desktop proof cannot replace a blocked phone payment. Repair shipping and policy conflicts first. When thank you/order status behavior depends on settings, apps, plan or development scope, verify that scope before deciding. Do not upgrade those pages, tracking, apps and payments together on launch day.

Shopify’s checkout and accounts editor is separate from the theme editor and covers the relevant checkout, thank you, order status and customer-account settings. Basic or higher supports standard customization and eligible thank-you/order-status apps. App customization on information, shipping and payment pages, plus advanced features, remains within Shopify Plus limits. Classify friction as a setting, app, plan-permission or development issue, then inspect the store’s current interface.

Use public scanning to choose where to investigate

Identify the production domain, HTTPS, homepage, policies, Contact and primary PDP URLs to inspect. If the site is private or passworded, record that scope. Do not remove a password or publish merely to obtain a score.

The visible form currently sends a store URL, platform hint, stage and manual confirmation flags. It does not upload or inspect order screenshots, recordings, email samples, ad-account IDs, support threads or delivery proof. Public crawl findings, an available PageSpeed result and manual confirmations have different origins. Failed, unavailable or unconfirmed evidence should remain unverified.

Put report URL, failed page type, HTTP status, review time and lead into your QA table, then add the corresponding manual material. A page not found by the crawler may reflect discovery or crawl scope. A tool signal does not establish purchase, delivery or support outcomes.

Give seven checks separate Go and Hold conditions

Payment, mobile, tracking, policy, SEO, speed and support need distinct evidence. These seven review checks turn a public diagnostic or a manual flag into a retest job. They do not claim that the Scanner automatically performed every check.

Each gate needs manual proof, a condition to continue, a hold condition and a write-back. One score, green item or success cannot speak for another gate. An accessible policy URL does not establish applicable legal duties; SEO basics do not guarantee indexing or ranking.

Start with the affected page and action, then interpret the score. LCP describes main-content loading, INP responsiveness after interaction and CLS layout movement. Reference good limits are LCP at most 2.5 seconds, INP at most 200 milliseconds and CLS at most 0.1, within a defined device and statistical window. Shopify’s summary uses the 75th percentile of real visits over the past 30 days; data may lag up to 36 hours, and new/private stores may have no metrics. A lab score, emulator or historical report does not guarantee this phone now. Hold a purchase path with a blank hero, late controls or blocking images/scripts/apps; log a minor non-purchase-page problem for follow-up.

Use a keyboard to check visible focus, sensible order, menus, links, variants, cart, forms, errors and contact. Check that an overlay can close and return focus to its entry. Include actual content and relevant assistive-technology review. One score or keyboard pass does not establish complete accessibility or legal compliance.

Read four lanes in one release sheet

Review public surface, checkout/order, tracking/events and operations/support together. Launch QA Command Center was the internal shorthand; the deliverable is each lane’s Go/Hold condition, evidence, confirming lead and first-hour action.

A passing page does not establish checkout, checkout does not establish usable purchase data, and data does not establish support. One Hold cannot be hidden by a different passing lane.

Decide which faults directly affect ordering

Compare three actions for each issue: repair today and retest the same path, delay until the setup or integration can be checked, or pause the affected opening. Use the six concrete categories and their evidence to choose the response.

A PDP promising 2-5 days while the policy says 7-12 needs reconciliation even if checkout technically succeeds. Fixing a button does not resolve payment-provider review or a payout hold. Major theme work, app replacement, support migration, Consent Mode and cross-domain tracking changes need their own regression window.

Make the call from scope, evidence and a stop condition

The four states organize work; they do not act on the publisher’s account. Go still starts with a bounded opening and observation. Buyers should not discover faults in an unverified critical path.

Discuss soft launch only after the critical purchase path passes and the remaining gap is nonblocking and observable. Name the market, SKU set, entry, budget cap, retest time and trigger action. Missing tracking may leave data unusable and calls for diagnosis first; do not acknowledge unexplained purchase data while scaling from its ROAS or revenue.

Give the last two hours actions, confirmers and evidence

This is an example schedule, not a platform deadline. Work through T-120, T-90, T-60, T-30 and T-10: freeze risky changes, test the phone order, reconcile payment/events, align promises/support and re-rank open issues. Arrange the named second reviewer for checks that call for one. A solo operator still needs a clear authority and a later review point.

Keep the actor, confirmer, first proof and pause rule for each window. Without evidence, continue the test; a chat message saying “checked” is not closure. Real payment, refund, notice and publication actions retain their own authority requirements.

Keep a blocker-repair lane, record the version, affected paths and rollback, then repeat relevant regression. Do not redesign the theme, change the offer or start complex automation in the first hour. Review orders, failed payments, email, support and purchase within 24 hours, then repeating exceptions at 72 hours. This is an operating cadence, not a platform SLA.

Record device, market, cleanup and observation

Choose the combination being checked. Each row includes device/browser, market, action, failure/pause/recovery, observation and suggested severity. Untested combinations remain untested. These examples are not measurements detected from this browser.

The five review checks start empty. scope, matrix, severity, cleanup and monitor must all be recorded before the result says the record is ready. The main 2/6 example, mobile 1/4 or another selection cannot tick them. This measures record preparation, not release permission.

Enter only a non-sensitive summary needed for this review. Do not include customer names, full addresses, complete order IDs, payment data, credentials, full recording links or internal account screenshots. Keep sensitive originals separately and use a redacted reference, version and time that you can locate.

The two records retain the six evidence text fields; the first also keeps the selected row, five review ticks and evidence answer. Imported line breaks and an incorrect answer stay as saved. The old textareas were unbounded; each native long-text field has a 2,000-character cap, with existing per-record text and storage limits. Keep longer originals separately; arbitrary-length legacy notes are not claimed lossless. Save/restore/download/clear affects its own group. If a browser operation fails, the current notes remain available for manual copying.

What does “checked” mean without evidence?

The quick question retains its original option order and separate feedback. It has no saved-record binding: refresh requires another answer. Its current feedback appears in the copied working note.

Route the earliest unresolved gap to repair

If refunds, lost parcels, missing email or failed payments lack an owner, build the support path. If rates, timing, duties, tracking or exception promises are unclear, return to fulfillment. Once QA evidence is ready, connect orders, data, support, inventory and review cadence. A route does not establish that its prerequisites are complete.

Give refunds, lost parcels, email failures and inquiries an owner, response boundary and escalation route. Pass an exception that cannot be handled today to someone able to decide, and record the next contact or review time.

QA working notes for the next reviewer

Add current pressure, first proof, this-week action, stop action, review window, release sheet, final manual judgment and next route. The eight original manual notes are now saved in groups. Explain which issue affects ordering, whether it can be fixed today, who retests, what stays frozen and what comes next.

The note begins with current selections and specific summaries, then the six evidence texts and eight notes. It ends with complete, unfiltered reference sentences so every original branch’s full advice and reason can be found. Those references are not all active at once. Copy/download .txt produces current working text; saving group JSON stores the browser record. Neither substitutes for the other.

Keep the full record in a suitable location you control, with sources, version, date and next review time. Hand it to an authorized reviewer. If clipboard access fails, select the preview and copy manually. Successful copying does not establish a passing purchase path.

Close this QA run with a reviewable path

Use the sequence below for planning and review. Actual account, transaction, refund, notice and publication actions still require their own permissions. Completing local records only saves the learning work.

Leave one scoped judgment and the next missing piece of evidence. When real conditions change, verify the same path again before updating the record.

Questions before opening

Take the issue to its working lesson