The BFCM Checkout Readiness Checklist for Shopify

Checkout is the only part of a store where a fault costs you the entire order rather than degrading the experience. Everywhere else, a problem loses you some conversion at the margin. Here it loses you the transaction outright, and during BFCM it loses you the transaction at the moment you have paid the most to acquire it.

Black Friday 2026 falls on Friday 27 November, with Cyber Week running to 3 December. Working backwards from that, checkout work wants to be finished and frozen by mid-November.

Stop worrying about traffic

The most common BFCM anxiety is capacity, and for a Shopify merchant it is largely misplaced. Platform infrastructure handling peak load is Shopify's problem, and it is one they have solved at a scale no individual merchant approaches.

What actually fails during peak is merchant-controlled:

• Discount logic behaving in ways nobody tested, at a volume that surfaces every edge case at once.
• Apps timing out or degrading, particularly ones making synchronous third-party calls during checkout.
• Third-party scripts slowing pages precisely when conversion is most valuable.
• Inventory overselling, especially where bundles or gifts decrement stock nobody was forecasting.

Every item on that list is yours. That is good news, because it means preparation actually helps — none of these are things you can only hope go well, and each one can be verified in advance by someone willing to sit down and test it properly.

Discount logic is where BFCM breaks

If you fix one thing on this page, fix this.

Offers are built one at a time, over several weeks, each by someone thinking about that offer alone. They then meet each other in a real cart, alongside the discount code you emailed subscribers in October and forgot about, and a customer who has been carrying an abandoned cart since before any of it went live.

The failure modes are consistent and all bad:

The test is dull and non-negotiable. List every discount that could be simultaneously active, including codes already in circulation. Then walk the actual customer path for each combination, on a real device. Anything you cannot make behave correctly should be made explicitly non-combinable rather than left to resolve itself at checkout under load.

Test the accelerated checkouts specifically

Shop Pay, Apple Pay, Google Pay and the other wallet buttons take a meaningful and growing share of orders, and they do not behave like the standard flow. They compress or skip steps, which means anything depending on a skipped step is invisible to a shopper using one.

The practical consequences:

Discount codes need a field. Automatic discounts apply at the platform level and survive. Codes require the shopper to type them somewhere, and accelerated buttons frequently bypass that. A BFCM campaign built entirely on a code will structurally fail for a portion of your traffic.

Cart-manipulating apps get bypassed. Any app achieving its behaviour by rewriting the cart rather than through Shopify Functions may simply not run. This is the single strongest practical argument for Functions-based discount logic.

Upsells positioned in the cart are skipped. If your AOV plan depends on a cart-page upsell, wallet-button shoppers never see it.

Test a complete purchase through each accelerated method you have enabled, with your actual offers active. Not the standard flow with the button visible — an actual completed order.

The failed payment case is skipped almost universally and matters more during BFCM than at any other time, because card declines rise sharply when people are spending unusually, hitting limits they do not normally approach. A shopper whose first card is refused will try a second one if the path back is obvious, and will leave if it is not.

Audit apps in October, not November

Every app touching cart or checkout is a dependency and a page-weight cost. Both matter more at peak.

The audit is straightforward: open a product page and the cart in DevTools, look at what third parties load, and ask of each one whether it is currently earning more than it costs. Apps trialled and abandoned are the easiest wins, and most stores have several — an uninstalled app frequently leaves its theme snippet behind and continues loading.

Do this in October. Removing something load-bearing days before peak creates precisely the risk you are trying to eliminate, and there is no time to observe the consequences.

Inventory and the quiet oversell

Checkout and inventory meet in a way that only becomes visible at BFCM volume, and the failure is expensive because it happens after you have taken the money.

Ordinary selling decrements stock predictably. BFCM offer mechanics do not. A free gift consumes stock of a product whose demand is driven by sales of something else entirely. A bundle can draw down a component that is also sold separately, from two directions at once. A buy-X-get-Y drains a variant nobody is watching because it was never the product being promoted.

Three things worth settling before the weekend:

Decide what happens when a gift runs out. The options are that the offer stops applying, that it substitutes, or that it oversells. All three are defensible; discovering which one your setup does at 2am on Black Friday is not. Set a stock alert on every gift and bundle component.

Check overselling settings deliberately. Continue-selling-when-out-of-stock is right for some products and catastrophic for others. During BFCM the volume compresses weeks of ordering into hours, so a setting that was harmless all year can produce hundreds of unfulfillable orders before anyone notices.

Reserve stock for the offers you have advertised. If an offer is the centrepiece of a campaign, the inventory backing it should not also be freely sellable through every other route.

The week itself

Preparation is most of it, but a few things belong to the days themselves.

Watch order-level margin, not just revenue. Revenue during BFCM looks good almost regardless. The number that reveals a discount logic problem is what you earned per order, and a sharp move there is the earliest signal something is applying that should not be.

Monitor the proportion of orders receiving each offer. If an offer that applied to 30% of orders on Friday applies to 3% on Saturday, something changed and nobody was told.

Keep a rollback path. Know how to disable each offer quickly and who has access to do it. During peak, the correct response to a misbehaving discount is usually to turn it off, not to debug it live.

Write down what broke, while it is happening. Peak weekends generate a dozen small discoveries that everyone is certain they will remember and nobody does. A running note costs nothing and is the entire basis of next year's preparation, which otherwise restarts from memory and repeats the same faults.

Have someone actually watching. Automated alerting is better than nothing, but the failures that hurt most are the silent ones that no alert is configured for. A person placing a test order twice a day catches things monitoring does not.

For offer structure and the margin arithmetic behind it, see the BFCM 2026 series. Checkout mechanics beyond peak season are covered in checkout and payments, and the discount implementation detail in promotions and offers.