We are not just a remote agency. We are an active part of the ecosystem. We believe in Open Source and contributing back to the community that powers over 40% of the web (W3Techs).
In Antwerp's competitive market, site speed is your strongest SEO asset. Our Astro + Headless WP stack delivers performance that leaves competitors behind.
For businesses in Antwerp serving Local SMB and Enterprise, data security is paramount. Headless architecture virtually eliminates standard WordPress attack vectors.
A WooCommerce store in Antwerp sits next to a fashion brand on Meir launching a seasonal collection with EUR checkout and bpost delivery to a Pacco point near Centraal Station, a logistics operator near the Port of Antwerp-Bruges selling spare parts with role-based B2B pricing and invoices carrying a BCE number, a D2C subscription box from Eilandje on recurring billing through Stripe, or a merch shop for an industry event that must survive a traffic spike in peak week without losing Mollie webhooks. That is not a reason to pretend Woo is a TMS or a global OTA booking platform. It is a reason to write checkout, Bancontact and Mollie gateways, BTW/TVA, shipping and warehouse integrations the way a Belgian compliance team, a warehouse in Flanders 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 Antwerp and across Belgium. Scope covers checkout, Bancontact, Mollie, Stripe, PayPal, shipping zones, BTW/TVA 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.
Antwerp is Belgium’s second-largest city, a European logistics hub with the Port of Antwerp-Bruges and home to Antwerp Digital Hub, which concentrates startups, agencies and tech companies from Eilandje to Berchem. This is not institutional Brussels or university Ghent. A brief from a client in Antwerp sounds different: less about FR/NL/DE trilingualism on a single page, more about Dutch as the first locale, forms collecting data under Belgian GDPR, and a store that survives a fashion season opening or port campaign deadline without failing on a Friday evening.
Meir, Nationalestraat and the area around ModeMuseum are a different brief profile than Eilandje and the port. Fashion brands, boutiques and SMEs sit here with a shorter publishing cycle. They have smaller infrastructure budgets than a port corporation, but the same risk: a hacked checkout or a form sending data without legal basis damages reputation faster than slow LCP. Belgium requires a BCE/KBO number in the footer. In Flanders Dutch dominates, so the NL version is often first, not an add-on to French. Development that tests only the English version does not see regressions in Dutch.
A brief from a client in Antwerp 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 Antwerp 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 fashion season opening, and legal is asking whether the checkout consent checkbox and privacy policy can stand up to APD before the next collection launch. That is integration debt surfacing in publication week, not in an SEO audit.
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.
A Belgian cart starts with currency. A store in Antwerp 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 Antwerp 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 Antwerp agglomeration expects the amount on checkout, in the confirmation email and on the bank statement to be in euros, with BTW/TVA 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 a fashion 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 Antwerp 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 BTW/TVA declaration drift, and it surfaces on the invoice, not in the cart.
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 Antwerp agglomeration. DPD offers door delivery and a ParcelShop network in Antwerp: city centre, Borgerhout, Wilrijk, Merksem, Hoboken. 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 fashion season opening 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 near the port, point near Centraal Station) gets its own method with a clear pickup address.
BTW/TVA 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 the port or a D2C shop selling a fashion catalogue alongside accessories. Woo must calculate tax per line item, not take the highest cart rate. A product tax class error surfaces on the BTW/TVA invoice, not in the basket.
B2B within Belgium with a valid BCE/KBO number (BTW / TVA) 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 Antwerp.
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.
The most common defect in stores that return for repair in Antwerp 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 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 Meir and Centraal Station, loses signal in a 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.
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 fashion season opening 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.
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.
Belgium applies EU Regulation 2016/679 (GDPR) together with the Act of 30 July 2018 on the protection of natural persons 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 Antwerp 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:
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.
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 Antwerp 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 Flanders. NL and EN versions get separate slugs, hreflang and a regression checklist after every major theme or WPML plugin change. For Flemish companies the Dutch version is often first, English second, French third. Order affects the regression checklist and menu structure.
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 Antwerp 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:
wp_wc_orders.wc_create_refund on Mollie, Stripe, PayPal or a bank transfer on overschrijving.Post-holiday season and post-event weeks test this path. A store that manually clicks refunds in the Mollie panel during fashion season opening week and fixes stock in Excel drifts BTW/TVA reporting and oversells returning goods.
Fashion season opening, port campaign publication and Black Friday are three calendar points you cannot ignore in a brief from a client in Antwerp. In those windows site traffic multiplies, newsletters go out in large volumes, and every production change is risk. That is why the runbook records a deployment freeze: in fashion season opening 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 fashion season opening 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 BTW/TVA) and B2C checkout (gross) are two templates, not a CSS toggle. A buyer with a BCE number in Antwerp expects net. A consumer in the agglomeration expects gross.
Antwerp Digital Hub is not just a name in the footer. It is dozens of startups, creative agencies and SaaS firms across the agglomeration from Eilandje to Berchem. 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.
Meir, Nationalestraat and ModeMuseum carry a different brief profile. Fashion brands, boutiques and SMEs with shorter publication cycles. They have smaller infrastructure budgets than a port corporation, but the same risk profile: a hacked site or a form sending data without legal basis damages reputation faster than slow LCP. Checkout tested only in English does not catch regressions in Dutch.
The Port of Antwerp-Bruges and Eilandje are a third pillar. Logistics operators, spare parts suppliers and industrial material vendors publish product catalogues, material configurators and landings for a specific service line. Traffic spikes during port campaign week are a real failure profile that needs cache, CDN and staging with rollback written before deploy.
The typical brief that reaches seniors in Antwerp 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 fashion season opening starts next week. That is a checkout, webhook and HPOS problem, not a marketplace template problem.
We see WooCommerce Subscriptions in Antwerp 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 Antwerp 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. Fashion campaigns generate heavy JPEGs from the lookbook; 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. Fashion season opening or a port campaign is an infrastructure test, not a quarterly average. Monitoring from a single US region lies when visitors browse from Flanders. 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.
Entry audit covers: taxonomy and BTW/TVA 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, fashion season and port campaign 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 BTW/TVA 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.
This page stays with the shop: catalogue, checkout, payment, shipping, stock, document, return. Blog theme, Gutenberg, intranet or a corporate site at Antwerp Digital Hub are not the topic here. That is WordPress developer in Antwerp. Monitoring, core updates and backups without checkout rebuild are WordPress maintenance and support in Antwerp. Broader care without a city: WordPress maintenance. The shared e-commerce pillar: WooCommerce developer.
Antwerp Digital Hub, Meir and the Port of Antwerp-Bruges 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 fashion season opening.
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 Antwerp agglomeration), whether HPOS is enabled, what the warehouse looks like (Antwerp, 3PL, regional HQ), whether finance waits for export to Exact Online, whether cookie consent blocks tags before approval, and which fashion season or port campaign 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 Antwerp get the same engineering rigour as any other store, with the stack Belgian buyers actually use and a fashion season and port campaign calendar written into the release schedule.
We serve clients in Antwerp and nearby areas.
This page features specific insights for Antwerp.
A WooCommerce store in Antwerp sits next to a fashion brand on Meir launching a seasonal collection with EUR checkout and bpost delivery to a Pacco point near Centraal Station, a logistics operator near the Port of Antwerp-Bruges selling spare parts with role-based B2B pricing and invoices carrying a BCE number, a D2C subscription box from Eilandje on recurring billing through Stripe, or a merch shop for an industry event that must survive a traffic spike in peak week without losing Mollie webhooks. That is not a reason to pretend Woo is a TMS or a global OTA booking platform. It is a reason to write checkout, Bancontact and Mollie gateways, BTW/TVA, shipping and warehouse integrations the way a Belgian compliance team, a warehouse in Flanders 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 Antwerp and across Belgium. Scope covers checkout, Bancontact, Mollie, Stripe, PayPal, shipping zones, BTW/TVA 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.
Antwerp is Belgium’s second-largest city, a European logistics hub with the Port of Antwerp-Bruges and home to Antwerp Digital Hub, which concentrates startups, agencies and tech companies from Eilandje to Berchem. This is not institutional Brussels or university Ghent. A brief from a client in Antwerp sounds different: less about FR/NL/DE trilingualism on a single page, more about Dutch as the first locale, forms collecting data under Belgian GDPR, and a store that survives a fashion season opening or port campaign deadline without failing on a Friday evening.
Meir, Nationalestraat and the area around ModeMuseum are a different brief profile than Eilandje and the port. Fashion brands, boutiques and SMEs sit here with a shorter publishing cycle. They have smaller infrastructure budgets than a port corporation, but the same risk: a hacked checkout or a form sending data without legal basis damages reputation faster than slow LCP. Belgium requires a BCE/KBO number in the footer. In Flanders Dutch dominates, so the NL version is often first, not an add-on to French. Development that tests only the English version does not see regressions in Dutch.
A brief from a client in Antwerp 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 Antwerp 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 fashion season opening, and legal is asking whether the checkout consent checkbox and privacy policy can stand up to APD before the next collection launch. That is integration debt surfacing in publication week, not in an SEO audit.
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.
A Belgian cart starts with currency. A store in Antwerp 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 Antwerp 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 Antwerp agglomeration expects the amount on checkout, in the confirmation email and on the bank statement to be in euros, with BTW/TVA 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 a fashion 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 Antwerp 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 BTW/TVA declaration drift, and it surfaces on the invoice, not in the cart.
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 Antwerp agglomeration. DPD offers door delivery and a ParcelShop network in Antwerp: city centre, Borgerhout, Wilrijk, Merksem, Hoboken. 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 fashion season opening 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 near the port, point near Centraal Station) gets its own method with a clear pickup address.
BTW/TVA 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 the port or a D2C shop selling a fashion catalogue alongside accessories. Woo must calculate tax per line item, not take the highest cart rate. A product tax class error surfaces on the BTW/TVA invoice, not in the basket.
B2B within Belgium with a valid BCE/KBO number (BTW / TVA) 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 Antwerp.
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.
The most common defect in stores that return for repair in Antwerp 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 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 Meir and Centraal Station, loses signal in a 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.
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 fashion season opening 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.
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.
Belgium applies EU Regulation 2016/679 (GDPR) together with the Act of 30 July 2018 on the protection of natural persons 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 Antwerp 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:
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.
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 Antwerp 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 Flanders. NL and EN versions get separate slugs, hreflang and a regression checklist after every major theme or WPML plugin change. For Flemish companies the Dutch version is often first, English second, French third. Order affects the regression checklist and menu structure.
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 Antwerp 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:
wp_wc_orders.wc_create_refund on Mollie, Stripe, PayPal or a bank transfer on overschrijving.Post-holiday season and post-event weeks test this path. A store that manually clicks refunds in the Mollie panel during fashion season opening week and fixes stock in Excel drifts BTW/TVA reporting and oversells returning goods.
Fashion season opening, port campaign publication and Black Friday are three calendar points you cannot ignore in a brief from a client in Antwerp. In those windows site traffic multiplies, newsletters go out in large volumes, and every production change is risk. That is why the runbook records a deployment freeze: in fashion season opening 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 fashion season opening 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 BTW/TVA) and B2C checkout (gross) are two templates, not a CSS toggle. A buyer with a BCE number in Antwerp expects net. A consumer in the agglomeration expects gross.
Antwerp Digital Hub is not just a name in the footer. It is dozens of startups, creative agencies and SaaS firms across the agglomeration from Eilandje to Berchem. 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.
Meir, Nationalestraat and ModeMuseum carry a different brief profile. Fashion brands, boutiques and SMEs with shorter publication cycles. They have smaller infrastructure budgets than a port corporation, but the same risk profile: a hacked site or a form sending data without legal basis damages reputation faster than slow LCP. Checkout tested only in English does not catch regressions in Dutch.
The Port of Antwerp-Bruges and Eilandje are a third pillar. Logistics operators, spare parts suppliers and industrial material vendors publish product catalogues, material configurators and landings for a specific service line. Traffic spikes during port campaign week are a real failure profile that needs cache, CDN and staging with rollback written before deploy.
The typical brief that reaches seniors in Antwerp 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 fashion season opening starts next week. That is a checkout, webhook and HPOS problem, not a marketplace template problem.
We see WooCommerce Subscriptions in Antwerp 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 Antwerp 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. Fashion campaigns generate heavy JPEGs from the lookbook; 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. Fashion season opening or a port campaign is an infrastructure test, not a quarterly average. Monitoring from a single US region lies when visitors browse from Flanders. 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.
Entry audit covers: taxonomy and BTW/TVA 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, fashion season and port campaign 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 BTW/TVA 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.
This page stays with the shop: catalogue, checkout, payment, shipping, stock, document, return. Blog theme, Gutenberg, intranet or a corporate site at Antwerp Digital Hub are not the topic here. That is WordPress developer in Antwerp. Monitoring, core updates and backups without checkout rebuild are WordPress maintenance and support in Antwerp. Broader care without a city: WordPress maintenance. The shared e-commerce pillar: WooCommerce developer.
Antwerp Digital Hub, Meir and the Port of Antwerp-Bruges 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 fashion season opening.
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 Antwerp agglomeration), whether HPOS is enabled, what the warehouse looks like (Antwerp, 3PL, regional HQ), whether finance waits for export to Exact Online, whether cookie consent blocks tags before approval, and which fashion season or port campaign 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 Antwerp get the same engineering rigour as any other store, with the stack Belgian buyers actually use and a fashion season and port campaign calendar written into the release schedule.
Explore selected projects supporting our clients' success.
Digital World Capital LLP is an alternative investment manager specializing in the telecommunications and media sectors on a global scale. The company focuse...
In the eastern part of Mielno, an exclusive apartment complex by the Baltic Sea, DUNE Resort, is being developed. This exceptional investment evokes the lu...
Instytut-csr.net is one of the valuable projects in my WordPress developer portfolio, realised as an educational and informational platform dedicated to Corp...
How we approach AI citations, WooCommerce B2B modernization, and NIS2-aligned operational resilience on WordPress. These guides apply to every client location.
Local expertise: - WooCommerce checkout in Antwerp in EUR via Bancontact, Mollie and Stripe with 3DS and webhooks - bpost, DPD and GLS shipping zones with pickup points across the Antwerp agglomeration - HPOS in wp_wc_orders tables, stock reservation and payment webhook idempotency Our team understands the Antwerp market and tailors solutions to local business needs. In practice, this means a focus on Core Web Vitals, local intent, and information architecture tailored to the Antwerp market.
Let's discuss how we can bring top-tier performance to your project.
Schedule free consultation in AntwerpStay updated with the WooCommerce Developer community
Since 26 August 2026, links in Google results go through google.com/goto instead of straight to the page. What this changes in analytics, in rank tracking tools and in WordPress, and what it does not change at all.
WP Rocket 3.23.2.1 and earlier fatal on WordPress 7.1: TypeError in Cloudflare.php line 562. GitHub report 6 July, sites down 19 August, fix 3.23.2.2 on 20 August. Update the plugin first.
Google now expands AI Overviews to a full AI Mode answer on some queries and pushes the ten blue links down. Our Search Console numbers on offer URLs at positions 2 to 4, and what we changed so the overview has a fact to cite.
Google changed its JSON-LD extraction and now applies only one pass of HTML unescaping. Double-escaped entities are no longer unrolled, so the block stops parsing and the structured data disappears. How to measure your own corpus and how to encode it correctly.
Google splits site reputation manual actions by searcher location from 30 August 2026. Outside the EEA the demotion still hits the affected portion. Inside the EEA that impact does not apply; the section may rank independently. Why parasite SEO does not return.
More articles are available on /en/blog/
For each gateway we document supported flows (one-shot, recurring, refunds, partial refunds, 3DS through Mollie or Stripe), the test transaction matrix, webhooks and local idempotency so a duplicate webhook does not create a duplicate order. End-to-end QA on staging covers cart, Bancontact, Mollie, Stripe, PayPal and Apple Pay payment, admin confirmation, email, carrier label, refund and failure paths, including the scenario where the customer paid but Woo still shows pending after a payment plugin patch.
Yes. The work usually starts with a Lighthouse, WP-CLI profile and Query Monitor pass on the most-trafficked product, category and checkout pages in Antwerp, identifies the actual bottleneck (heavy theme, autoloaded options, slow plugin queries, catalogue image weight, cart fragments, a gateway script loading before LCP) and tackles those one at a time rather than installing yet another optimisation plugin.
Strengthen your business with professional technical support in key areas of the WordPress ecosystem.
Stores, checkout flow, and sales logic.
Store outage, slow checkout, post-update chaos.
Ongoing WooCommerce care, monitoring, and uptime.
EU store checklist: VAT, accessibility, evidence pack.
White-label WordPress development for agencies.
WooCommerce sync with ERP and wholesale systems.
Google shut off the Content API for Shopping on 18 August 2026, so v2.1 calls now return 410 Gone. If your WooCommerce store feeds Merchant Center through the official plugin you are fine, but custom integrations that never moved to Merchant API are already offline.
Architecture for a WooCommerce catalog on Astro 7. What stays in wp-admin, which plugins die with the theme, Store API versus GraphQL, and why checkout stays on WooCommerce.
The Shopify Plus vs WooCommerce headless decision in 2026 is no longer a binary "platform vs custom" trade-off. Both can run headless, both integrate AI, both ship at the edge. The real axes are control, total cost over five years, and exit strategy. This article walks the matrix with confirmed platform facts.