BigCommerce Open Payment Provider Fee Explained: Which Payments Trigger It and What It Costs

How does the BigCommerce Open Payment Provider Fee work?

What the Open Payment Provider Fee actually is

The Open Payment Provider Fee is a BigCommerce platform charge applied to eligible order GMV on its self-service plans when the order is processed through a payment provider that is not on BigCommerce’s current Embedded Payment Provider list. BigCommerce bills it monthly in arrears and displays it as a separate line item on the merchant invoice.

It is important to separate this fee from payment processing. A payment processor or gateway can still charge its own percentage, fixed transaction charge, cross-border fee, currency-conversion fee or other commercial rate. The BigCommerce Open Payment Provider Fee is a different layer. BigCommerce charges it because of the provider classification attached to the order; it is not the processor’s own fee and it does not mean BigCommerce processed the card transaction.

BigCommerce also states that the fee is charged to the business rather than the shopper and must not be passed through as an Open Payment Provider surcharge at checkout. That rule is separate from whatever surcharge rules a payment network or local law may impose on card payments more generally.

Performance is different from the self-service tiers. BigCommerce currently publishes zero Open Payment Provider Fees for Performance accounts operating under contracted terms. Because Performance is contractual, a large merchant should still rely on its own signed commercial terms for account-specific pricing rather than assuming every provision is identical across contracts.

The current BigCommerce fee rates — and why the percentage alone is not enough

The headline rates are easy to find. What they do not tell you is how much of a merchant’s GMV will actually be multiplied by the rate.

Those numbers are current BigCommerce published terms, but a fee percentage without the correct base can be misleading. If a Growth merchant has $80,000 in post-reduction Inclusive GMV and only one quarter of that amount is attributed to Open providers, multiplying the full $80,000 by 1% would overstate the fee by four times. The relevant base in that example is the $20,000 Open share, not the full $80,000.

That is why a payment-cost comparison should not stop at “Core is 2%” or “Scale is 0.6%.” The more useful question is: what share of the billing-period Inclusive GMV does BigCommerce actually attribute to Open payment routes?

Embedded vs. Open Payment Providers

BigCommerce currently lists 21 Embedded Payment Providers. The list includes major names such as Stripe, Adyen, Amazon Pay, Checkout.com, Klarna, PayPal Braintree, PayPal Complete Payments, PayPal Wallet, Afterpay, Affirm and BigCommerce Payments, alongside additional regional and specialized providers.

Orders processed through a provider on the current Embedded list do not incur the Open Payment Provider Fee. Any payment provider not on that list is treated as Open for this fee under BigCommerce’s published framework.

The classification should not be read as a quality ranking. “Embedded” is a BigCommerce program classification, not a general statement that one provider is safer, cheaper or technically better than every Open provider. Some merchants use specialized gateways because of country coverage, existing commercial relationships, complex integrations, industry requirements or payment methods that are important to their customers.

The list is also not permanent. BigCommerce says current partner classifications can evolve, that merchants receive advance notice of changes, and that changes apply prospectively to future orders. For that reason, provider status should be verified against the live BigCommerce Embedded Payment Provider list before a merchant makes a migration decision based on fee savings.

There is a useful structural contrast with open-source commerce. WooCommerce core does not impose a platform-level transaction percentage based on which gateway a merchant chooses. That does not make payment processing free — gateways, extensions and integrations can still have costs — but it illustrates why provider classification is a specifically important part of BigCommerce’s hosted SaaS economics.

The order-level rule that determines whether you pay

This is the most important part of the mechanism: having an Embedded Payment Provider enabled somewhere in checkout does not automatically make every order fee-free. BigCommerce attributes each order to the provider that actually processed it.

Imagine a store that displays PayPal Wallet and a direct card option routed through an Open gateway. PayPal Wallet is currently an Embedded provider. If the shopper chooses PayPal Wallet and PayPal processes the order, the order’s GMV is not subject to the Open Payment Provider Fee. If the shopper instead chooses the Open gateway, that order can be fee-exposed even though an Embedded option was visible on the same checkout page.

The part I initially underestimated when mapping this out was how quickly the store-level question becomes useless. Asking “Do we use Stripe?” is not enough. A merchant with five payment routes may use Stripe heavily and still accumulate fee exposure through the other four. What matters is the distribution of actual processed orders, not the list of payment logos a shopper can see.

Which payments and orders trigger the fee?

The table below is the practical version of BigCommerce’s current policy. Provider classifications can change, so provider-specific rows should always be read against the live Embedded list.

Why offline and purchase-order merchants need to look closer

The offline rule is one of the easiest parts of the policy to miss because “payment provider fee” sounds like something that should exist only when a card gateway processes a transaction. BigCommerce’s own documentation says otherwise: offline GMV counts as Open Payment Provider volume.

That makes the fee particularly relevant to merchants with B2B or hybrid workflows. A company may use an Embedded processor for every consumer card transaction while still accepting invoices, purchase orders or other manual payment methods from wholesale buyers. The card side can be entirely fee-free while the offline side creates Open Provider GMV.

This also explains why payment-provider audits should include operational order types, not just the storefront’s payment settings. A merchant can review the checkout configuration, see Stripe and PayPal, and conclude the fee should be zero — while a meaningful share of order value is actually being recorded through purchase-order terms in a B2B workflow.

The categorization is internally consistent with the rule BigCommerce has chosen: an offline order was not processed by an Embedded Payment Provider. Whether that economic model is attractive for a particular B2B merchant is a separate question. The useful point for budgeting is that an offline-heavy business can have a very different OPP bill from a pure DTC store at the same total GMV.

How mixed payment-provider stores are charged

Mixed-provider stores are where the headline percentages become least useful. A merchant might route most card volume through Stripe, use a regional Open provider for one market and accept some B2B orders offline. In that setup, there is no single “BigCommerce transaction fee” that sensibly describes all sales.

Suppose a Growth-plan store has $80,000 in annual Inclusive GMV after BigCommerce’s 10% reduction. Of that post-reduction GMV, 75% is attributed to Embedded providers and 25% to Open providers.

Payment mix therefore becomes an operating metric. A merchant can lower fee exposure without eliminating every Open provider if more order volume shifts to Embedded routes. The reverse can also happen: an Open provider may remain enabled for months with little impact, then become materially expensive after a new market or customer segment starts using it heavily.

For planning purposes, I would track the provider mix alongside processor pricing. A 1% BigCommerce fee on 10% of volume is a very different problem from the same 1% fee on 70% of volume, even though both merchants can truthfully say they are “using an Open provider.”

How BigCommerce calculates Open Payment Provider GMV

BigCommerce’s current published method starts with Inclusive GMV. For billing and plan-threshold purposes, BigCommerce describes GMV as gross order value after a 10% reduction. That number can differ from a merchant’s own revenue tracking, and BigCommerce explicitly says the difference is expected.

For the Open Payment Provider Fee, BigCommerce publishes the following relationship:

This is why the figure in a BigCommerce invoice may not reconcile directly to a Stripe dashboard or accounting report. The merchant may be comparing different concepts: raw checkout revenue, processor-settled payments, accounting revenue, total gross order value and BigCommerce’s post-reduction Inclusive GMV are not necessarily interchangeable numbers.

There is a second distinction worth preserving. Plan tier and Open-provider attribution are separate systems. Core and Growth use trailing-12-month Inclusive GMV thresholds to determine when a merchant moves to a higher plan. Scale uses its own included monthly GMV and overage structure, and BigCommerce says Scale accounts move to Performance at $2 million in trailing-12-month GMV. The OPP Fee, by contrast, asks how individual orders were processed. The systems interact because the plan determines the OPP percentage, but an Embedded order does not become Open merely because a store grows into a higher tier.

Practically, the merchant’s account dashboard is the right source for reconciliation. BigCommerce says the dashboard shows current Inclusive GMV and the share attributed to each provider category. That is more reliable for fee auditing than rebuilding the number from a general revenue report.

What the fee actually costs at realistic payment mixes

Every example in this section starts with Inclusive GMV after the 10% reduction. The payment-mix percentages refer to the share of that adjusted Inclusive GMV attributed to Open versus Embedded routes. That keeps the examples aligned with the BigCommerce billing model rather than treating raw merchant revenue as the fee base.

Core: $20,000 Inclusive GMV, 100% Open

A smaller Core merchant with $20,000 in post-reduction Inclusive GMV and every order processed through an Open provider has the simplest calculation:

$20,000 × 2.0% = $400 per year.

If the same adjusted GMV were instead processed entirely through Embedded providers, the Open Payment Provider Fee would be zero. At Core’s rate, the percentage difference is large even when the absolute dollar amount is still manageable.

Growth: $80,000 Inclusive GMV, 25% Open

This is the mixed example above. Only $20,000 of the adjusted Inclusive GMV is Open-provider volume, so the fee is approximately $200 rather than $800. This is a good illustration of why a merchant should not use “annual sales × plan rate” as a budgeting shortcut.

Growth B2B: $90,000 Inclusive GMV, half offline

A wholesale-leaning merchant can stay within Growth’s published $100K trailing-12-month threshold while still having meaningful offline exposure. If the merchant has $90,000 in adjusted Inclusive GMV and half is attributed to purchase orders or other offline methods, the fee-exposed portion is $45,000:

$45,000 × 1.0% = $450 per year.

This is a more realistic Growth example than modeling several hundred thousand dollars of trailing annual GMV on a tier BigCommerce says auto-upgrades after $100K.

Scale: $1.2 million Inclusive GMV, 40% Open

A Scale merchant with $1.2 million in adjusted Inclusive GMV and 40% of that amount attributed to a regional Open provider has $480,000 of fee-exposed GMV:

$480,000 × 0.6% = $2,880 per year.

The percentage is much lower than Core’s, but a smaller percentage on a large base can still produce a meaningful cost. This example also keeps the OPP Fee separate from Scale’s 0.9% GMV overage above the included $33,333 monthly amount. They are different charges driven by different rules.

What happens with marketplace and externally originated orders?

BigCommerce’s pricing documentation is clear that certain social-commerce transactions and native Amazon and eBay integrations count toward sales/order totals used for plan economics. That answers the plan-GMV question.

The harder question is whether a marketplace-originated order — where an external marketplace handled the actual buyer payment and BigCommerce receives an order record — is universally attributed the same way for Open Payment Provider Fee purposes. The official material is much clearer about plan GMV inclusion than it is about every possible marketplace payment-attribution path.

That difference matters because plan thresholding and OPP attribution are separate systems. It would be unsafe to assume that “counts toward GMV” automatically answers “is Open-provider fee-exposed” for every marketplace integration and account configuration.

This is one place where refusing to overstate the rule is more useful than forcing a universal answer. Merchant discussions can surface edge cases, but they should not be treated as a substitute for the platform’s own billing attribution on a live account.

Where the fee appears on your BigCommerce invoice

BigCommerce says the charge appears as a distinct monthly line item labeled Open Payment Provider Fee. Fees are calculated on the prior calendar month and billed monthly even if the underlying BigCommerce subscription itself is billed annually.

If the amount looks unfamiliar, a six-step reconciliation is more useful than comparing the invoice directly to total revenue:

1. Confirm the plan. Core, Growth and Scale use different OPP percentages.
2. Open the provider-attribution breakdown. Identify how much Inclusive GMV BigCommerce assigned to Embedded versus Open categories.
3. Check the actual order routes. A visible Embedded option does not matter if the shopper actually used an Open provider.
4. Include offline orders. Manual and purchase-order volume can create fee exposure.
5. Apply the plan rate to Open Provider GMV. Do not multiply raw revenue by the headline percentage.
6. Escalate genuine mismatches. If the provider breakdown and published rate do not reconcile to the invoice, that is a support question rather than something to solve by guessing.

If the line item does not appear, BigCommerce says the relevant orders were processed through Embedded providers or the Open Payment Provider GMV for that billing period was zero.

Should you switch payment providers to avoid the fee?

Not automatically. BigCommerce itself notes that some merchants decide not to switch because the fee is smaller than the switching cost. Its current guidance says provider changes can take roughly two weeks to four months end to end depending on underwriting, integration complexity and reconciliation needs.

The correct comparison is therefore not “Open provider = bad, Embedded provider = good.” A provider migration can affect processing rates, settlement, authorization performance, fraud tooling, saved payment methods, subscriptions, regional payment coverage, accounting, reconciliation and operational support. A fee saving can be real and still be smaller than the value lost elsewhere.

The payment-provider break-even calculation

A provider-switch decision becomes much clearer when the Open Payment Provider Fee is translated into a payback model rather than discussed as a percentage.

Consider a Scale merchant with $200,000 of Open Payment Provider GMV. At 0.6%, the BigCommerce OPP cost is:

$200,000 × 0.6% = $1,200 per year.

Now assume an Embedded alternative would cost 0.20 percentage points more in processor fees on the same volume. The additional processor cost would be:

$200,000 × 0.20% = $400 per year.

The recurring economic benefit from switching is therefore approximately:

$1,200 OPP Fee avoided − $400 higher processing cost = $800 per year.

If implementation, testing and migration cost $2,000 once, the simple payback period is:

$2,000 ÷ $800 = 2.5 years.

That example shows why saying “we save 0.6% by switching” would be inaccurate. The business eliminates a 0.6% BigCommerce fee but gives 0.2% back through a more expensive processor, leaving a 0.4% recurring improvement before other operational differences. If the new provider instead had a lower processing rate, the economics could become much more attractive. If migration required extensive redevelopment or reduced authorization rates, the opposite could be true.

This is the part of the decision I would model before touching the payment settings. The fee itself is easy to calculate once the Open GMV is known. The harder question is whether the alternative payment stack creates a better total cost and operating outcome.

How the fee changes the way BigCommerce pricing should be compared

BigCommerce pricing can no longer be summarized responsibly by the subscription amount alone. Core, Growth and Scale already have different GMV rules, and the Open Payment Provider Fee adds a variable cost that depends on payment architecture. Two merchants can pay the same base subscription while carrying very different effective platform costs because one routes nearly every order through Embedded providers and the other relies heavily on Open or offline payment paths.

That does not make BigCommerce inherently expensive or inexpensive. It means the platform’s cost model is sensitive to configuration. Merchants using Embedded providers can have zero OPP Fee, while merchants with specialized payment requirements need to include an additional variable layer in their budget. That is a more precise way to evaluate the platform than treating the published OPP percentage as a universal transaction tax.

For the broader question — whether BigCommerce’s multi-storefront, B2B, API and catalog architecture justify its pricing for a particular business — continue to our BigCommerce rating and platform analysis. This article intentionally isolates the payment-provider mechanics because they are easy to lose inside a general platform review.

Bottom line

The BigCommerce Open Payment Provider Fee is best understood as a payment-routing cost, not a percentage automatically applied to every sale. The plan sets the rate. Order attribution determines the fee-exposed base. BigCommerce’s post-reduction Inclusive GMV provides the billing framework, and Embedded-provider attribution removes the GMV that is not subject to the fee.

That creates three practical rules. First, do not calculate the fee from raw revenue alone. Second, do not assume that enabling an Embedded provider makes the entire store fee-free. Third, do not forget offline and purchase-order volume, because BigCommerce explicitly counts offline GMV as Open Payment Provider volume.

For a merchant auditing an unfamiliar invoice line, the fastest route to the real answer is the provider-category breakdown in the BigCommerce account. Once that split is known, the percentage math is straightforward. The more strategic question — whether to change providers — should only come after processor rates, migration costs and operational dependencies are put next to the OPP Fee in the same model.