A WooCommerce store in Brussels sits next to a D2C subscription box from Ixelles with EUR checkout and bpost delivery to an office on Avenue Louise, a B2B wholesaler from Anderlecht with role-based pricing and invoices carrying a BCE number, an event merch shop near Heysel that must survive a traffic spike in peak week without losing Mollie webhooks, or a Brussels Digital Hub brand on recurring billing through Stripe. That is not a reason to pretend Woo is a trade-association CRM or an EU institution booking system. It is a reason to write checkout, Bancontact and Mollie gateways, TVA/BTW, shipping and warehouse integrations the way a Belgian compliance team, a warehouse in the Brussels agglomeration or a legal department reading GDPR and APD guidance (Autorité de protection des données / Gegevensbeschermingsautoriteit) expects, not only the way a Lighthouse score on a category page looks.
WPPoland delivers WooCommerce development from a Polish senior team for businesses in Brussels and across Belgium. Scope covers checkout, Bancontact, Mollie, Stripe, PayPal, shipping zones, TVA/BTW tax logic, hooks instead of core edits, and end-to-end QA on order paths. WordPress theme work, care retainers and contact are separate topics, with links at the end.
#WooCommerce checkout in Brussels
Brussels is the capital of Belgium, home to EU institutions and a Brussels Digital Hub node that concentrates startups, agencies and tech firms across the agglomeration from Etterbeek to Saint-Gilles. The city combines the Schuman area with trade associations and law firms, Avenue Louise with service firms and SMEs, Ixelles with short D2C publication cycles, and the Heysel district where industry events and trade fairs generate traffic spikes on WooCommerce landings and stores. A store in this layout is often not a brochure with a cart but an event merch channel, a B2B catalogue for distributors, a digital product subscription or a membership campaign shop that must hit a Friday 23:59 deadline.
A brief from a client in Brussels often sounds like: we have Elementor and thirty plugins, checkout takes forever, Bancontact works randomly, and after a Woo update orders sit on pending. That is a checkout architecture and Mollie webhook problem, not a marketplace template problem. The typical project that reaches seniors in Brussels does not say build us a shop. It says: inherited Woo with a page builder, Mollie configured by an agency three years ago, the warehouse glues statuses manually after a Heysel event, and legal is asking whether the checkout consent checkbox and privacy policy can stand up to APD before quarterly report publication. That is integration debt surfacing in publication week or at conference registration deadline, not in an SEO audit.
WordPress Meetup Brussels meets regularly in the local ecosystem. That is not a sales channel. It is a signal that the community knows WordPress Coding Standards and can tell the difference between WooCommerce Blocks checkout and a page builder generating shortcodes in content. Stores we build or repair here usually combine two rhythms: daily B2C sales with bpost delivery across the Brussels agglomeration, and catalogue spikes before report publication, a membership campaign or an industry event when a warehouse in Belgium or fulfilment near Brussels must ship DPD or GLS parcels, not a registered bpost letter.
Work stays anchored to WooCommerce. Customisation goes through action and filter hooks and a custom plugin, never through core file edits. The boundary between Woo core, plugin code and theme is set at audit and lands in the runbook.
#Payments on checkout in Belgium in 2026
A Belgian cart starts with currency. A store in Brussels sells in EUR. Bancontact is the payment method most consumers in Belgium pick first: redirect to the bank (KBC, Belfius, ING Belgium, BNP Paribas Fortis), confirmation in the mobile app, return to the store with a paid status. WooCommerce supports Bancontact through Mollie, Stripe, MultiSafepay or Adyen. Integration requires correct webhook handling, idempotency on the store side and sandbox tests before production.
Mollie is a gateway buyers and finance teams in Brussels know from in-store terminals and monthly invoices. Stripe covers most international scenarios: card with 3D Secure, Apple Pay, Google Pay and the PayPal wallet. A client from the Brussels agglomeration expects the amount on checkout, in the confirmation email and on the bank statement to be in euros, with TVA/BTW shown explicitly.
For each gateway the runbook records: supported flows (one-shot, recurring, capture, full refund, partial refund), webhook URL, events that change status, sandbox account matrix and idempotency history. Mollie reports payment.paid and refund.created as separate events. Stripe needs an explicit decision on whether capture happens immediately or after the parcel ships. For bulky goods or personalised items the second option protects against charging for a SKU that is not in stock.
We order methods on checkout for Belgian habits: Bancontact at the top, PayPal and card through Mollie or Stripe below, Apple Pay where Safari dominates mobile traffic from an event campaign, bank transfer (overschrijving) only on a B2B path with a clear message about settlement time. A default Woo template with card first and no Bancontact works against Belgian market habits, including a buyer in Brussels who prefers a bank redirect on a cart above a few hundred euros.
Stores selling to other EU countries must separately solve VAT OSS or local registration in the destination country. Woo alone is not an OSS module. Either a tax plugin calculates destination rates, or the ERP is the tax source and Woo only collects address and amounts. Mixing both sources is the most common TVA/BTW declaration drift, and it surfaces on the invoice, not in the cart.
#Shipping zones: bpost, DPD and GLS
Domestic delivery from Belgium in 2026 is primarily bpost (Pacco, bpack 24h Pro), DPD and GLS. bpost handles parcels up to standard dimensions across the Brussels agglomeration. DPD offers door delivery and a ParcelShop network in Brussels: city centre, Anderlecht, Woluwe, Zaventem, Molenbeek. Woo zones split not only Belgium / EU / rest of world but weight and dimension: up to letter threshold, up to standard parcel, above that a pallet courier for event bulky goods or B2B materials.
Carrier integration maps Woo products to carrier services: bpost Pacco, DPD Classic, GLS Business Parcel. A carrier plugin does not add a separate method to the zone list. It attaches to an existing flat or free shipping rate, then maps products in API settings. Manually gluing bpost labels in the portal after order volume from a Heysel event does not scale.
The label and tracking number return to the Woo order and the customer email. Generating the label after payment_complete moves to Action Scheduler (as_enqueue_async_action) so the webhook handler returns 200 before the carrier API calculates routing. Local pickup in the agglomeration (warehouse in Anderlecht, point near Gare du Midi) gets its own method with a clear pickup address.
#TVA/BTW and the BCE field
TVA/BTW rates in Belgium in 2026: standard 21 percent, reduced 6 percent (for example part of food and books), intermediate 12 percent on selected categories. A mixed cart is daily reality for a B2B supplier near Anderlecht or a D2C shop selling an event catalogue alongside a gadget. Woo must calculate tax per line item, not take the highest cart rate. A product tax class error surfaces on the TVA/BTW invoice, not in the basket.
B2B within Belgium with a valid BCE/KBO number (TVA / BTW) goes as reverse charge or zero rate where law allows, provided the number passes VIES validation and the store records proof of the check on the order. A BCE field on checkout, validation and tax class switching is not form decoration. On overschrijving B2B payment that same field decides whether the invoice has any chance with finance in Brussels.
We record in the runbook what calculates tax and issues documents: WooCommerce Tax, a separate invoicing engine (Yuki, Exact Online, Billit, custom integration), or the client’s accounting system. One numbering source. Two sources produce duplicate numbers or gaps, and a tax audit does not forgive that.
#Webhooks, stock reservation and HPOS
The most common defect in stores that return for repair in Brussels is not checkout appearance. It is what happens after the customer clicks Betaal met Bancontact or Plaats bestelling. A store with inventory in Belgium selling in parallel through its own Woo and through a marketplace pays twice for that mistake: once with an order in limbo, again with overselling a SKU already reserved in the second channel.
#Order status is set by the server, not the browser return
Order status is set by server-to-server notification. The customer return to the thank-you page is not the source of truth. The order-received endpoint is a browser event. Browsers are unreliable: after Bancontact authorisation the customer closes the tab on a tram between Schuman and Gare Centrale, loses signal in an airport parking garage, returns from cache. The woocommerce_thankyou hook displays content. It does not change payment status.
Money is decided by the gateway callback. In Woo a custom return URL with the wc-api parameter receives it, an action in the woocommerce_api_ family registered by the gateway plugin. After signature verification the handler calls payment_complete on the order object and moves it from pending to processing. We verify the signature on the raw request body from php://input before anything is parsed. Heavier work after verification (inventory sync, invoice issue, bpost or DPD dispatch) moves to Action Scheduler so the 200 response returns quickly and Mollie or Stripe do not start retrying.
A repeated gateway signal is normal, not a failure. We store the event identifier in order meta and check before processing. An already paid order does not change status a second time. It gets a note about an ignored duplicate.
Declined payment and partial refund are two separate paths. Decline sets status failed, not cancelled, because the order should still be payable: the customer gets a link from get_checkout_payment_url. Partial refund goes through wc_create_refund with line items and amounts plus a gateway refund flag. The order stays in processing or completed, and refunded amount is read from get_total_refunded, not from status.
#Inventory reservation and multichannel sales
We reserve stock when payment starts, not after confirmation. WooCommerce from version 4.3 stores reservation in wp_wc_reserved_stock through wc_reserve_stock_for_order, releases it through wc_release_stock_for_order, and takes hold time from woocommerce_hold_stock_minutes. Without that, two buyers enter Bancontact on the last unit of a limited SKU from a collection before an industry event and both get confirmation.
On multichannel sales Woo reservation knows nothing about Bol.com, Amazon or another channel. The source of truth becomes a shared pool in ERP or a fulfilment layer, and Woo holds stock through sync. Hold stock on overschrijving B2B payment is set longer than on Bancontact: a bank transfer can land the next business day.
#wp_wc_orders tables and compatibility mode
High-Performance Order Storage is default for new installations from WooCommerce 8.2. Orders then live in wp_wc_orders, wp_wc_order_addresses, wp_wc_order_operational_data and wp_wc_orders_meta, not as shop_order posts in wp_posts. Older stores switch deliberately: compatibility mode first, then HPOS as authoritative storage, then dual-write off when reports and plugins stop diverging.
Diagnostics and reports go through wc_get_orders and OrderUtil, not SQL on wp_posts. A plugin that in 2026 still finds orders only in postmeta shows empty lists on HPOS and loses refunds. Official Mollie, Stripe, PayPal, bpost and DPD have been HPOS-ready for years. The problem is old warehouse connectors and custom crons.
#GDPR, APD and forms in the Belgian context
Belgium applies EU Regulation 2016/679 (GDPR) together with the Act of 30 July 2018 on the protection of natural data subjects with regard to the processing of personal data. The supervisory authority is APD (Autorité de protection des données in French, Gegevensbeschermingsautoriteit in Dutch). For a WooCommerce store in Brussels that is not an abstract legal paragraph. It is decisions in forms, consent plugins, privacy policy and audit logs.
What we put in the brief and in code:
- Forms collecting personal data (customer account, newsletter, B2B enquiries, checkout with account creation) get an explicit legal basis, a consent checkbox where consent is required, and field minimisation. Fields you do not need for the form purpose do not exist.
- Consent plugins (Cookiebot, Complianz, Didomi, popular in Belgium) are configured so marketing scripts do not load before acceptance. APD guidance requires informed consent before non-essential cookies. That is a theme and enqueue-order decision, not a care ticket after the first supervisory-authority report.
- Privacy policy and cookie policy are templates with protected fields, not blocks an editor can delete from the tree. In Brussels those pages are compliance assets, not marketing footnotes.
- CRM integrations (HubSpot, Salesforce, Pipedrive) get data-flow documentation: what reaches the external system, how long, who is controller. DPAs are the client’s decision, but Woo configuration must enable that decision.
- Audit logs for forms and admin changes help during incidents. If someone asks who changed checkout form settings on Friday before report publication, the answer cannot be we do not know.
We do not promise GDPR compliance without a process owner on the client side. We do not file a report to APD on the client’s behalf. We promise technical configuration the owner can describe in documentation and include in a 72-hour breach notification when procedure requires it. APD publishes guidance and audit tools at autoriteprotectiondonnees.be; the checkout runbook should align on what the agency documents versus what stays with the data controller.
#Hosting in the EU
Personal data under GDPR raises jurisdiction: where the server stands. Combell in Belgium, OVH in France, Hetzner in Germany, AWS in Frankfurt (eu-central-1) are different answers for a compliance officer, but all sit in the EU. Ashburn or Hillsboro is the United States and usually a veto without Standard Contractual Clauses or another transfer basis.
The question whether hosting is in Brussels comes up less often than whether it is in the EU. The operational answer has two parts. Jurisdiction: EU, backups do not slip to a US bucket overnight without agreement. Latency: origin in Belgium or Frankfurt plus CDN with TLS termination in the EU usually suffices for users in Belgium and Central Europe. Brussels has data centres in the agglomeration, but WordPress origin often still sits with a provider in the Frankfurt or Paris region. That is not a defect. It is an explicit residency decision documented in the runbook.
#Returns and consumer law as store operations
The following paragraphs describe store consequences. They are not legal advice. Terms and conditions, privacy policy and return policy texts are approved by counsel or the responsible person in the company. Woo’s job is to connect that text to the cart, the button, the email and the warehouse.
A consumer in Belgium has the right to withdraw from a distance contract within 14 days under Belgian consumer law (Wetboek van economisch recht, Boek VI). The period starts when the customer received the goods. For a warehouse in the Brussels agglomeration that is not legal trivia. It is an SKU you cannot sell again because it may return three quarters later.
The operational path we build:
- The customer submits a return with order number or data that lets you find it in
wp_wc_orders. - The store sets RMA status, sends confirmation and a bpost or DPD return label or dispatch instructions.
- Warehouse receipt releases the SKU block and only then triggers
wc_create_refund on Mollie, Stripe, PayPal or a bank transfer on overschrijving. - Partial return (one of three lines) does not close the whole order and does not refund shipping blindly; amounts come from line items, not a manual refund everything.
- Non-returnable goods (hygiene, personalisation, digital content after access started) must state that at the SKU before purchase.
Post-holiday season and post-event weeks test this path. A store that manually clicks refunds in the Mollie panel during report publication week and fixes stock in Excel drifts TVA/BTW reporting and oversells returning goods.
#Catalogue and checkout around report publication and Heysel events
Quarterly report publication, industry event registration near Heysel and Black Friday are three calendar points you cannot ignore in a brief from a client in Brussels. In those windows site traffic multiplies, newsletters go out in hundreds of thousands, and every production change is risk. That is why the runbook records a deployment freeze: in report publication week no plugin updates, no new blocks, no theme changes. Staging gets changes; production waits until a few days after the peak.
A catalogue that carries eight hundred SKUs for eleven months gets a limited-edition layer before season: bundles, prices valid until stock runs out, variants not in the standing offer. Woo must carry that without killing the category page.
A new checkout architecture, HPOS switch or bpost and DPD zone remap does not go to production in a seasonal window. A small SEO change the week before report publication can overwrite robots, drop a collection landing from the index or break cache on a promo page.
Variants are real variations with their own SKU, weight and tax class, not a text field type your colour. A large matrix (size × colour × material for B2B parts) gets its own queries and fragment cache.
Pre-order before a product line launch: SKU is visible, payment is taken, but fulfilment waits until date. on-hold or a custom awaiting-stock status must block the carrier label. Otherwise the bpost plugin dispatches an empty parcel to a Pacco point near the station.
Net / gross pricing on B2B checkout (net plus TVA/BTW) and B2C checkout (gross) are two templates, not a CSS toggle. A buyer with a BCE number in Brussels expects net. A consumer in the agglomeration expects gross.
#Brussels as market context, not a title decoration
Brussels Digital Hub is not just a name in the footer. It is dozens of startups, creative agencies and SaaS firms across the agglomeration from Etterbeek to Saint-Gilles. Merch shops, D2C box subscriptions and B2B platforms for distributors often start on WooCommerce because they go live fast, then stall on checkout and compliance. A checkout outage or wp-admin log leak is not a marketing problem. It is a compliance problem and often a lawyer conversation before APD.
The Schuman, Berlaymont and European Quarter areas carry a different brief profile. Trade associations, law firms, consultancies and think tanks must handle publications in FR and NL (sometimes EN and DE), conference registration forms and regulatory content with effective dates. An event merch shop or member portal with checkout must survive a 23:59 Friday deadline without a Monday-morning operational incident.
Avenue Louise, Place du Châtelain and the Flagey area are a third pillar. Service firms, creative agencies and SMEs with shorter publication cycles. They have smaller infrastructure budgets than a corporation near the institutions, but the same risk profile: a hacked site or a form sending data without legal basis damages reputation faster than slow LCP. Belgium requires a BCE/KBO number in the footer and often bilingual FR/NL content. Checkout tested only in French does not catch regressions in Dutch.
Heysel events and Brussels Expo are a fourth pillar. Merch producers, event equipment suppliers and industry material vendors publish product catalogues, material configurators, booth meeting sign-ups and landings for a specific trade fair edition. Traffic spikes in event week are a real failure profile that needs cache, CDN and staging with rollback written before deploy.
The typical brief that reaches seniors in Brussels does not say make a pretty shop. It says: inherited Woo with thirty plugins, checkout losing Mollie webhooks, warehouse in Belgium synced manually from Excel, finance waiting for export to Exact Online, and quarterly report publication starts next week. That is a checkout, webhook and HPOS problem, not a marketplace template problem.
#Subscriptions, B2B and WooCommerce Blocks
We see WooCommerce Subscriptions in Brussels on D2C boxes, digital product subscriptions or B2B plans billed cyclically through Stripe. A subscription needs its own runbook: payment retry, grace period, cancellation, plan upgrade, CRM sync. Stripe webhook invoice.payment_failed must reach Woo and change subscription status, not only send an email.
B2B in Brussels is role-based pricing, minimum order quantities, quote workflows and dedicated account portals. WooCommerce B2B or a custom role layer must work with the BCE number and overschrijving payment. A B2B portal showing net prices without role validation is a wholesale price list leak on the public front.
WooCommerce Blocks Checkout makes sense when checkout must stay light and not drag the entire page builder. Checkout blocks render server-side where possible. Mollie, Stripe and bpost Location Finder scripts load when checkout is on screen, with preconnect to their domains, not in the footer of every category page.
Checkout is dynamic. Full page cache on cart and checkout serves someone else’s cart or an empty mini-cart fragment. The cache layer (Redis, Cloudflare) bypasses those paths or uses segmentation. Mini-cart fragments are calculated separately.
Catalogue images go in AVIF / WebP with srcset. Event campaigns generate heavy JPEGs from the booth; without processing, LCP on the product card drops before the buyer sees the Bancontact button. Query Monitor on staging shows whether the carrier plugin and gateway add N queries on every cart request.
Measurement: Lighthouse and field data on product, category and checkout URLs, before and after. Report publication or a Heysel event is an infrastructure test, not a quarterly average. Monitoring from a single US region lies when visitors queue at a booth in central Brussels. A measurement point in the EU is part of acceptance criteria.
Core Web Vitals affect Google ranking and conversion on a page collecting orders in campaign peak. We do not promise a specific percentage delta before audit, because improvement scale depends on the starting state of that installation. Performance budgets are set at project start and verified on field data from CrUX reports, not laboratory measurement alone.
#Scope, QA and handover
Entry audit covers: taxonomy and TVA/BTW tax classes, Bancontact, Mollie and Stripe payment order, bpost and DPD zones, HPOS and plugins reading orders, webhooks, hold stock, return path, export to Exact Online or the accounting system, Lighthouse baseline, report publication and Heysel event calendar in the release schedule, GDPR configuration and cookie consent under APD. At this stage we decide what is the source of truth for stock, tax and document number.
Implementation goes in feature branches. Each gateway has a sandbox scenario: Mollie test mode, Stripe test mode, PayPal sandbox, Apple Pay in test environment. bpost and DPD have label test environments. Final QA ends with an order that passes: mixed cart with TVA/BTW rates, bpost Pacco point, webhook, order note, label, email, then partial refund on the same gateway.
Handover is gateway runbooks, zone map, store-side return description, accounting export instructions and HPOS decision record. Pricing is individual and in writing before start. Scope changes are discussed with timeline consequence. We do not publish an SKU price list on this page.
#When this page, and when care or WordPress development
This page stays with the shop: catalogue, checkout, payment, shipping, stock, document, return. Blog theme, Gutenberg, intranet or a corporate site at Brussels Digital Hub are not the topic here. That is WordPress developer in Brussels. Monitoring, core updates and backups without checkout rebuild are WordPress maintenance and support in Brussels. Broader care without a city: WordPress maintenance. The shared e-commerce pillar: WooCommerce developer.
Brussels Digital Hub, the Schuman area and Avenue Louise explain where B2B shops with a BCE number and overschrijving payment come from. They do not explain why a Mollie webhook without idempotency leaves an order pending after report publication.
#Start your WooCommerce project in Brussels
For contact a short summary is enough: whether the shop already exists, which gateways are active (Bancontact, Mollie, Stripe, PayPal), where shipping runs from (bpost, DPD, pickup in the Brussels agglomeration), whether HPOS is enabled, what the warehouse looks like (Brussels, 3PL, regional HQ), whether finance waits for export to Exact Online, whether cookie consent blocks tags before approval, and which report publication or Heysel event dates block release. From that we can see whether checkout rebuild, webhook and stock wiring, or a narrower fix is needed.
WPPoland works on WooCommerce from the order side, not from the slide deck. Businesses in Brussels get the same engineering rigour as any other store, with the stack Belgian buyers actually use and a report publication and industry event calendar written into the release schedule.