DEV Community: Robert Domestisck

Top B2B eCommerce Platforms with Headless & Composable Architecture in 2026

Robert Domestisck — Wed, 15 Apr 2026 12:12:02 +0000

Top B2B eCommerce Platforms with Headless & Composable Architecture in 2026

The shift toward modular, API-first commerce architecture is no longer a forward-looking experiment — it's the operating standard for manufacturers, distributors, and wholesalers building serious digital sales channels. When your catalog has 50,000 SKUs, your pricing logic lives inside an ERP, and your buyers expect the same experience on a mobile app, a kiosk, and a web portal, a monolithic platform becomes a ceiling rather than a foundation.

This guide covers seven platforms that have made genuine progress on headless and composable architecture for B2B use cases, ranked with enterprise B2B teams in mind. Scores referenced below draw from Gartner's 2024 Critical Capabilities for Digital Commerce research.

1. OroCommerce

If your business operates complex B2B workflows — account hierarchies, role-based pricing, RFQ pipelines, and territory-level catalog segmentation — OroCommerce is built for exactly that scope. It is the strongest purpose-built B2B eCommerce platform in this list when measured against enterprise sales complexity.

The platform ships with CRM, marketplace, CMS, PIM and OMS bundled under a single license, which removes a common integration burden that other vendors push onto customers through third-party ISV partnerships. Its GraphQL and REST APIs support headless implementations with third-party DXP or front-end-as-a-service layers, while the modular monolith architecture keeps operational overhead lower than fully decomposed microservices stacks.

Gartner scores OroCommerce at 4.02 out of 5.0 for B2B Digital Commerce — second only to Spryker in that category — and highlights strong capabilities across B2B workflows, RFQs, CRM integration, and globalization via multisite inheritance. Recent additions include AI SmartAgent for B2B buying assistance, OroPay for check-out and invoicing, and AI-generated real-time reporting.

For manufacturing, distribution, and wholesale organizations that want deep B2B functionality without stitching together five separate vendor contracts, OroCommerce sits at the top of this list.

2. Spryker

Spryker earns its position as the highest-scoring platform in Gartner's B2B Digital Commerce use case at 4.32 out of 5.0, and its composable commerce score of 4.46 places it second overall in that category. The architecture — over 40 packaged business capabilities deployed on PaaS — gives development teams genuine modularity at the component level.

The platform's state machine and workflow BPM tooling are a particular differentiator for B2B. Complex purchase approval flows, multi-step quoting, and channel-specific rules can be configured without custom development. Its recent additions include a native auction capability, a customer self-service portal, and an MCP server that allows buyers to place orders through external LLMs including Anthropic Claude.

Spryker is well-suited for manufacturers, particularly in automotive and industrial sectors, where the commerce layer needs to connect tightly with IoT data, CPQ, and aftersales service workflows. Its main trade-off is operational overhead: as a PaaS offering, it requires a full-stack engineering team managing the full development and deployment cycle. Since Spryker mainly operates in Germany, its smaller North American footprint limits the pool of available integration partners.

3. Commercetools

Commercetools holds the highest composable commerce score in Gartner's Critical Capabilities research at 4.59 out of 5.0, which reflects a genuine architectural commitment rather than a marketing position. Every API is independently consumable, every service can be deployed in isolation, and the platform is natively available on AWS, GCP, and Azure — including a dedicated SaaS deployment in China, which few competitors offer.

The platform's target customer is a large global enterprise with more than $100 million in annual GMV and operations across multiple regions. Its Foundry precomposed solution for retail and manufacturing cuts initial deployment time, though implementation complexity remains high for teams without significant platform experience.

For B2B specifically, commercetools added buyer approval workflow automation, business-unit-specific pricing and promotions, and MCP-based agentic commerce frameworks that let merchants connect AI agents to the commerce stack.

However, despite these additions, the platform continues to rank notably lower than OroCommerce and Spryker in B2B-specific capabilities, which typically translates into a need for more extensive customization to meet complex B2B requirements. Its native CMS is lightweight, so organizations that need sophisticated content management will need a third-party integration — a known gap the vendor acknowledges.

4. BigCommerce

BigCommerce lands in Gartner's Challenger quadrant with a composable commerce score of 4.24, driven by its modular architecture of over 100 independently deployable microservices and a well-regarded partner ecosystem. The Catalyst headless storefront framework, built on Next.js and Vercel, gives front-end teams a modern development experience without rebuilding API connectivity from scratch.

The B2B Edition — a fully integrated module within the core platform — handles contract pricing, net payment terms, shared shopping lists, and company account management. Its acquisition of Feedonomics adds channel syndication across retail media and marketplace networks.

Where BigCommerce shows limits is in native functionality for complex B2B models: subscription commerce and marketplace operations both require third-party ISV integrations. Organizations running B2B2X models or multi-seller marketplaces will need to evaluate the partner ecosystem carefully before committing. That said, for mid-market B2B merchants who want a modern, composable foundation with a strong ecosystem, BigCommerce offers a credible path.

5. Elastic Path

Elastic Path takes an unusual position in this market: it sells its commerce modules independently, which means organizations can deploy only the capabilities they actually need — catalog management, subscriptions, cart and checkout, or the full composable stack. This a-la-carte model is genuinely differentiated and appeals to teams that are augmenting an existing platform rather than replacing everything at once.

The platform earns a composable commerce score of 4.15 from Gartner, with particular recognition for its Composer iPaaS layer that connects third-party services without custom middleware development. Its catalog architecture supports unlimited catalogs, price books, and hierarchies, which makes it well-suited for manufacturers and telcos managing complex product structures.

The consistent limitation noted by Gartner is B2B feature depth: Elastic Path lacks native RFQ management, B2B approval workflows, and role-based buyer configuration. Teams with heavy B2B workflow requirements will need to build or integrate those capabilities, which adds to implementation scope. For composable front-end projects where catalog flexibility is the primary driver, it's a strong candidate.

6. Shopware

Shopware holds a Visionary position in Gartner's 2025 Magic Quadrant, recognized for differentiated capabilities including 3D and AR product visualization, a native digital sales room, and AI-generated content tooling. It is among the fastest-growing vendors in the research by both revenue and customer additions, and its extension marketplace grew from 4,000 to 6,000 apps between 2024 and 2025.

The platform is available as open-source community edition, self-hosted, PaaS, or single- and multi-tenant SaaS — a deployment flexibility that midmarket European manufacturers tend to value. Its Composable Frontends framework supports JavaScript-based headless storefronts, while its native Symfony storefront handles teams that prefer a managed approach.

For B2B, Shopware offers a rule builder for pricing and promotions and a digital sales room capability that few platforms in this research match natively. The main gap is unified retail commerce — BOPIS, curbside, and store associate apps require third-party integrations — and its core remains largely monolithic despite modular service components.

7. Optimizely Configured Commerce

Optimizely Configured Commerce targets manufacturing, wholesale, and distribution customers in the mid-market, and it does that job with genuine depth. Its B2B capabilities cover visual product configurators, contract pricing, product entitlements, and CPQ workflows — all within a single-tenant SaaS environment bundled with DXP, PIM, DAM, and personalization.

Gartner highlights its AI-assisted search, via Google Vertex AI, generated product descriptions, and automated translations as meaningful B2B productivity tools. The platform's preconfigured headless storefront, built on React and pre-integrated with its native CMS Spire, gives customers a faster path to headless without rebuilding the API layer.

Two limitations worth noting: Optimizely's commerce offerings are rarely deployed independently of the broader DXP, which creates bundle dependency for customers who only need commerce functionality. Its native marketplace and subscription capabilities are also limited compared to other platforms in this list. For manufacturers and distributors already using or evaluating Optimizely One, the commerce module integrates tightly with the rest of the experience stack.

Choosing the Right Architecture for Your B2B Context

The platforms above reflect a wide range of trade-offs between composability, operational complexity, B2B feature depth, and total cost of ownership. A few questions worth working through before shortlisting:

How complex is your B2B buying process? If approval workflows, RFQ management, and account-based pricing are core to your sales motion, OroCommerce and Spryker offer the deepest native support. commercetools and BigCommerce cover the basics but require more ISV integration for advanced workflows.
What is your team's infrastructure capacity? Fully decomposed composable platforms like commercetools and Spryker require experienced platform engineering. BigCommerce and Optimizely are more accessible to smaller technical teams.
Do you need B2C and B2B from one platform? If your organization sells to both consumers and businesses, commercetools, OroCommerce, and BigCommerce all support this from a unified architecture without requiring separate platform instances.
What deployment model fits your compliance requirements? HIPAA, GDPR, and data residency requirements vary significantly by vendor. OroCommerce and Spryker support on-premises and private cloud deployments — a requirement in regulated industries that rules out several SaaS-only platforms.

The Gartner Critical Capabilities research referenced throughout this article evaluates these platforms across nine capability dimensions and five use cases. It remains one of the most structured tools available for comparing vendors against your specific deployment requirements.

Stop Storing Secrets in localStorage: Patterns for a Secure Digital ID Wallet

Robert Domestisck — Sun, 26 Oct 2025 19:48:45 +0000

TL;DR: localStorage is convenient, but it’s a glass box. If you’re building a digital ID wallet app (cards, IDs, passes), move secrets out of JS-readable storage. Use passkeys/WebAuthn for auth, httpOnly cookies or a BFF for sessions, and E2EE with non-extractable keys + IndexedDB for encrypted payloads. Sprinkle in CSP, Trusted Types, and a service worker for defense-in-depth.

Why localStorage is the wrong place for secrets

XSS exfiltration: Any script that runs in your origin can read localStorage. That means one missed output-escape, compromised NPM dependency, or misconfigured third-party and your tokens are gone.

Long-lived & persistent: Secrets survive tabs, reloads, and crashes. Great for convenience, terrible for incident response.

No flags: Unlike cookies, you can’t mark localStorage as HttpOnly, Secure, or SameSite.

Copyable at rest: DevTools, extensions, or shared machines can yank it.

What counts as a “secret”?
Access/refresh tokens, private keys, recovery seeds, raw PII, and unencrypted ID documents (images, PDFs, MRZ text). If losing it lets an attacker impersonate a user or decrypt their vault, it’s a secret.

Threat model for a Digital ID Wallet

Goal: store user cards/IDs encrypted at rest, unlock with the user’s device auth, and sync safely.

Trust boundaries: the server must never see plaintext vault data; the browser must not keep extractable keys in JS land.

Reality: XSS, supply-chain JS, malicious extensions, shoulder-surfing, stolen laptops.

So we need patterns that degrade gracefully even when XSS happens.

Pattern 1 — Authenticate with Passkeys (WebAuthn), not bearer tokens in JS

Use WebAuthn to create a device-bound credential. No tokens to hoard in localStorage.

// Register (create) a passkey
const publicKey: PublicKeyCredentialCreationOptions = {
challenge: await fetch('/webauthn/challenge').then(r => r.arrayBuffer()),
rp: { name: 'Your App', id: location.hostname },
user: {
id: new TextEncoder().encode(currentUserId),
name: currentUserEmail,
displayName: currentUserName,
},
pubKeyCredParams: [{ alg: -7, type: 'public-key' }, { alg: -257, type: 'public-key' }],
authenticatorSelection: { userVerification: 'required' },
};
const cred = await navigator.credentials.create({ publicKey });
await fetch('/webauthn/register', {
method: 'POST',
body: JSON.stringify(cred),
headers: { 'Content-Type': 'application/json' }
});

At sign-in, assert instead of exchanging passwords for bearer tokens:

const assertion = await navigator.credentials.get({
publicKey: {
challenge: await fetch('/webauthn/challenge').then(r => r.arrayBuffer()),
userVerification: 'required',
allowCredentials: [ /* your credential IDs */ ]
}
});
await fetch('/webauthn/verify', { method: 'POST', body: JSON.stringify(assertion) });

Session handling: Prefer an opaque, short-lived session issued server-side, returned as Set-Cookie with HttpOnly; Secure; SameSite=Strict. No token lands in JS.

Pattern 2 — Use a BFF (Backend-for-Frontend) instead of storing tokens client-side

If you must talk to third-party APIs, don’t hand access tokens to the browser. Let a thin BFF attach tokens server-side.

Browser -> BFF (/api/*) -> Upstream APIs
^ keeps only HttpOnly session cookie, no access tokens in JS

This removes the incentive to stash OAuth tokens in localStorage. When XSS fires, there’s nothing reusable to steal.

Bonus: If you need proof-of-possession, add DPoP at the BFF or mutual TLS upstream.

Pattern 3 — Encrypted vault in IndexedDB using non-extractable keys

Store encrypted cards/IDs in IndexedDB. The encryption key is a non-extractable CryptoKey wrapped by a passkey-protected key. Even if XSS lists your DB, it sees only ciphertext.

Step A: Create a content-encryption key (CEK)
// Non-extractable symmetric key
const cek = await crypto.subtle.generateKey(
{ name: 'AES-GCM', length: 256 },
false, // not exportable
['encrypt', 'decrypt']
);

Step B: Wrap CEK with a user-bound key

Use a wrapping key tied to the device (via WebAuthn + platform keystore) or derive from a user secret combined with device signals. Here’s the Web Crypto wrap flow (assuming you obtained/imported wrappingKey securely):

const wrapped = await crypto.subtle.wrapKey(
'raw',
cek,
wrappingKey, // e.g., RSA-OAEP/WebAuthn-backed
{ name: 'RSA-OAEP' }
);
// Save wrapped in IndexedDB; unwrap it after user verification

Step C: Encrypt and store records
async function encryptBlob(cek: CryptoKey, data: Uint8Array) {
const iv = crypto.getRandomValues(new Uint8Array(12));
const ct = await crypto.subtle.encrypt(
{ name: 'AES-GCM', iv },
cek,
data
);
return { iv, ct: new Uint8Array(ct) };
}

Persist { iv, ct } in IndexedDB. Never keep plaintext or keys in localStorage.

Pattern 4 — Gate decryption behind User Verification (biometrics/PIN)

On each unlock, require userVerification: 'required' via WebAuthn (or OS keychain on desktop apps). This makes decryption events interactive and ties them to Face/Touch ID.

await navigator.credentials.get({
publicKey: {
challenge: await fetch('/unseal/challenge').then(r => r.arrayBuffer()),
userVerification: 'required',
allowCredentials: [ /* the credential used to wrap CEK */ ]
}
});
// server returns a one-time unwrap token or a wrapped CEK shard

Practical note: Cache a short-lived unwrapped CEK in memory only (not in storage). Clear it on tab close, inactivity, or lock.

Pattern 5 — Service Worker as a thin shield

A service worker can centralize fetches and enforce “no secrets in requests”:

// sw.js
self.addEventListener('fetch', (e) => {
const url = new URL(e.request.url);
// Block accidental leakage of internal headers/query params
if (url.searchParams.has('token')) {
e.respondWith(new Response('Forbidden', { status: 403 }));
return;
}
e.respondWith(fetch(e.request));
});

It also provides offline caching of encrypted payloads only (Cache Storage). Never cache decrypted responses.

Pattern 6 — Lock down the front end (CSP, Trusted Types, COOP/COEP)

CSP: default-src 'self'; script-src 'self' 'strict-dynamic' 'nonce-...'; object-src 'none'; base-uri 'none'; frame-ancestors 'none'.

Trusted Types: eliminate DOM XSS sinks by requiring safe HTML builders.

Subresource Integrity: pin hashes for third-party JS (or better: self-host and sign).

COOP/COEP: isolate your browsing context to reduce cross-origin surprises and enable powerful APIs safely.

These won’t save you if you actively store secrets in JS storage, but they reduce XSS probability and blast radius.

Pattern 7 — Sync without trusting the server (E2EE)

For multi-device:

Generate CEK on Device A.

Wrap CEK using Device A’s wrapping key; upload only the wrapped blob.

On Device B, after user verification, re-wrap CEK for Device B and store locally.

Documents sync as ciphertext; the server never sees plaintext or unwrapped CEKs.

If you add multi-party access (e.g., family vault), use asymmetric envelope encryption: a unique data key per item, wrapped for each member’s public key.

Pattern 8 — Mobile & desktop: use platform keychains

If you ship native shells (Capacitor, React Native, desktop apps):

iOS: Keychain + Secure Enclave (non-exportable keys).

Android: Keystore with StrongBox where available.

Desktop: OS keyrings (Windows DPAPI, macOS Keychain, libsecret on Linux).

Store wrapped keys or small secrets there, never plaintext in sandboxed files.

What if you really need to remember something in the browser?

If you must persist some state:

Store opaque references or nonces, not secrets.

Use short expiry and bind them to device/credential where possible.

Rotate aggressively; treat it like a cache hint, not a keyring.

Migration playbook (away from localStorage)

Audit: find every read/write of localStorage, list the data classes (token, PII, UI prefs).

Classify: move only non-sensitive prefs (theme, layout) to localStorage; everything else migrates.

Session: swap JS bearer tokens for HttpOnly session cookies via a BFF.

Vault: introduce IndexedDB + non-extractable keys; write a one-time migration that decrypts old blobs and re-encrypts under the CEK.

App hardening: deploy CSP + Trusted Types; turn on SRI; review third-party scripts.

Kill switch: add a remote feature flag to force logout + key wipe for incident response.

Mini reference: Do / Don’t

HttpOnly; Secure; SameSite cookies for sessions

WebAuthn passkeys for auth + user verification

Non-extractable keys + AES-GCM in IndexedDB

E2EE sync (server sees ciphertext only)

CSP, Trusted Types, SRI, SW hygiene

Don’t

Put tokens, private keys, or vault plaintext in localStorage

Cache decrypted data in service worker/Cache Storage

Log secrets to console/analytics

Rely on obfuscation or UI-level “locks” as real security

Closing thoughts

A digital ID wallet lives or dies by how you store secrets. localStorage was never meant to be a key vault. With passkeys for sign-in, server-side sessions (or a BFF), and an encrypted vault backed by non-extractable keys in IndexedDB, you raise the bar dramatically—without wrecking UX. Add platform keychains on mobile/desktop, and you’ve got a modern, user-friendly wallet that stays locked even when the browser misbehaves.

If you want a follow-up, I can post a small reference implementation: WebAuthn login + CEK wrapping + encrypted IndexedDB with React hooks and a service worker cache that never touches plaintext.

5 Lessons from Web Development That Apply to People-Finder Platforms

Robert Domestisck — Thu, 31 Jul 2025 09:29:37 +0000

What do building a React app and reconnecting with a childhood friend have in common?

At first glance, not much. One involves component trees and state management; the other, years of distance and a lingering question: "What ever happened to them?" But look closer, and you’ll find that both share something powerful—code designed to connect people.
People-finder platforms like Radaris help users track down old friends, classmates, family members, or long-lost loved ones. Whether you’ve moved across states or simply drifted apart over time, platforms like these turn fragmented data—addresses, phone numbers, public records—into meaningful reconnections. They’re part search engine, part digital detective.

And they don’t work by accident. The tech principles that power great web applications—speed, structure, security, and user-centered design—are the same ones that make people-finders so effective. Web development isn’t just about building tools for businesses—it’s about building bridges between people.

Lesson 1: Speed Matters More Than Ever

In web development, speed isn't just a bonus—it's survival. Studies show that users start bouncing if a page takes more than 2–3 seconds to load. That urgency only intensifies on platforms driven by emotion. People-finder tools like Radaris.com aren't just utilities—they’re emotional engines. When you're trying to reconnect with someone who disappeared from your life years ago, waiting isn’t just frustrating—it’s heartbreaking.

That’s why performance optimization is critical. Platforms like Radaris leverage:

Indexed search to surface results faster than traditional database queries
Smart caching to avoid reloading previously visited profiles
Lazy loading to prioritize content visibility without overloading the page

📌 Callout: “At Radaris, milliseconds matter when you're searching for someone who’s been missing for years.”

Lesson 2: User Experience is Everything

Speed gets users in the door, but user experience earns their trust. Clunky interfaces breed hesitation, especially when someone’s emotionally invested in the outcome. On the other hand, a fluid, intuitive design helps users feel confident—and keeps them engaged.

For people-finder platforms, that means:

Search-as-you-type to show instant feedback and reduce typing errors
Mobile-first UI for users looking up names from their phones at a family gathering
Contextual breadcrumbs that help users trace their search journey without confusion

Radaris excels at this with a clean, responsive layout, logical filtering options, and CTAs that guide without overwhelming. When someone is nervous about finding the right person, clarity becomes comfort.

Trust isn't a feature—it’s the byproduct of thoughtful design.

Lesson 3: Data Integrity is a Feature, Not a Footnote

In web development, clean, structured, and normalized data is the foundation of any stable app. If your database is a mess, no amount of front-end magic can fix it. The same is even more critical in people-finder platforms like Radaris.

When you're helping users reconnect with someone from their past, a wrong address or mismatched name isn’t just a technical hiccup—it’s a broken lead or false hope. That’s why data integrity isn’t a backend concern—it’s a core feature.

Behind the scenes, platforms like Radaris rely on:

Deduplication algorithms to avoid showing the same person multiple times
Validation rules to flag incomplete or suspicious entries
Source hierarchy to prioritize the most credible data sets

The challenge? Balancing data volume with verification. Pulling from multiple public records, social networks, and third-party databases requires strict logic to determine what’s real and what’s noise.

🛠️ People-finders aren’t just aggregators—they’re data curators.

Lesson 4: Privacy by Design

The old mindset was “gather everything.” In 2025, the mantra is “protect everything.”

Privacy isn’t a checkbox—it’s a design principle. With increasing scrutiny from users and regulators, platforms like Radaris are embedding privacy directly into the product lifecycle.

That means compliance with laws like GDPR and CCPA isn’t optional—it’s fundamental. But technical compliance is just one side of the coin. The developer’s role is to operationalize privacy:

Building granular permission layers that control who sees what
Creating opt-out workflows that are user-friendly and effective
Securing data with encrypted endpoints and robust access controls

🔐 “Building trust starts in the codebase.” When users feel that their data is respected and protected, they’re far more likely to engage—and stay.

Lesson 5: Empowering Users with Insight, Not Overload

In development, we know the difference between a great dashboard and a terrible one. The best ones highlight what matters; the worst ones bury users in data. That same principle is crucial in people-finder platforms.

When someone searches for a long-lost friend or relative, they don’t want a data dump. They want clarity. A smart interface prioritizes information like:

Last known location
Past occupations
Possible relatives
Relevant age or education markers

This isn’t just a UI challenge—it’s a UX responsibility. Overloading users with raw data can create anxiety or confusion, especially when it comes to sensitive subjects like reconnecting after years apart.

Good platforms use design patterns that support progressive disclosure to surface the most relevant details first, offer intuitive filters, and encourage thoughtful outreach, not invasive digging.

📌 Ethical UX means empowering, not overwhelming.

Conclusion: Building With Empathy

In the world of people-finder tools, web development isn't just about performance or architecture—it's about people.

Your choices as a developer—from how fast a page loads to how data is displayed or protected—shape how someone experiences that crucial moment of reconnection. It's not just about using the latest tech stack or building the slickest UI.

💡 “When you're building tools that help someone reconnect with a person they lost touch with, clean code and fast endpoints aren’t just nice-to-haves—they're acts of service.”

That’s why privacy-by-design frameworks aren’t just compliance checkboxes—they’re trust-building tools. It’s also why people-finder tools must focus on data accuracy as a product feature, not an afterthought.

In the end, great platforms blend engineering skill with emotional intelligence—and that’s where the magic really happens.