E-Commerce Platforms & Shop Systems
BigCommerce
Provenance unknown Report an errorPanel rating · 6 judges · How to read the stars
Category median
Sovereignty: 1 of 4 dimensions proven
0–5 in half steps. 5 means the rubric's top anchor is met on the evidence.
by BigCommerce, Inc. · www.bigcommerce.com
Report an error on this page Is this your product? →
Read this page as one judge. Each weighs the same scores by what they care about.
The panel's verdict
BigCommerce is strongest on catalog and checkout and extensibility: the judges found a one-page checkout that can be forked on GitHub with full source access, digital wallets, one-click and buy-now-pay-later, customer-group pricing, account-specific catalogs and B2B invoicing, plus REST and GraphQL APIs across storefront, admin, account and B2B with downloadable OpenAPI specs. It is weakest on sovereignty and pricing transparency: the vendor is BigCommerce, Inc. with copyright held by BigCommerce Pty. Ltd., hosting appears as a Google Cloud Platform heading with no server region stated, the subprocessor list was not captured, and the captured pages show no plan price — the public cost facts are a free trial without a credit card and no payment fees through 20+ embedded providers. Tax and legal sits at 4, with hand-configured rates and no public information on VAT-ID validation, reverse charge or OSS. The judges split on operations: the B2B seller scored 7 for multi-channel order intake and 600+ integrations; the operations lead scored 4, finding no named vendor-maintained interface and returns only as third-party apps.
Speaks for it
- A one-page checkout that can be forked on GitHub with full source access, shipping digital wallets, one-click, and buy-now-pay-later.
- Account-specific catalogs, customer-group pricing, purchase orders, and B2B invoicing at checkout.
- REST and GraphQL APIs across storefront, admin, account, and B2B, with downloadable OpenAPI specs and headless starter solutions.
- No payment fees for orders processed through 20+ embedded payment providers.
- A migration app documented for up to 500,000 product, customer, and order records.
Held against it
- Tax rates configured by hand, with no public information on VAT-ID validation, reverse charge, OSS reporting, or e-invoicing.
- Hosting on Google Cloud Platform with no server region stated and a subprocessor list whose contents were not captured.
- No plan price on the captured pages, with PayPal card rates described only as pre-negotiated.
- Migration documented inbound only, with no public information on export completeness or a data-return commitment.
- Returns appearing only as a marketplace category of nine apps, with no public information on partial shipments or carrier label printing.
Best for
- You sell to business buyers and need account-specific catalogs, customer-group pricing, and purchase orders or invoice payments at checkout.
- Your team wants to build and own the storefront, using a forkable checkout and REST and GraphQL APIs with downloadable OpenAPI specs.
- You sell across channels — marketplaces such as Amazon, Walmart, and eBay, point of sale, and multiple storefronts.
- You are moving in from Shopify, WooCommerce, or Adobe Commerce (Magento) and need a documented import of up to 500,000 records.
Avoid if
- You need vendor-handled German or EU tax correctness — the documented tax mechanism is manual rate configuration, with no public information on VAT-ID validation, reverse charge, or OSS reporting.
- Your procurement requires an EU contracting entity or a stated server region — the vendor is BigCommerce, Inc., the copyright holder is BigCommerce Pty. Ltd., and hosting appears as Google Cloud Platform without a region.
- You must budget from published prices — the captured pages show a free trial and the absence of payment fees, but no plan price, billing period, or order limits.
- You need returns processed in the system rather than through marketplace apps — returns appear as a nine-app category.
The scores
Catalogue & checkout
Show reasoningHide reasoning
How this is scored
Products, variants, pricing rules and the path to payment — the part that either converts or does not.
0 — Flat product list with one price and no variants; checkout is a form and one payment method.
3 — Variants and categories with a standard checkout and two or three payment methods, but no bundles, no tiered pricing and no guest checkout worth the name.
5 — Full variant matrix, product bundles, tiered and customer-group pricing, guest checkout, and the payment methods a German shop needs including invoice and direct debit.
8 — Configurable products, per-channel pricing, promotions and vouchers with rules, a checkout that can be customised without a rebuild, and payment via the major providers plus buy-now-pay-later where offered.
10 — Merchandising and checkout are the product: rule-driven pricing and promotions, A/B-testable checkout, multi-currency and multi-language as standard, and conversion features (abandoned cart, one-page checkout) shipped rather than bolted on.
The Merchant
This is the checkout I want to sell on: optimized one-page checkout, no-code controls in the control panel for branding and guest checkout behaviour, full source access and a GitHub fork of the checkout, plus digital wallets, one-click, buy-now-pay-later and B2B invoicing among 250+ payment methods, with abandoned-cart email recovery and checkout upsells shipped. I found no public information on product variants, bundles or tiered pricing, and direct debit is not named among the methods, which is what holds this back from the very top. 1 3 4
The B2B Seller
This is a shop that has met a trade customer: account-specific catalogs and pricing, customer-group pricing, purchase orders and B2B invoicing at checkout, plus a one-page checkout with wallets, BNPL and shipped abandoned-cart recovery, multi-currency and multi-language. I stop just short of the top because we found no public information on a configurable-product variant matrix, voucher rules engines or A/B testing of the checkout. 1 3 4
The Developer
One-page checkout with wallets, one-click and BNPL, abandoned-cart recovery shipped rather than bolted on, multi-currency and multi-language as standard, plus customer-group and account-specific pricing and promotions in checkout — and a checkout that can be forked on GitHub with full source access rather than reskinned in a closed editor. I found no public information on A/B-testing the checkout or on native bundles and tiered quantity pricing. 1 3 4
The Operations Lead
One-page checkout, abandoned-cart recovery, digital wallets, one-click and buy-now-pay-later are shipped features on the product pages, and customisation goes as far as forking the checkout on GitHub with full source access; customer-group and account-specific pricing are documented alongside multi-currency with real-time exchange rates and multi-language. We found no public information on variant matrices, bundles, tiered pricing or A/B-testable checkout, which is what keeps this short of the very top. 1 3 4
The Data Protection Officer
The captured checkout pages show a one-page checkout that can be forked on GitHub with full source access, BNPL, digital wallets and one-click, plus customer-group pricing, account-specific catalogs, promotions and upsells inside checkout, and abandoned-cart email recovery shipped alongside multi-currency and multi-language. We found no public information on an A/B-testable checkout or a rule-driven promotions engine, which is what keeps this off the top band. 1 3 4
The Skeptic
One-page checkout, wallets, one-click and buy-now-pay-later are all public, and the checkout can be forked on GitHub with full source access and a SDK — that is customisation without a rebuild, which I rarely get to say. Pricing rules run to customer-group and account-specific pricing with promotions and upsells inside checkout; I found no public information on product bundles or A/B-testable checkout variants. 1 3 4
Tax & German legal correctness
Show reasoningHide reasoning
How this is scored
VAT determination, OSS, B2B reverse charge, and the checkout requirements German law actually imposes — judged on what the platform does, not on a plugin someone could buy.
0 — A single VAT rate applied everywhere; no B2B handling, no country logic, no legal-text handling in checkout.
3 — Per-country VAT rates configurable by hand, net prices for B2B possible with effort, and legal texts as free-form pages.
5 — Automatic VAT by destination and customer type, VAT-ID validation with reverse charge, gross and net display per customer group, and the mandatory checkout elements (order button wording, withdrawal policy, price indications) handled.
8 — OSS thresholds tracked and reported, correct invoicing per case including reverse-charge notes, small-business and third-country handling, and e-invoicing (XRechnung/ZUGFeRD) for B2B orders.
10 — Tax and legal correctness are maintained by the vendor rather than the merchant: rates and thresholds updated as the law moves, OSS reporting produced, every invoice case correct out of the box, and documented conformity a lawyer could review.
The Merchant
Tax is configured by hand: manual rates per zone and per tax class with tax-inclusive or exclusive price display per customer group, guest-zone detection via geolocation, and collection for multiple taxation authorities — a capable kit the merchant maintains. I found no public information on automatic VAT determination, VAT-ID validation with reverse charge, OSS, XRechnung or ZUGFeRD e-invoicing, or the German checkout legal texts, so German-law correctness stays my job rather than the platform's. 5 6 9
The B2B Seller
Zones by country, subdivision and postal code, with inclusive or exclusive price display per customer group, get a shop to net prices for trade buyers — but the rates themselves are configured by hand via the tax API. We found no public information on VAT-ID validation with reverse charge, OSS thresholds and reporting, e-invoicing formats, or the German checkout requirements such as order-button wording and withdrawal policy, which is the core of my test. 5 6
The Developer
Tax zones resolve by customer address or geolocation and can be scoped to customer groups with inclusive or exclusive price display, which gets a German B2B shop part of the way. But the rates themselves are configured by hand per country, subdivision and postal code, and I found no public information on VAT-ID validation, reverse charge, OSS reporting, e-invoicing or the mandatory German checkout elements. 5 6
The Operations Lead
The developer docs show real determination machinery — the shopper's address or geolocation assigns a tax zone, zones can be scoped to customer groups, and price display switches between tax-inclusive and exclusive per zone and per group — but the rates themselves are configured by hand through the Tax Rates and Zones API. We found no public information on VAT-ID validation with reverse charge, OSS reporting, e-invoicing formats, or the German checkout elements such as order-button wording and withdrawal policy. 5 6
The Data Protection Officer
The tax documentation states plainly that the Rates and Zones API configures manual taxes, with per-country, per-subdivision and per-postal-code zones, multiple rates per zone, and tax-inclusive or exclusive price display per customer group and zone. That is hand-built VAT rather than vendor-maintained correctness: we found no public information on VAT-ID validation, reverse charge, OSS reporting, e-invoicing, or the German checkout elements such as order-button wording and withdrawal policy, and cross-border automated taxes appear only via shipping partners. 5 6 9
The Skeptic
Tax is configured by hand through zones and rates — country, subdivision and postal-code zones with a rate per tax class — and the destination-based zone detection plus per-customer-group gross or net display is genuinely documented. I found no public information on VAT-ID validation with reverse charge, OSS thresholds or XRechnung/ZUGFeRD e-invoicing, so the German cases fall on the merchant or on a tax service whose name and price the captured pages never give. 5 6
Extensibility & developer surface
Show reasoningHide reasoning
How this is scored
Themes, apps, APIs and headless — whether the shop can be shaped to the business, and at what cost in lock-in.
0 — Fixed templates, no app ecosystem, no API.
3 — Theme editing within limits and a small app store; a read-mostly API and no local development story.
5 — Custom themes with a template language, an app or plugin ecosystem, a documented REST API, and webhooks for the core order events.
8 — Full storefront API for headless builds, an extension framework with its own lifecycle, staging environments, version control for themes, and documented rate limits.
10 — A platform a team can own: headless-first APIs, open-source or source-available core, plugin architecture with a real dependency model, local development and CI supported, and upgrade paths that do not orphan customisations.
The Merchant
The developer surface is broad and public: REST and GraphQL APIs across storefront, admin and B2B, downloadable OpenAPI specs, headless starter solutions, a documented session-sync rate limit, and full source access to the checkout — a shop a team can shape without a rebuild. I found no public information on staging environments as a platform feature, version control for themes or webhooks for order events, which keeps it one tier below the best-in-class surface. 7 8 3 4
The B2B Seller
A full GraphQL storefront API alongside REST with downloadable OpenAPI specs, JWT session sync for headless logins, and a checkout whose source I can fork on GitHub is a surface a team can build a proper B2B portal on. We found no public information on staging environments, documented API rate limits or version control for themes, so I settle at the level below the top. 3 7 8
The Developer
The strongest developer surface on these pages: GraphQL and REST storefront APIs with downloadable OpenAPI specs, headless starter solutions, MCP servers, and a checkout that can be forked on GitHub with full source access. Catalyst ships as versioned packages, which gives the storefront layer a real upgrade cadence, but I found no public information on version control for the theme system itself, a plugin dependency model, staging environments outside third-party app categories, or documented API rate limits. 2 3 7 8 12
The Operations Lead
REST and GraphQL surfaces across storefront, admin, account and B2B with downloadable OpenAPI specs, headless starter solutions, a WordPress plugin, Catalyst packages at published versions, and a checkout you can fork — a development team can genuinely own the storefront. Staging appears only as an app-marketplace category, and rate limits are spelled out only for session sync rather than for the APIs generally. 2 3 7 8
The Data Protection Officer
There is a genuine headless surface — REST and GraphQL APIs across storefront, admin, account and B2B, downloadable OpenAPI specs, starter apps, and a checkout a team can fork and rebuild — which sits well above a basic plugin shop. We found no public information on staging environments, on documented rate limits beyond the session-sync lockout, or on version control for themes, so this stops short of the top band. 3 7 8
The Skeptic
GraphQL and REST surfaces across storefront, admin, account and B2B, downloadable OpenAPI specs, headless starter solutions, MCP tooling and a checkout you can fork — a developer surface a team can actually work with. I found no public information on staging environments, documented rate limits or a local development story beyond two staging apps in the marketplace. 3 7 8 12
Order operations & back office
panel disagrees
Show reasoningHide reasoning
How this is scored
What happens after checkout: order management, stock, returns, shipping, and the link to ERP or accounting.
0 — An order list and an email; stock is a number nobody trusts, returns are manual.
3 — Order statuses and basic stock, one shipping integration, and returns handled by hand.
5 — Order workflow with partial shipments, multi-warehouse stock, named carrier integrations with label printing, and a returns process in the system.
8 — Multi-channel order intake, automated fulfilment routing, supplier and dropshipping flows, and maintained interfaces to named ERP and accounting systems.
10 — The shop is the front of an operation: real-time stock across channels and warehouses, returns and refunds fully worked including partials, ERP integration the vendor maintains, and operational reporting a merchant runs the business from.
The Merchant
Native operations cover the shipping side well — real-time carrier quotes, flat-rate and value-based rates, multi-address shipping, POS stock sync and buy-online-pick-up-in-store — and reach into ERP, WMS and 3PL through 600+ integrations is real breadth. Returns processing and much of order management arrive as marketplace apps rather than in the system, and I found no public information on partial shipments, carrier label printing or dropshipping flows. 9 10 3 1
The B2B Seller
Multi-channel order intake from marketplaces, point of sale and multiple storefronts with inventory, customers and orders synced everywhere you sell, plus 600+ ERP, CRM, PIM and WMS integrations and 3PL connections, is a real back office. Returns appear only as an app category rather than a process in the system, no ERP or accounting system is named, and we found no public information on partial shipments, supplier and dropshipping flows or carrier label printing. 1 3 9 10
The Developer
Multi-channel intake is real — marketplaces, multi-storefront and 150+ sync channels — and the Shipping Manager does real-time carrier quotes, flat and weight-based rates, with 3PL, warehouse and fulfilment-centre connections plus integration categories for ERP, CRM, PIM and WMS. Returns appear only as third-party apps, and I found no public information on partial shipments, multi-warehouse stock, dropshipping or named ERP and accounting systems. 1 3 9 10
The Operations Lead
What the pages show is shipping setup with real-time carrier quotes and named rate tools — ShipperHQ, Advanced Shipping Manager, GlobalE — a point-of-sale inventory sync claim, marketplace and multi-storefront selling, and an integration count of 600+ across ERP, CRM, PIM and WMS without a single named, vendor-maintained interface. We found no public information on partial shipments, partial refunds, label printing or multi-warehouse stock, and returns appear only as a category of nine third-party apps rather than a process in the system. 1 3 9 10
The Data Protection Officer
Multi-channel intake is well evidenced — marketplace listings, point-of-sale sync, multi-storefront, 3PL and warehouse-system connections, and a Shipping Manager with real-time carrier quotes and location-based methods. Returns surface only as a nine-app marketplace category, and we found no public information on partial shipments or carrier label printing; from my seat, order data running through that many third-party apps also spreads customers' personal data across the chain. 1 3 9 10
The Skeptic
The shipping story is broad — real-time carrier quotes, 3PL, OMS/WMS connections, BOPIS, cross-border duties and customs documentation — with 600-plus ERP, CRM, PIM and WMS integrations claimed at category level and multi-channel intake from marketplaces and point of sale. But returns sit in a nine-app marketplace category rather than an evidenced native process, and I found no public information on partial shipments, automated fulfilment routing or ERP interfaces the vendor maintains. 1 9 10
Data ownership & exit
Show reasoningHide reasoning
How this is scored
Whether the catalogue, customers and order history remain the merchant's: export completeness, hosting choice, and what leaving actually costs.
0 — Export is a partial CSV; order history and customer records cannot leave intact, and hosting is the vendor's alone.
3 — CSV export of products and customers, order history partial, no self-hosting, no documented migration path.
5 — Complete export of catalogue, customers and orders via API or dump, documented deletion, and a stated data-return commitment.
8 — Full-fidelity export including media and order documents, self-hosting or a choice of hosting partner, and no metering that prices a migration out of reach.
10 — Ownership is structural rather than promised: open-source or source-available platform the merchant can run anywhere, database-level access, documented migration in both directions, and contractual data return.
The Merchant
Moving in is documented in detail — a migration app handling 500,000 product, customer and order records, post-import error reporting, and a data-erasure module in the security program. The way out is not: I found no public information on full export of catalogue, customers and order history, a stated data-return commitment, self-hosting or a documented exit path, so what leaving actually costs cannot be judged. 11 12 2
The B2B Seller
The way in is well documented — a migration app and services transferring up to 500,000 product, customer and order records with post-import error reporting — and data erasure and backups are named modules. But the captured pages document entry, not exit: we found no public information on complete export of catalogue, customers and order history, a data-return commitment, or self-hosting. 2 8 11
The Developer
Migration is documented in one direction only — into the platform from Shopify, WooCommerce and Magento with a 500,000-record transfer limit — while the security programme names data erasure and backups. I found no public information on export completeness, self-hosting or a documented path out, which is the number that tells me what a five-year commitment actually costs. 2 8 11
The Operations Lead
Every migration fact points inward — a migration app, premium migration services, agencies, 500,000 product, customer and order records, post-import error reporting — while the public APIs and a named Data Erasure module in the trust centre are the only outward-facing pieces. We found no public information on export completeness, a documented way out, self-hosting, or a data-return commitment. 2 8 11 12
The Data Protection Officer
Moving data in is documented — 500,000 product, customer and order records via a migration app — and Data Erasure is listed as a security module heading, but we found no public information on export completeness, on deletion executing against order history, or on a data-return commitment. Hosting is on the vendor's Google Cloud platform with no alternative offered, so the pages captured do not document what leaving actually costs. 2 11 12
The Skeptic
Everything public about moving data is about arriving: a migration app, premium migration services and agencies for up to 500,000 product, customer and order records in, plus 28 migration-service apps and a Data Erasure module in the trust center. I found no public information on outbound export fidelity, self-hosting, or any commitment — let alone price — for leaving with your own catalogue and order history. 2 11 12
European sovereignty
panel opinion
Show reasoningHide reasoning
How this is scored
Where customer and order data live, who the contracting entity is, and which subprocessors sit in the checkout path. Independently sourced by the sovereignty pipeline.
0 — Non-EU vendor and contracting entity, hosting unstated or non-EU, subprocessors unnamed.
3 — EU hosting offered as an option while the contracting entity is non-EU, or the subprocessor list is absent.
5 — EU hosting as standard and an EU contracting entity, but parts of the chain — CDN, analytics, payment routing, support tooling — are non-EU without an explained safeguard.
8 — EU hosting on named infrastructure, EU contracting entity, complete subprocessor list published, any non-EU processing named with its legal basis.
10 — Sovereign end to end and evidenced: vendor, entity, hosting and every subprocessor European, certification published, and a self-hosted option that puts the shop entirely under the merchant's control.
The Merchant
No server region is stated — infrastructure is Google Cloud Platform with no location given — and although a trust center lists Subprocessors and a Data Processing Agreement as document categories, their contents were not captured, so no subprocessor names and no safeguard against US legal access are visible. The copyright entity is BigCommerce Pty. Ltd. and I found no public information on an EU contracting entity or EU hosting. 2 4 11
The B2B Seller
The vendor is BigCommerce, Inc. with the copyright held by BigCommerce Pty. Ltd., and we found no public information on an EU contracting entity, EU hosting or any server region — hosting appears only as a Google Cloud heading. The subprocessor list and data processing agreement exist as document categories whose contents were not captured, leaving an unexplained US CLOUD Act exposure in the checkout path, which for my EU trade customers puts this at the bottom. 2 11
The Developer
The pages name Google Cloud Platform as infrastructure with no server region stated, the copyright entity is BigCommerce Pty. Ltd., and I found no public information on an EU contracting entity, EU hosting or a captured subprocessor list. The trust pages offer an international data transfer whitepaper and a DPO contact, which acknowledge the transfer question without evidencing an EU-side safeguard. 2 11
The Operations Lead
No server region is stated anywhere, the only hosting reference is a Google Cloud Platform heading in the trust centre, and the subprocessor list exists as a document category whose contents were not captured. The footer entity is BigCommerce Pty. Ltd., a corporate form outside the EU, and the single point is for published privacy materials such as a Data Protection Officer and an international transfer whitepaper. 2 4
The Data Protection Officer
The vendor is BigCommerce, Inc. with copyright held by BigCommerce Pty. Ltd., hosting runs on Google Cloud Platform with no server region stated, and the subprocessor list exists only as an uncaptured document heading — so with 20+ embedded payment providers in the checkout we cannot see where a single one of them processes. Data-protection artefacts such as a DPO contact, a transfer impact summary and an international transfer whitepaper exist as headings, but we found no public information on EU hosting, an EU entity, or where CDN, analytics and payment routing sit, and the US cloud provider in the chain raises Cloud Act exposure. 1 2 4
The Skeptic
The entity in the footer is BigCommerce Pty. Ltd., the trust page names Google Cloud Platform as infrastructure without stating a server region, and the subprocessor list exists only as a document category whose contents were not captured. Security certification is impressive and a DPO plus a transfer-impact summary are offered, but on the European questions — EU entity, EU hosting, named subprocessors — I found no public information at all. 2 4 11
Pricing transparency
Show reasoningHide reasoning
How this is scored
Whether a merchant can compute the real annual cost — licence, transaction fees, apps, hosting — from public pages alone. The category where the headline price is least often the invoice.
0 — No public prices at all; every tier is a sales conversation.
3 — A monthly headline exists, but transaction fees, mandatory apps or hosting costs are unstated — the invoice is unknowable from the page.
5 — Tier prices public with billing period stated and transaction fees given, but at least one commonly needed piece (a required app, hosting, payment gateway rate) is unpriced.
8 — Every tier priced publicly including transaction or revenue-share rates, order or GMV limits, and the cost of the extensions most shops need; VAT treatment and minimum term stated.
10 — Complete price computability: annual cost derivable for a given order volume and GMV including licence, transaction fees, hosting and typical extensions — and for open-source platforms, an honest statement that the licence is free and where the money actually goes.
The Merchant
No plan price appears on the captured pages — no monthly figure, no billing period, no order or revenue limits, no VAT treatment — so the real annual licence cost is not computable from public information. The few cost facts run the other way: a free trial without a credit card and no payment fees through 20+ embedded providers, while PayPal card rates are described only as pre-negotiated and volume-linked, without figures. 1 4 12
The B2B Seller
No plan price appears on the captured pages, so a merchant cannot compute the licence cost of an annual deal from public information — every tier is a sales conversation. Credit where due: the free trial with no credit card and the stated absence of payment fees for 20+ embedded providers are public, but we found no public information on tier prices, billing period, order limits or the actual PayPal card processing rates. 1 4 11
The Developer
I found no public information on subscription prices across the captured homepage, product and checkout pages; what is public is a free trial without credit card and "no payment fees for orders processed through 20+ embedded payment providers". Without a published tier price, order limits, minimum term or VAT treatment, the annual cost is not computable from public pages. 1 4 12
The Operations Lead
The only cost facts on the captured pages are a free trial with no credit card and no payment fees for orders processed through the 20+ embedded payment providers, with PayPal rates described only as pre-negotiated and decreasing as you grow. We found no public information on plan prices, billing periods, order or revenue limits, minimum terms or VAT treatment, so a merchant cannot compute the annual invoice from public pages. 1 4
The Data Protection Officer
The only pricing facts captured are a no-credit-card free trial and the statement that there are no payment fees for orders through 20+ embedded providers, with PayPal card rates described as pre-negotiated but no figures given. We found no public plan prices, billing periods, VAT treatment or order limits, so a merchant cannot compute a real annual cost from these pages. 1 4
The Skeptic
No plan price appears on any captured page — not the monthly headline, not the billing period, not order limits — and the only cost facts are a no-credit-card trial and the absence of payment fees on 20+ embedded providers. The PayPal rates are "pre-negotiated" and unstated, and the app marketplace filters Free versus Paid without prices, so a merchant cannot compute a year's invoice from what is public. 1 4 12
European sovereignty — proven facts
1 of 4 dimensions provenBuilt only from facts shown on the vendor's own pages. A dimension we could not prove is left open, not scored as zero.
| Legal entity | Not determined | — | uncited Report an error |
|---|---|---|---|
| Ownership | Not determined | — | uncited Report an error |
| Data residency | Not determined | — | uncited Report an error |
| Subprocessors | US CLOUD Act reach ⚠ unverified | 0/2 pts | 2 Report an error |
Where this could be wrong
- Evidence ages. The oldest capture behind this page is from 29 Sep 2026. Vendors change pricing and policies without notice; every fact reflects its source as of the capture date shown in the registry.
- Weak sourcing — Subprocessors. Google Cloud Platform appears only as a trust-center section heading under Infrastructure rather than in the subprocessor list or DPA (both exist as document categories but their contents were not captured), and no server region is stated
- AI can misread a source. Extraction and judgement are automated; a citation guarantees traceability, not infallibility. If something here is wrong, say so — no account needed, every report is decided within 5 business days, and accepted corrections are published.
What we left out
A claim that does not survive our checks costs us the claim, not the page. This is what was taken off this one.
- 37 product facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 11 integrations facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 9 pricing facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 2 compliance facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 1 legal fact could not be confirmed on the vendor’s page as captured and was left out of this page and of the panel’s material. Know more? Tell us
- 1 support fact could not be confirmed on the vendor’s page as captured and was left out of this page and of the panel’s material. Know more? Tell us
Sources (12)
The pages every claim on this page was read from — each one checked, dated, and kept verifiable.
- 1 Vendor page www.bigcommerce.com Checked 29 Sep 2026 Details →
- 2 Security / trust page — found from the homepage security.bigcommerce.com Checked 30 Sep 2026 Details →
- 3 Catalogue & checkout — found from sitemap www.bigcommerce.com Checked 1 Oct 2026 Details →
- 4 Catalogue & checkout — found from sitemap www.bigcommerce.com Checked 1 Oct 2026 Details →
- 5 Tax & German legal correctness — found from sitemap docs.bigcommerce.com Checked 1 Oct 2026 Details →
- 6 Tax & German legal correctness — found from sitemap docs.bigcommerce.com Checked 1 Oct 2026 Details →
- 7 Extensibility & developer surface — found from sitemap docs.bigcommerce.com Checked 1 Oct 2026 Details →
- 8 Extensibility & developer surface — found from sitemap docs.bigcommerce.com Checked 1 Oct 2026 Details →
- 9 Order operations & back office — found from sitemap www.bigcommerce.com Checked 1 Oct 2026 Details →
- 10 Order operations & back office — found from sitemap www.bigcommerce.com Checked 1 Oct 2026 Details →
- 11 Data ownership & exit — found from sitemap www.bigcommerce.com Checked 1 Oct 2026 Details →
- 12 Data ownership & exit — found from sitemap www.bigcommerce.com Checked 1 Oct 2026 Details →