What acceptance means
Developers test that what they built works. Acceptance asks a different question: can this business trade on this store tomorrow? Only the people who will run it can answer, because only they know what a correct order, invoice and delivery look like. A store can pass every technical test and still charge the wrong tax in one region or send orders to the warehouse without the gift message.
Acceptance needs three things agreed in advance: the scenarios to be tested, who signs each area, and what would stop the launch. Without the last, the decision is made under pressure on launch day, and the answer is always go.
Test real orders from start to finish
The core of acceptance is a set of orders placed as a customer would place them and followed through every system until the money and the goods are accounted for. Use real products and real addresses.
| Scenario | Follow it through to |
|---|---|
| A simple order, new customer, card payment, home delivery | Confirmation email, payment captured, order in the ERP or order system, stock reduced, pick, dispatch email with tracking, invoice |
| A guest order | The same, with no account created |
| An order with a discount code and a sale item | Correct totals on screen, in the email, on the invoice and in the accounts |
| Each delivery option, including collection | Correct charge, correct instructions to the warehouse or shop |
| Each payment method | Captured or authorized as intended, with the right reference in finance |
| A destination with different tax or duties | Tax as your accountant confirmed, shown clearly to the customer |
| A variant, a bundle and a pre-order or backorder | Right items, right stock movements |
| A failed payment, then a retry | Clear message, basket kept, one order created, not two |
| A cancellation before dispatch | Stock returned, payment released or refunded, emails sent |
| A full and a partial refund | Money returned to the original method, stock and accounts correct |
Before launch, place at least one order in the live store with a real card, for a small amount, and refund it. Test modes do not prove that the live payment account is configured, verified and paying out to the right bank account.
Payments, tax and delivery
- 01
Is the payment account live and verified?
Who confirmsFinance. Payouts reach the correct bank account, and the provider has finished its checks on the business.
- 02
Are taxes right for every region you sell to?
Who confirmsYour accountant. Prices shown with or without tax as required, and invoices containing what local rules demand.
- 03
Are delivery rates and zones right?
Who confirmsOperations. Test addresses in each zone, heavy and oversized items, free delivery thresholds and places you do not serve.
- 04
Do fraud and verification settings behave?
Who confirmsFinance and the payment provider. Genuine test orders pass, and extra verification works on phones.
- 05
Are currencies and rounding consistent?
Who confirmsFinance. The same total appears in the basket, the email, the payment and the accounts.
- 06
Do refunds and chargebacks have a process?
Who confirmsCustomer service and finance. Who may issue a refund, and up to what amount.
Emails, content and legal pages
- Every automatic message. Order confirmation, dispatch, delivery, refund, account creation, password reset, abandoned basket. Read each one on a phone, with real order data, in every language.
- Sender and delivery. Messages come from your domain, pass authentication checks and arrive in the inbox, not the spam folder, at the main email providers.
- Product content. A sample across every category checked for names, prices, images, variants and stock. Nothing left from the demonstration data.
- Legal pages. Terms of sale, privacy policy, returns and cancellation rights, delivery information and company details, reviewed by a legal adviser for the markets you sell in.
- Consent. Cookie notice and marketing opt-ins working as your privacy policy says, with tracking held back until consent where the law requires it.
- Error and empty states. The page for a missing address, an empty basket, an out-of-stock product and a failed search, each with a way forward.
Integrations, data and search visibility
- 01
Prove each integration with the live system
Orders arrive in the ERP, stock changes come back, shipping labels print, the email tool receives subscribers. Test against production connections, since test environments often differ.
- 02
Break each integration on purpose
Switch one off, place an order, switch it back. Nothing should be lost or duplicated, and someone should have been alerted.
- 03
Reconcile migrated data
Counts of products, customers and orders, gift card and credit balances, and a field-by-field sample.
- 04
Check redirects
Every old address leads to the right new page. Run the full list automatically.
- 05
Check what search engines will see
Titles, descriptions, structured product data, the sitemap, and that the settings which hide a store during development are removed at launch.
- 06
Check measurement
Analytics records a purchase once, with the right value, and advertising tags fire only after consent.
A worked example
Acceptance week at a cosmetics retailer
This example is invented to show what acceptance typically finds. A cosmetics retailer is a week from launching a rebuilt store.
- PlanTwenty-two order scenarios are agreed. Finance signs payments and tax, the warehouse signs fulfilment, marketing signs content and emails, the owner makes the final decision. Launch blockers are listed in advance.
- OrdersNineteen scenarios pass. A discount code combined with a sale item gives a total one cent different on the invoice. A bundle reduces stock of the bundle but not of its components. A partial refund does not reach the accounts.
- Live paymentA real order succeeds, but the first payout is pending because the provider is still verifying a director's identity. It is resolved three days before launch.
- EmailsDispatch emails land in spam at one major provider. The sending domain's authentication records were incomplete.
- DecisionThe bundle stock fault and the refund fault are blockers and are fixed and retested. The one-cent rounding difference is accepted in writing by finance for launch, with a fix scheduled.
The store launches a day later than planned, with one known issue on a signed list. Every fault found that week would otherwise have been found by a customer, the warehouse or the accountant.
Speed, accessibility, security and the team
Ready to open
- Key pages measured on a mid-range phone on mobile data
- Checkout completed by keyboard and with a screen reader
- Administrator accounts reviewed, with two-step sign-in
- Backups taken and a restore tested
- Staff trained on orders, refunds and stock, with written procedures
- Customer service briefed, with answers to likely questions
Not ready
- Tested only on the team's own laptops
- Developer and test accounts still active with full rights
- Nobody knows how to issue a refund
- No monitoring or alert if checkout fails
- Launch planned for the day before a major promotion
A load test is worthwhile if you expect a surge at launch or have a large mailing list. Otherwise, a quiet opening to a small audience for a few days does the same job with real customers and less risk.
The decision, launch day and the weeks after
Hold a short meeting where each owner reports pass, pass with listed issues or fail for their area. Known issues go on one list, each with a severity, an owner and a date. The person accountable for the business then decides. If a blocker is open, the launch moves. A store that opens a week late is forgotten in a month. A store that opens broken is remembered.
On launch day, follow a written sequence with named people: final data update, switch, redirects on, test order in the live store, monitoring confirmed. Keep the way back available for an agreed period. For the first weeks, review orders, payments, errors and customer messages every day, and keep the development team on hand. Our guide on planning an ecommerce replatforming project covers the cutover itself.
The acceptance checklist
Ecommerce launch acceptance checklist
0 of 11 checkedWhat to do next
Write your order scenarios now, whatever stage the build is at. Ask finance, the warehouse and customer service which orders cause them trouble today, and add those. The list is useful to the developers long before launch, because it tells them what finished means.
Automated tests can rerun many of these scenarios after every change, which our QA and test automation page describes. Tell us when you plan to launch if you would like an independent acceptance review.
Common questions
Who should sign off an ecommerce launch?
The business, area by area. Finance confirms payments, tax and accounting. Operations confirms fulfilment and stock. Marketing confirms content, emails and measurement. Customer service confirms it can support customers. One accountable person makes the final decision. The development company supports the testing and fixes faults. It should not be the one to declare its own work accepted.
How long should acceptance testing take?
Long enough to run every scenario, fix what fails and run those again. For most stores that means days, not hours, and it needs staff from finance and operations to be available. Plan the period into the schedule from the start. Acceptance squeezed into the final afternoon is a formality, and its faults surface after launch.
Can we launch with known issues?
Yes, if each is understood, minor and written down with an owner and a date, and nobody is surprised. Agree beforehand what counts as a blocker: anything that takes the wrong money, loses an order, misstates stock or breaks a legal requirement. Issues outside that list can be accepted knowingly by the person responsible for that area.
Is testing in the platform's test mode enough?
No. Test mode proves the logic. It does not prove that the live payment account is verified, that payouts reach your bank, that live tax and shipping settings match, or that production integrations are connected. Place at least one real order with a real card in the live store before opening, follow it through and refund it.
What should we watch in the first days after launch?
Orders arriving and reaching your order system, payment success rates, errors, emails being delivered, stock staying in step, search engine error reports and what customers tell your support team. Check daily, with the developers available to respond. Most launch problems show within the first week, and quick fixes then prevent lasting damage.
