WooCommerce Developer in Bern

A WooCommerce store serving customers in Bern sits next to the Bundeshaus at Bundesplatz, canton Bern administration and Swisscom headquarters at Alte Tiefenaustrasse. That is not a reason for checkout to pretend to be a federal portal. It is a reason for payment gateways, VAT logic and order data handling to be written the way a Swiss legal team, a German-speaking buyer in Bern and a French-speaking reviewer from canton Vaud expect before anything reaches production.

WPPoland builds this WooCommerce from a senior Polish team for businesses, suppliers and organisations with a base, branch or client base in Bern. Scope is WooCommerce development: custom checkout, Swiss payment gateways, VAT and shipping rules, DE/FR bilingual storefronts, ERP integrations and code review on Git. Institutional WordPress sites and maintenance retainers are separate topics, with links at the end.

#WooCommerce development in Bundesstadt and canton Bern

Bern is not Basel with pharma and the stock exchange, nor Geneva with the UN and WTO. It is Bundesstadt: seat of the Federal Council, parliament and key federal offices around Bundesplatz. Canton Bern adds its own administration, universities and a dense network of IT suppliers serving public procurement. Swisscom, headquartered in Bern-Ost, is one of the city’s largest technology employers, but a WooCommerce brief here rarely reads “build us a shop like a telecom operator”. More often it reads: inherited theme with twelve plugins, TWINT that fails on mobile Safari, DE/FR product descriptions that drift apart after an update, and a reviewer in Bern asking about nFADP, hosting in CH and whether order exports send personal data to a US CRM without a processor agreement.

For a WooCommerce store those facts mean three harder requirements than on a typical B2B market. First, payment trust: TWINT, PostFinance, invoice with QR-Rechnung and card with 3DS are not interchangeable. Swiss buyers expect the method they use daily. Second, formal language: German front in formal Sie, French version in parallel, checkout errors and transactional email in both languages, not machine translation from a Polish brief. Third, order data residency and retention: hosting in Switzerland, backups, logs and CRM integrations are discussed before the first commit, not as a contract appendix after a data incident.

Bern Digital Hub at Wylerstrasse and nearby coworking spaces (Impact Hub Bern, Biel/Bienne in the agglomeration) add reviewers who read pull requests and ask whether the consent plugin sends IP addresses to the US without a legal basis. The University of Bern (Universität Bern) and Bern University of Applied Sciences (BFH) produce people who can tell a payment webhook from a theme function and know that Polylang does not replace an editorial process for product copy. Commuters from Biel/Bienne, Thun and Solothurn work in one office in German and French, so a DE/FR storefront with Polish fulfilment back office is more common here than a purely Polish front with a German panel.

The typical brief that reaches seniors does not read “make a fast shop”. It reads: WooCommerce on a marketplace theme, cart fragments slowing every page, Swiss VAT rounded wrong on B2B orders, TWINT working in staging but not production, and a product catalogue synced from ERP with duplicate SKUs after a cron job. That is a checkout, integration and Git-process problem, not a “install another plugin” problem.

WPPoland is not a contractor for admin.ch or canton Bern. Proximity to the Bundeshaus sets the bar for documentation, roles and bilingual delivery. It does not set a list of government references.

#Checkout, payments and Swiss buyer expectations in Bern

Checkout in Bern is where revenue is won or lost. A store that loads product pages quickly but stalls on payment confirmation loses the sale at the worst moment. The work starts with a written audit of the current checkout: fields collected, gateways active, mobile behaviour, failure paths and what happens when a webhook arrives twice.

#TWINT, PostFinance, Stripe and card flows

Swiss buyers in Bern use TWINT daily. PostFinance remains common for invoice and card flows in canton Bern. Stripe and PayPal cover international cards and subscriptions where the brief requires them. Each gateway gets its own runbook: supported flows (one-shot, recurring, refunds, partial refunds, 3DS), test card matrix, webhook list, idempotency handling and reconciliation steps for the finance team.

TWINT integration is tested on real mobile devices, not only desktop staging. Safari on iOS handles redirects differently from Chrome on Android. A checkout that works in the developer’s browser but fails when the buyer returns from the TWINT app is a production incident, not a minor UX issue.

PostFinance and invoice-with-QR-Rechnung flows need clear copy in DE and FR: what the buyer pays, by when, and what reference number appears on the bank transfer. WooCommerce order status must reflect payment reality. An order marked “processing” before funds arrive creates support load and accounting mismatch.

Stripe with 3D Secure 2.0 is the default for card payments where TWINT is not offered. Webhook signatures are verified. Failed payments leave the cart intact with a readable error in the buyer’s language, not a blank screen or a generic “something went wrong”.

#Logic in the plugin, presentation in the theme

The boundary is simple and recorded in the runbook. The theme shows product layout, category archives and brand tokens. The plugin knows checkout hooks, gateway configuration, VAT rules, ERP sync and B2B role pricing. If changing the theme breaks TWINT callbacks, the architecture was wrong.

A custom WooCommerce extension has its own prefix, PSR-4 autoload, main file with Plugin Name header and semver. Checkout logic does not go into the theme’s functions.php, because functions.php dies with the theme and a Bern client changes branding agencies more often than the payment stack.

Layer comparison used at kickoff:

#Swiss VAT, shipping and fulfilment for stores in Bern

Swiss VAT (MWST) is not EU VAT. Rates, registration thresholds and B2B reverse-charge rules need explicit configuration in WooCommerce tax settings and custom logic where the default plugin behaviour is insufficient. A store shipping from a warehouse in Bern-Ost to buyers across Switzerland and into neighbouring EU markets needs zones, classes and rounding rules documented before launch.

Shipping zones for Switzerland typically split by weight, package size and carrier API. Swiss Post integration with real-time rates reduces checkout abandonment compared to flat “CHF 9.90” guesses. Pickup points and Saturday delivery are brief topics, not afterthoughts.

B2B wholesale in Bern often means role-based pricing, minimum order quantities, request-for-quote for large orders and separate payment terms (invoice net 30) alongside consumer TWINT. Those rules live in a plugin layer with tests on price calculation, not in ad hoc coupons that an editor can delete by mistake.

ERP and inventory sync from systems common in Swiss SMB chains (Abacus, Bexio, custom CSV from a Bern supplier) run on Action Scheduler with explicit conflict resolution: what wins when ERP stock is zero but Woo shows three units, how often sync runs, and who gets alerted when sync fails overnight.

Product data import automation from supplier feeds needs idempotent keys. A cron that creates duplicate variable products every night is worse than manual entry. The runbook records field mapping, error notifications and rollback steps.

#DE/FR bilingual storefront: Polish team, Swiss front

The most common friction in Poland-Bern ecommerce collaboration is not PHP. It is tone, currency display and the language pair. Institutional German uses formal Sie. The French version cannot be a literal translation from a Polish brief or a machine export from DE without native review. That is not solved by WPML alone. It is a language brief, a string list in the theme and plugin, and an approval process before production.

Practical rules written into store documentation:

• Interface strings (buttons, form errors, aria-label, placeholder) are in formal Sie on DE and formal vous on FR when the front is bilingual. Checkout errors must name the field and the fix, not only “invalid input”.
• Product titles and descriptions may be authored in DE, FR or both. The brief records who approves each language before the SKU goes live.
• CHF formatting uses Swiss conventions: apostrophe thousands separator where the brief requires it, two decimal places for consumer prices, clear VAT-inclusive or VAT-exclusive labelling per legal advice.
• Impressum, privacy policy (Datenschutzerklärung / politique de confidentialité), terms of sale (AGB / conditions générales) and withdrawal information are linked from checkout and footer. In Bern those pages are compliance, not marketing footer. Commercial-register entry (Zefix) and canton Bern data are verified by the client; the store supplies fields and templates, not “automatic legal compliance”.

Polylang or WPML solve hreflang and language copies. They do not solve process: who approves German product copy, who approves French, before production. Staging shows both language versions because “DE broke because someone edited FR” appears only on comparison, not in Lighthouse.

Transactional email (order confirmation, shipping notice, password reset) is tested in both languages with real SMTP on staging. A template that renders broken French accents or wrong date format erodes trust faster than a slow category page.

#Performance engineering for WooCommerce in Bern

Speed is a competitive advantage in Bern. Research consistently shows that every 100ms of additional load time costs conversion. WooCommerce adds cart fragments, session cookies and plugin queries that a brochure site never carries. The performance pass targets the paths that matter: product view, category archive, cart and checkout.

What the team measures and fixes:

• Asset optimisation: images in WebP and AVIF through a build pipeline, responsive srcsets, lazy loading below the fold without delaying LCP on the hero product image.
• Caching architecture: Redis object cache for WordPress, transients with explicit TTL on product queries, CDN cache rules that exclude cart and checkout URLs, browser cache for static assets with content hashes.
• Cart and session: cart fragments loaded only where needed, session handler tuned for CH hosting, no full-page cache on checkout or account pages.
• Database: autoloaded options audit, slow query log on staging, index review on wp_postmeta where attribute filters dominate.
• Checkout: minimal plugin footprint on checkout template, deferred non-critical scripts, payment gateway scripts loaded only on payment step.

Every performance decision is data-driven. Lighthouse and Core Web Vitals on product and checkout templates in DE and FR are part of acceptance, not a separate project sold later.

#Security, nFADP, FDPIC and order data in Switzerland

Proximity to the Bundeshaus and Swisscom does not turn a WooCommerce store into a federal classification system. The team does not claim “ISO 27001 compliant” or “NCSC certified” unless the client ran that audit. WordPress and WooCommerce should deliver inventory, access trail and update discipline the client can paste into procurement or processor-agreement documentation, not an agency “compliance stamp”.

Posture maintainable in code and process without pretending to be an audit:

• No secrets in Git. API keys for gateways, CRM and ERP go through environment variables. wp-config.php with a password in Git history is an incident.
• Admin and shop manager accounts use 2FA. Roles are cut to what WooCommerce requires. A Polish fulfilment user does not get install_plugins on production.
• XML-RPC disabled unless justified. File editor in the admin disabled.
• Headers: HTTPS, HSTS where certificate and CDN allow, CSP matched to real scripts (consent, analytics, payment iframes).
• Dependencies: pinned plugin versions, CVE scan in CI, Woo and WordPress updates on staging before production.
• Backups and restore: backup without tested restore is decoration. Restore test on staging is in the runbook. Backup residency in CH is a contract topic.
• Logs: who changed gateway settings, which order export ran when. Retention agreed with nFADP and client policy. After an incident the client may need to notify the Federal Data Protection and Information Commissioner (FDPIC, EDÖB in German); logs must fit a notification form. The agency does not file on behalf of the data controller.

GDPR and nFADP are separate layers in cross-border briefs. EU buyers ordering from a Bern store may fall under GDPR; Swiss residents under the revised Federal Act on Data Protection (nFADP). Form-field minimisation, processor agreements with Stripe, PostFinance and email providers, consent for marketing and analytics scripts, and hosting location are mapped before launch. Hosting “in Switzerland” is a jurisdiction argument, not a magic shield. A checkout collecting personal data without legal basis and without policy coverage is not fixed by a server in Bern-Ost alone.

PCI DSS scope stays with the payment provider where card data never touches the WordPress server. The brief records which gateways tokenise on their side and which fields Woo stores locally.

Penetration tests are mentioned only when the client has or orders them from a lab. WPPoland does not add certificates it does not hold. Hardening WooCommerce is a set of pull-request decisions, not a slide about zero incidents.

#Git, staging and QA on order paths

This layer separates senior WooCommerce work from “upload a plugin ZIP over FTP”. In Bern a client with an IT department or public-procurement experience asks about it on the second meeting, especially if the reviewer comes from BFH, Bern Digital Hub or internal IT at Swisscom.

The repository holds the custom theme and custom plugins. Plugins from WordPress.org and WooCommerce.com do not live as copied folders in Git unless there is a hard reason (fork, patch, air-gap). One feature branch per change: new gateway, VAT fix, DE/FR string sync, cart performance. Pull request has description, screenshots or screen recording of checkout, and checklist: i18n, accessibility on checkout fields, no secrets, payment test on staging, both language versions pass regression.

Code review is done by a senior who did not write the branch. Review runs WordPress Coding Standards but also reads intent: should B2B pricing live in a plugin, does the webhook handler survive duplicate delivery, does the cart fragment hook run on every page unnecessarily. PR comments are in English or Polish depending on the client reviewer; Swiss IT in Bern usually prefers English in the diff and DE/FR in shop manager documentation.

Staging is a production copy with anonymised customer data. Real gateways in sandbox mode. Crons that send mail to real addresses disabled. Shop managers click through staging with real products in both languages. Production promotion is a documented step: tag or merge to main, asset build, cache warmup, rollback path. The team does not “quick upload” one PHP file over SFTP before a seasonal sale in Bern, because nobody can reconstruct what was on production on Friday.

End-to-end QA on staging covers: guest checkout, registered checkout, TWINT and card success paths, failed payment, refund, partial refund, order email in DE and FR, admin order edit, stock decrement, ERP sync if in scope. Failure paths are as important as happy paths. A buyer who sees a charged card and no order email will call support before they call the developer.

#Bern Digital Hub and the local ecommerce scene

Bern Digital Hub at Wylerstrasse 60A is a reference point for Bern’s digital ecosystem: meetups, networking, projects linking administration, startups and IT suppliers. It is not a WPPoland sales argument. It is a barometer: ecommerce leads in Bern ask about the repository, staging and whether the checkout breaks after a Woo update because they heard those questions at local meetups and in BFH corridors.

Impact Hub Bern and nearby initiatives add reviewers who read copy and configuration. Swisscom as an employer sets the bar for suppliers in the chain: questions about data location, log retention and payment webhook security appear earlier than on a typical Polish B2B market.

The wider Swiss scene has WordCamp Switzerland and meetups in Zurich or Basel, but a Bern brief does not need to pretend to be Basel banking or Geneva diplomacy. For this city DE/FR bilingual delivery, canton Bern logistics and Swiss payment methods matter more than a slide about “global organisations”. Stores from this team must survive questions: where order data is stored, who approves the French product page, whether a marketing pixel fires before consent, and whether TWINT callbacks are verified on staging.

#WordPress institutional sites are a separate scope

This page does not build federal publication catalogues, Gutenberg block themes for public consultation or CPT-driven intranets. If the brief moves to institutional WordPress without checkout, scope changes owner and is described by the WordPress developer in Bern. Pillar without city: WordPress developer. Mixing shop and institutional theme in one repository without plugin boundaries is the fastest route to a Woo update breaking a compliance landing, or a theme change breaking TWINT.

A corporate site with one “shop” button to external Woo can stay in the theme as a link. Cart logic itself does not belong on an institutional brief.

#After launch: handover or maintenance

A development engagement ends with documentation, handover session and Git access for the client team. The runbook describes: how to add a product, how to configure a shipping zone, how to test a gateway in sandbox, how to ship a branch, how to rebuild staging, whom to call when checkout fails after a plugin update, how to publish a DE/FR product pair without hreflang regression. If ongoing Woo updates, monitoring and on-call are needed after launch, that is WooCommerce maintenance in Bern, not a hidden annex to the store build. Pillar without city: WooCommerce maintenance.

Development pricing is individual and delivered in writing after scope is agreed. There is no rate card or “hour packages” on this page. Scope changes (sudden B2B layer, third language, ERP integration mid-sprint) return to the written record before they enter a sprint.

#How to start a WooCommerce project in Bern

A short brief is enough to begin: which theme and plugins exist today, which gateways are live (TWINT, PostFinance, Stripe), who manages products (PL/DE/FR), whether the front should use formal Sie and vous, whether B2B pricing is in scope, whether Bern IT requires Git and staging from day zero, where hosting sits and whether backups must stay in CH. The team reviews the install, lists risks (checkout plugin stack, secrets in repo, missing privacy policy, broken DE/FR pair, VAT rounded wrong on wholesale) and proposes a plan with acceptance criteria.

Contact: WPPoland contact form. The service pillar without city in the slug remains at WooCommerce developer.