Online Store Launch Checklist: What to Test Before You Publish

A store is ready for controlled publication when a customer can find the right product, understand the offer, and reach a correctly configured checkout in preview. Publishing activates payments, so complete the paid-order and notification checks on the live store before promotion. Record the expected result, actual result, evidence, owner, and status for every critical check. If pricing, tax, shipping, payment, or order recording fails, pause promotion and fix the cause.

This checklist assumes the store has already been built and configured. If it has not, begin with the complete online-store build sequence. Here, the job is release control: prove what works, expose what does not, and make one person accountable for each decision.

Set up the test before you start clicking

Name one release owner. That person does not need to perform every test, but they decide whether failed checks block publication and confirm that fixes have been retested. Give individual areas to people who understand them: catalog, storefront, payments, fulfilment, tax, and domain or search setup.

Create a copy of the checklist below and use four statuses: not tested, pass, fail, and not applicable. “Looks fine” is not evidence. Useful evidence is a preview URL, screenshot, screen recording, order reference, confirmation email, or a short note containing the input and observed output. Never put full card details, passwords, or unnecessary personal data in the record.

Build a small test set that creates meaningful differences:

• one typical full-price product;
• the lowest- and highest-priced products;
• a product with a longer title or description;
• a product near a shipping threshold, if one applies;
• at least two supported shipping destinations and one unsupported destination;
• one eligible and one ineligible basket for any active promotion.

Use test products and controlled orders where possible. Before the live acceptance check, agree who will pay, the maximum amount, how the order will be identified, and whether it will be refunded. A successful payment must create the expected paid Setka order.

1. Verify product data, prices, and shopping paths

Compare the storefront with the catalog source rather than checking one page against another. Confirm product names, descriptions, images, availability, prices, and any factual claims. Inspect several product pages, not only the most polished one. The lowest and highest prices deserve their own check because formatting and currency errors often show at the edges.

Then walk the navigation as tasks: “find the blue mug,” “return to the main category,” or “reach the cart from a product page.” Check the header, menu labels, category paths, footer links, logo-to-home behavior, and any policy or contact links customers need before buying. A link that opens is not necessarily correct; verify its destination and the page’s meaning.

For each test, write an expected result before recording the result. For example: “Selecting Ceramics opens the Ceramics category and shows the mug” is testable. “Navigation works” is not. If the cart and product presentation need deeper inspection, use the dedicated shopping cart UX guide rather than expanding this release pass into a redesign.

2. Run a compact device matrix

Test on real phones when you can. Browser resizing is useful for finding obvious layout faults, but it does not reproduce every keyboard, browser-bar, touch, or payment behavior. The larger mobile ecommerce UX checklist covers interaction detail; this matrix establishes minimum launch coverage.

On every device, complete the main path from homepage to category, product, cart, checkout, and confirmation. Rotate a phone once, increase text size, and trigger at least one form error. Look for hidden controls, clipped text, horizontal scrolling, unusable keyboards, focus that disappears, and a checkout button covered by another element. This is a launch-focused mobile pass, not a complete accessibility or performance audit.

3. Exercise every important cart state

Start with an empty cart. Its message should explain that nothing is there and provide a sensible route back to products. Add one item, add a second item, change a quantity, and remove each item. Confirm product identity, unit price, quantity, subtotal, discount presentation, and the path to checkout after every change.

Test refresh and back-button behavior. If the shopper leaves the cart and returns during the same session, confirm that the observed state matches the store’s intended behavior. Try an unavailable quantity or other invalid input if the interface permits it. The expected outcome is a clear rejection or correction—not a broken total or a silent failure.

Record rounding and currency formatting exactly as shown. If discounts, shipping, or tax affect the total later in checkout, the cart should not make a contradictory promise. Treat an incorrect product, price, quantity, or total as stop-ship.

4. Check live payment outcomes before promotion

Run this section after controlled publication, because that is when checkout accepts payment. Cover successful payment and, where the selected Stripe methods provide safe scenarios, failed payment and cancellation or abandonment. The Stripe setup guide owns account, currency, and method configuration; this checklist observes the resulting Setka states.

For a successful checkout, confirm that Setka creates the expected paid order, updates inventory, sends the customer confirmation, and notifies the merchant. Check the order lines, quantities, discounts, shipping, tax, total, customer email, and delivery address.

For a failed payment, confirm that Setka does not present the attempt as a paid order and that the customer receives a useful next step. For a cancelled payment, check that the customer can understand what happened and return to a safe shopping state. Treat any unexpected paid status or duplicate order as a product exception to investigate, not a normal merchant reconciliation task.

5. Challenge shipping, tax, and promotions

Use addresses that cross each meaningful rule boundary: the main supported region, another supported region with a different rate, and an unsupported destination. Test postal codes or regions that are easy to confuse. Confirm that the offered method, price, delivery language, and eligibility match the approved shipping table. Do not infer carrier services or delivery times that are not configured and operational.

Tax needs an owner who understands the business’s actual obligations. Check that representative products and supported destinations produce the approved treatment, that the checkout explains whether tax is included or added, and that rounding is consistent. This test validates implementation against an approved tax decision; it is not tax advice or proof that the business is compliant in every jurisdiction.

For each active discount or promotion, test an eligible basket, an ineligible basket, every boundary value, the schedule, any savings cap, and every intended combination. Confirm the displayed reduction, final total, and customer message. If the store has no launch promotion, mark the section not applicable rather than creating one for the test.

6. Validate the domain and public discovery controls

Keep preview testing and public-domain testing distinct. Before publication, confirm the intended hostname, canonical form, and who controls the domain and DNS account. After the approved cutover, test the root domain, common www form where relevant, HTTPS, key internal links, checkout return, and an intentionally invalid URL. The custom-domain publishing guide should contain verified connection instructions; do not copy unverified DNS values into this checklist.

Check crawl and index signals separately from rankings. Confirm that public pages intended for discovery are reachable without login, return the expected page, and are not accidentally blocked from crawling or marked against indexing. Check the sitemap and canonical destination if the platform exposes them. Confirm that preview or staging URLs are not being treated as the public version. After publication, submit or inspect the live property through the search tools the business uses. The ecommerce SEO checklist covers the broader optimization work.

These checks can catch an accidental visibility block; they cannot guarantee indexing or rankings. Use the public URLs and search tools to verify the released store rather than treating a successful preview as search evidence.

Stop-ship criteria: when not to publish

Do not publish, or pause the cutover, when any of these conditions is true:

• a product can be purchased with the wrong identity, price, quantity, currency, discount, tax, shipping charge, or total;
• a supported customer cannot complete payment, or a failed or cancelled payment creates an ambiguous paid order;
• a successful payment does not create the expected paid Setka order, inventory update, or notifications;
• checkout accepts a destination the business cannot serve, or rejects a launch-critical supported destination;
• essential legal, policy, contact, or fulfilment information is missing or materially false;
• a critical path is unusable on a launch-supported phone or browser;
• the public domain points to the wrong destination, has a certificate warning, or breaks checkout return paths;
• public pages intended for discovery are accidentally blocked, while preview or private pages are exposed as canonical public pages;
• the team cannot identify an owner for a failed critical check.

Minor copy or spacing defects can enter a post-launch backlog only when they do not change a product promise, price, legal meaning, navigation path, or ability to buy. Record that decision. “We noticed it” is not a resolution.

Why the preview is the right control point in Setka

Setka generates the whole storefront around the merchant’s brief and catalog, including shared shopping surfaces, while commerce remains inside the same platform. That reduces the number of separate theme, app, and storefront layers a small team must coordinate. It does not remove the merchant’s responsibility to verify catalog facts, commercial rules, payment outcomes, delivery promises, and the public release.

Preview-before-publish makes that responsibility practical: test the candidate storefront before customers see it. Every storefront change is preserved as a storefront-wide version, so the team can keep a known reference and restore an earlier version if a later change is not acceptable. Versioning is a recovery control, not evidence that an untested release is safe.

Printable online store launch checklist

Print this section or copy it into the release record. Add an evidence link or reference for every critical pass.

Test setup

• Release owner and go/no-go decision time are named.
• Catalog, storefront, payment, fulfilment, tax, and domain owners are named.
• Test products, addresses, promotion cases, devices, and browsers are listed.
• Test-order budget, payment method, data-handling rules, and cleanup plan are agreed.
• The exact storefront candidate or preview version is recorded.

Products, prices, and navigation

• Representative product names, descriptions, facts, images, and availability match the catalog source.
• Lowest, highest, full, and promotional prices display correctly with the intended currency.
• Long titles and descriptions remain readable.
• Homepage, header, category, product, cart, footer, policy, contact, and logo links reach the intended destinations.
• A new visitor can complete the top three find-a-product tasks without assistance.

Mobile and browser coverage

• Main journey passes on a small real phone.
• Main journey passes on a large phone or second mobile operating system.
• Main journey passes on desktop or laptop.
• Critical checkout path passes in a second browser engine where practical.
• Menus, images, text, forms, errors, and checkout actions remain visible and usable.
• Rotation, increased text size, and an on-screen keyboard do not block the critical path.

Cart

• Empty cart explains the state and offers a route back to products.
• Add, remove, and quantity-change actions produce the expected item lines and totals.
• Multiple items, refresh, and back-button behavior do not corrupt the cart.
• Invalid or unavailable quantities are rejected or corrected clearly.
• Subtotal, discount, tax and shipping expectations do not contradict checkout.

Checkout, payment, and order

• Successful payment creates a paid Setka order and updates inventory.
• Product lines, quantities, discount, shipping, tax, total, customer, and address are correct in that order.
• Customer confirmation and merchant notification arrive with accurate facts.
• Failed payment does not create an authoritative paid order and offers a useful next step.
• Cancelled payment leaves the customer in an understandable shopping state.
• No scenario creates an unexplained duplicate paid order.

Shipping, tax, and promotion

• Main supported address receives the approved shipping options and price.
• Each materially different supported zone or rule boundary is tested.
• Unsupported destination is blocked with useful language.
• Delivery promises match the fulfilment plan.
• Approved tax treatment passes for representative products and destinations.
• Tax inclusion, addition, and rounding are communicated consistently.
• Eligible, ineligible, boundary, invalid, and expired promotion cases behave as approved, where applicable.
• Promotion totals remain consistent from cart through the paid order.

Domain, crawl, and index checks

• Intended hostname and responsible domain/DNS owner are recorded.
• Root and www forms behave as intended after cutover.
• HTTPS, important internal links, checkout return, and invalid-URL behavior pass.
• Public pages intended for discovery load without authentication.
• Intended public pages are not accidentally blocked from crawling or indexing.
• Canonical and sitemap destinations are checked where exposed.
• Preview or private URLs are not presented as the canonical public store.
• No stop-ship issue remains open; accepted minor issues have owners and due dates.

Test-order record

Use one row per attempt, including failures and cancellations. Never paste payment credentials into the record.

Run pre-publication checks against the preview, publish the controlled release, then complete live-domain and payment checks before promotion. Every critical item needs a recorded pass or a documented not-applicable decision from the release owner.