What Breaks When You Build a WooCommerce Store Stripe Won’t Process
Most WooCommerce builds follow the same sequence. Theme, products, shipping, then payments at the end, because payments are the easy bit. Install the Stripe plugin, connect the account, take a test order, done.
That sequence works for perhaps ninety percent of stores. For the rest, payments are not the last decision. They are the first one, and building in the usual order means discovering a structural problem after the site is finished.
Stripe publishes a restricted businesses list. So does PayPal. Between them they cover a wider range of ordinary commercial activity than most developers assume: prize draws and competitions, certain supplement categories, some CBD products, ticket resale, debt collection services, and a long tail of things that look completely normal from the outside. Shopify’s acceptable use policy is stricter still in places, which is why some UK sellers end up on WooCommerce by elimination rather than preference.
If you build for a client in one of those categories and only find out at launch, you have not built the wrong site. You have built a site that cannot take money.
The restriction is enforced after you launch, not before
This is the part that catches people. Nothing stops you connecting a Stripe account and processing test transactions. The account works. The plugin works. Orders come through.
Then transaction monitoring identifies the business category, and the account closes. Sometimes that happens in week one. Sometimes it happens six months in, during a busy trading period, with a balance held pending review. The client’s cash is frozen and they are ringing you, because you built the site.
Specialist providers exist for exactly this reason. In the UK, Cashflows is the common route for prize competitions and several other categories mainstream processors decline. Onboarding is slower than clicking connect. Expect three to ten working days with complete documentation, a setup fee somewhere between £200 and £500, per-transaction rates in the 1.4 to 2.5 percent range rather than Stripe’s headline pricing, and in many cases a rolling reserve of five to ten percent of monthly revenue held for three to six months.
None of that is a problem. It is just a different set of facts to design around, and it needs to be known before the build starts rather than after.
The gateway assesses the website, not just the company
Here is the detail that turns a payments problem into a development problem. Specialist acquirers review the live site as part of onboarding. Not the company registration, not the director ID, the actual pages.
For a UK prize competition site that means they are checking for a genuine skill question in the entry flow, a free postal entry route displayed at equal prominence to the paid route, competition-specific terms rather than a generic template, a visible privacy policy, published draw dates, and a winners page with real results on it.
Miss any of those and the application is delayed or declined. The merchant application is effectively a code review conducted by someone who does not write code.
That reverses the usual build order. Compliance pages stop being content the client will “send over later” and become a hard dependency for go-live. In practice the sequence that works is: confirm the category, introduce the client to a provider that accepts it, then build the site to that provider’s requirements while onboarding runs in parallel. Payment approval and development finish at roughly the same time instead of one blocking the other.
Three things that break at the plugin layer
Assuming you have the gateway sorted, standard WooCommerce still leaves gaps in restricted categories. Prize competitions are a useful worked example because the gaps are unusually clear.
Entry gating. A paid entry has to pass a skill question before it can be added to the basket or before checkout completes. There is no core WooCommerce concept for a purchase that is conditional on a correct answer. You either build it or you find something that already has it.
Allocation and caps. Competitions sell a fixed number of tickets with a hard close date, often with per-customer limits and bundle pricing that is not a simple quantity discount. Stock management gets you part of the way. It does not handle the close date, the sold-out state, or reconciling free postal entries into the same draw pool as paid ones.
Parallel entry routes. Under Section 339 of the Gambling Act 2005, a free entry route has to sit alongside the paid route with equal visual prominence and identical odds. That is a layout requirement enforced by law, on a template that also has to work at 390 pixels wide. It is not something a product page template anticipates.
Add draw execution with an auditable record, entry list publication, and winner announcement pages, and you are some distance past what plugins and a theme will cover.
Hosting is the second thing that fails
Restricted categories often come with unusual traffic profiles, and competitions have one of the sharpest. Load concentrates into the final hour before a draw closes, sometimes at ten times normal volume, and it lands on the least cacheable pages in the build: basket, checkout, and a ticket counter that has to be accurate in real time.
Shared hosting handles that badly. The site does not degrade gracefully, it falls over at the exact moment revenue is arriving, and the client loses both the sale and the trust. Budget for VPS or cloud hosting with server-side caching and a CDN, in the region of £99 a month for a site doing real volume, and treat the checkout path as the thing you load-test rather than the homepage.
What this means for how you scope the work
The practical change is small and it happens at the start of the project.
Ask what the client actually sells, in the terms a payment processor would use rather than the terms marketing uses. Check it against the restricted lists for Stripe, PayPal and Shopify Payments. If it appears, tell the client before you quote, because the project now includes gateway introduction, compliance page structure and probably a legal opinion letter, and none of that is in a standard build price.
Specialist studios have emerged in the categories where this recurs, which is the honest signal that the problem is structural rather than occasional. Nera Marketing works almost entirely on UK competition and prize draw platforms built on WordPress and WooCommerce, and prices bespoke builds from £2,995 with payment approval and compliance architecture handled as part of the engagement rather than as a variation. Whether you take that route or build it yourself, the useful thing is knowing the work exists.
WooCommerce is a good fit for restricted categories, mostly because the alternatives are worse. It is open enough to accommodate a non-standard entry flow, it works with gateways that hosted platforms will not integrate, and the client owns it outright.
It just needs the payment question answered first. Everything downstream depends on it, and it is the one decision that gets expensive to reverse.
- Author
- Latest Posts
Earn Money by Referring People
Refer customers to us with your affiliate link and earn commission on sales from your link.
US Servers with 24/7 North American Support
No comments yet