Website Builder Transaction Fees Explained: What That Extra Percentage Costs You and How to Bring Your Own Payment Setup

A website-builder sale can carry two separate charges: the platform’s transaction fee and the payment processor’s card-processing fee. They may come from different companies. Upgrading your plan, using native payments, or connecting another gateway can reduce one charge, but the result depends on the builder’s current plan, country, and provider rules.

What You’re Really Paying on Each Sale

Question	Short Answer
Is a platform fee the same as card processing?	No
Can both apply to one sale?	Yes
Does upgrading sometimes reduce platform fees?	Yes, depending on the builder
Does connecting another gateway automatically remove the builder fee?	No
Is interchange pricing always cheaper?	No
Should merchants compare total effective cost?	Yes

The number that matters is not the first percentage shown on a pricing page. It is what you actually lose to payment-related costs after the platform fee, processor fee, gateway costs, international charges, fixed fees, refunds, and other relevant expenses are included.

For a store doing $2,500 a month, an extra 1% may be only $25. At $100,000 a month, the same 1% is $1,000 every month before the underlying card-processing bill is counted.

That is why website builder transaction fees explained properly are a unit-economics question, not merely a pricing-page question.

Website Builder Transaction Fees Explained: Platform Fee vs Processing Fee

Several charges can sit around the same ecommerce order without being the same charge.

Charge	Who Charges It	What It Pays For	Percentage or Fixed?	Can It Potentially Be Reduced?
Builder transaction fee	Website/ecommerce platform	Platform commerce or checkout services under the builder’s pricing policy	Often percentage-based	Sometimes, through a different plan or payment configuration
Card-processing fee	Processor, payment facilitator, or acquirer	Authorization, clearing, settlement, network costs, risk and processor services	Percentage, fixed amount, or both	Sometimes
Gateway fee	Gateway or processor	Transmitting payment data between checkout and processing systems	Per transaction, monthly, bundled, or none separately	Sometimes
Website subscription	Website builder	Hosting, site tools, commerce features and other plan functionality	Usually recurring	By changing plans, but it is not automatically a transaction fee
Merchant-account costs	Acquirer/processor and related vendors	Processing and contracted account services	Varies	Often negotiable or dependent on provider

Platform transaction fee

A platform transaction fee is imposed by the ecommerce or website platform under its own pricing rules.

It may apply only on certain plans, only when particular payment providers are used, or only to specific types of products. It can also change as the merchant moves to a higher subscription tier.

Card processing fee

The processing charge pays for actually moving the card transaction through the payments system.

Under a bundled flat-rate arrangement, the merchant might simply see something such as “X% + Y¢.” Behind that rate are economics that can include interchange paid to issuers, card-network fees and the payment provider’s own margin.

Under interchange-plus pricing, those components are more visible:

Interchange + network assessments/fees + processor markup = processing cost

There can still be other charges outside that expression.

Gateway fee

The gateway is the technology layer that carries payment information between the customer-facing checkout and the processing infrastructure.

Some processors bundle the gateway into their processing price. Other merchant setups have a separate gateway account with its own monthly or transaction charge.

Monthly platform subscription

Your $30, $80 or $300 website plan is not automatically a “transaction fee.”

It is a recurring platform expense. However, the incremental cost of moving to a more expensive plan becomes relevant when that upgrade lowers your transaction percentage.

Why Can Two Payment Fees Apply to One Sale?

Because two different services can be priced independently.

The builder may charge for use of its commerce platform or for routing the transaction through an outside provider. The processor then separately charges for accepting and settling the card.

Squarespace describes this distinction explicitly: payment-processing rates are controlled by the payment processor, while Squarespace transaction fees depend on the billing plan and what the merchant sells.

Shopify likewise states that third-party transaction fees are in addition to processing charges imposed by the outside payment provider. Its documentation says these fees cover Shopify’s checkout platform and integration with external providers.

A hypothetical $100 sale

Assume, purely for illustration:

• Gross sale: $100.00
• Platform transaction fee: 2%
• Processing fee: 2.9% + $0.30

The math is:

Gross sale: $100.00
− platform fee: $2.00
− processor fee: $3.20
= approximately $94.80 remaining

That $94.80 is not profit. Product cost, shipping, advertising, tax obligations, refunds and operating expenses still come afterward.

The critical point is that a merchant who notices only the 2.9% + $0.30 processing rate has missed another $2 on the same $100 order.

Where do the charges appear?

That depends on the architecture.

A builder fee might appear on the platform invoice while the processor deducts its fee before the payout. With an integrated native payment system, several deductions may instead be visible in one financial dashboard.

BigCommerce’s current Open Payment Provider Fee, for example, is billed by BigCommerce as a separate monthly invoice item and is expressly separate from the provider’s processing charges.

This difference in reporting is one reason owners mistake multiple charges for one processing fee.

Why Does the Builder Charge an Extra Percentage?

There is no single answer that applies to every company.

The useful evidence is the pricing policy a builder publishes, not speculation about its motives.

Shopify says its third-party transaction fee covers providing its checkout platform and integrating with external payment providers. Its fee changes by plan.

BigCommerce’s 2026 structure distinguishes between its designated Embedded Payment Providers and other “Open Payment Providers.” Orders processed through Embedded Payment Providers avoid the Open Payment Provider Fee, while qualifying Open Provider volume on self-service plans can generate an additional platform charge.

Common documented pricing structures therefore include:

• lower plan tiers carrying higher commerce percentages;
• incentives to use a preferred or deeply integrated payment solution;
• different economics for native versus outside providers;
• fees associated with maintaining checkout and payment-provider integrations;
• lower percentages at higher subscription tiers.

None of that means every builder charges an extra platform percentage.

WooCommerce provides a useful architectural contrast. Its current pricing page describes the core platform as having 0% revenue share and says merchants choose their processor, although hosting, extensions and payment-provider expenses can still apply.

What a Website Builder Transaction Fee Actually Costs You

A fee that looks small in percentage terms can become one of the larger variable costs in the store as volume grows.

The table below shows the additional platform fee only. It does not include card processing.

Monthly Sales	0.5% Platform Fee	1% Platform Fee	2% Platform Fee
$2,500	$12.50	$25	$50
$5,000	$25	$50	$100
$10,000	$50	$100	$200
$25,000	$125	$250	$500
$50,000	$250	$500	$1,000
$100,000	$500	$1,000	$2,000

At $50,000 per month, 2% is $12,000 a year.

At $100,000 per month, 0.5% alone is $6,000 a year.

This is why a scaling merchant should periodically recalculate website builder payment processing costs rather than assuming the setup chosen at launch is still economical.

How Platform Fees Step Down as Your Plan Gets More Expensive

Not every builder uses this model, and the economics of upgrading depend on more than the transaction percentage. Merchants comparing tiers should also consider the broader differences between free and paid website builder plans, including ecommerce features, integrations, support, and the ability to scale as sales increase.

Shopify

On current U.S.-dollar annual-plan pricing shown by Shopify, Basic is $29 per month, Grow $79 and Advanced $299. Shopify lists third-party-provider transaction rates of 2%, 1% and 0.6% respectively.

Shopify’s current third-party transaction fee rules explain that these fees can apply when a merchant uses an outside payment provider and are charged in addition to the processing fees imposed by that provider. The applicable rate depends on the Shopify plan and payment configuration.

Availability varies by country. Shopify tells merchants to check payment-gateway availability for their own location.

A useful real-world piece of math follows.

Moving from the U.S. annual Basic price of $29 to Grow at $79 adds $50 per month, while the published third-party-provider fee drops from 2% to 1%.

Ignoring every other difference:

$50 ÷ 0.01 = $5,000

So approximately $5,000 of monthly sales processed through the affected outside provider is the fee-only break-even point.

That calculation does not say Grow is universally the better plan at $5,000. It says the extra subscription cost and one-percentage-point platform-fee reduction offset one another there, assuming all other variables stay constant.

Squarespace

Squarespace is in a plan transition, which is exactly the kind of contradiction that can make older comparisons misleading.

Its current documentation says the newer plan family being rolled out uses a 2% commerce transaction fee on Basic and 0% on Core, Plus and Advanced. The older Business plan carries 3%, while Commerce Basic and Commerce Advanced have 0% commerce transaction fees.

Payment processing remains a separate cost. Current Squarespace Payments rates also differ by country and, for some card categories, by website plan.

Because account availability and plan pricing can vary during the rollout, use the actual upgrade price displayed in your account for the break-even calculation.

BigCommerce

BigCommerce changed its payment-fee structure on June 1, 2026.

Its Core, Growth and Scale self-service plans currently charge no Open Payment Provider Fee on orders routed through designated Embedded Payment Providers. Open Payment Providers can trigger rates of 2%, 1% and 0.6% respectively.

Current annual-plan monthly equivalents are $29 for Core, $79 for Growth and $299 for Scale; monthly billing is $39, $105 and $399. BigCommerce also imposes GMV thresholds and other plan mechanics, so merchants cannot analyze the payment percentage in isolation.

This is particularly important because older statements that BigCommerce “never charges transaction fees” no longer describe every self-service payment configuration.

WooCommerce

WooCommerce does not use the same hosted-builder revenue-share model.

Its current pricing page says the open-source core has no platform revenue share and lets merchants pick a processor. The tradeoff is that the merchant may separately incur hosting, extensions, gateway and payment-provider costs.

When Does Upgrading the Builder Plan Pay for Itself?

The basic formula is:

Monthly plan-price increase ÷ transaction-fee percentage-point reduction = approximate monthly sales needed to break even

Convert the percentage-point reduction into decimal form.

A drop from 2% to 1% is a 1-percentage-point reduction, or 0.01.

When Does Upgrading the Builder Plan Pay for Itself?

The figures below are hypothetical.

Current Platform Fee	Higher-Tier Fee	Monthly Upgrade Cost	Break-Even Sales	Net Savings at $10,000 Sales
2%	1%	$20	$2,000	$80
1.5%	0.5%	$50	$5,000	$50
0.5%	0%	$15	$3,000	$35

For row one:

$20 ÷ 0.01 = $2,000

At $10,000 in monthly sales, a one-point reduction saves $100. After the extra $20 plan cost, the merchant is ahead by $80.

For row two:

$50 ÷ 0.01 = $5,000

At $10,000, the fee reduction saves $100 and the plan costs $50 more, leaving a $50 net difference.

For row three:

$15 ÷ 0.005 = $3,000

At $10,000, the 0.5-point reduction saves $50, less the $15 upgrade, or $35.

This model should be expanded if the plan also changes the processor rate, gateway charge or other commerce expense.

When a Platform Fee Becomes More Expensive Than a Dedicated Merchant Setup

There is no defensible universal answer such as “switch at $10,000 per month.”

A dedicated merchant account can look attractive at one transaction mix and expensive at another.

The variables include:

• debit versus credit mix;
• rewards and premium cards;
• commercial cards;
• average ticket;
• number of transactions;
• domestic versus international cards;
• ecommerce versus manually keyed transactions;
• processor markup;
• network costs;
• gateway fees;
• monthly account charges;
• PCI-related fees where applicable;
• chargebacks;
• refunds;
• platform fees;
• currency conversion;
• account underwriting and reserve requirements.

The right starting metric is:

Effective payment rate = Total payment-related fees ÷ Gross card sales × 100

If $4,000 in relevant payment costs supported $100,000 of card sales:

$4,000 ÷ $100,000 × 100 = 4.00%

Do this calculation for the current architecture and every proposed architecture.

Builder/native setup

Include relevant items such as:

**platform transaction fee

• processor charges
• gateway/payment charges
• cross-border costs
• currency conversion
• relevant payment-related fixed expenses**

Dedicated setup

Include:

**interchange

• card-network assessments/fees
• processor markup
• gateway fees
• applicable monthly/account costs
• other relevant contracted charges**

Do not compare a builder’s complete 3% or 4% effective cost with “interchange” alone.

Interchange is one component of merchant-acquiring economics, not the entire bill.

Flat-Rate Payment Processing vs Interchange-Based Pricing

How flat-rate pricing works

Flat-rate providers typically quote a bundled rate such as a percentage plus a fixed amount.

The merchant does not need to calculate separate interchange categories for every card. That simplicity can be particularly valuable for a new or low-volume store.

Advantages can include:

• predictable advertised pricing;
• simple onboarding;
• limited statement complexity;
• integrated checkout and reporting;
• fewer separate vendors.

The downside is that the bundled rate does not necessarily track the underlying cost of every card closely.

How interchange-based pricing works

An interchange-plus merchant arrangement commonly exposes more of the underlying structure:

interchange + network fees + processor markup

Other gateway, authorization or account charges may remain.

A merchant with favorable card mix and sufficient volume can sometimes obtain better economics this way, but that is a scenario to calculate—not a universal promise.

Why card mix changes the answer

A processor pays different underlying amounts depending on variables such as card type, transaction environment and qualification.

A store dominated by one card mix may therefore perform very differently under interchange-based pricing from another merchant with the same monthly sales volume.

Factor	Flat-Rate/Aggregator	Interchange-Based Merchant Account
Pricing simplicity	Usually high	Lower; statements can be more detailed
Cost transparency	Often bundled	Underlying components more visible
Low-volume convenience	Often attractive	Fixed costs may matter more
High-volume economics	Can remain competitive, but should be reviewed	Can become attractive for some merchants
Card-mix sensitivity	Less visible to merchant	Directly affects effective cost
Underwriting	Often streamlined	Can involve more formal underwriting
Funding/reserve policies	Provider-specific	Provider/acquirer-specific
Gateway requirements	Often integrated	May require separate or supported gateway
Contract considerations	Vary	Pricing, term and ancillary charges require review

A merchant should request an actual schedule and model it against recent transaction data.

How to Bring Your Own Payment Setup to a Website Builder

Bringing your own payment setup usually means connecting a builder-supported third-party processor, linking a compatible gateway to a dedicated merchant account, or using a hosted checkout outside the builder. The exact method depends on what your website builder allows.

Follow this process:

1. Check your builder’s supported payment providers: Open the payment or checkout settings and confirm which processors and gateways are available for your country and plan.
2. Confirm whether the builder still charges a platform fee: A third-party gateway does not automatically remove the builder’s transaction fee. Check the current plan terms before switching.
3. Choose the payment architecture: You may be able to use:
   • another supported processor;
   • a gateway connected to your merchant account;
   • a hosted checkout or payment link;
   • a plugin or app;
   • an API-based integration for more advanced setups.
4. Open or configure the processor account: Complete underwriting where required, connect the settlement bank account, and obtain the gateway or API credentials.
5. Connect it inside the builder: Use the builder’s official integration rather than adding raw card fields manually.
6. Configure payment methods: Confirm cards, Apple Pay, Google Pay, PayPal, subscriptions, saved cards, currencies, and other methods you actually need.
7. Run test transactions: Test a successful payment, decline, full refund, partial refund, wallet payment, and subscription transaction if applicable.
8. Verify order and payout reporting: Confirm that the builder order ID, gateway transaction ID, processor record, payout, and bank deposit can all be matched.
9. Check PCI responsibilities: Hosted or embedded payment tools can reduce how much card data your site handles, but they do not automatically remove all PCI DSS obligations.
10. Switch live traffic only after reconciliation works: Keep the old setup available until you understand what happens to existing subscriptions, saved payment credentials, refunds, and historical transactions.

How Major Builder Payment Setups Differ

The table reflects official documentation reviewed on September 21, 2026.

Builder	Native Payments Available?	Third-Party Provider Support	Extra Platform Fee Possible?	Does Plan Matter?	Key Limitation
Shopify	Yes, where Shopify Payments is supported	Yes; options vary by market	Yes, with affected third-party transactions	Yes	Provider availability and fees vary by country; direct vs external checkout differs
Squarespace	Yes, in supported countries	Stripe and PayPal for online commerce; Square for supported in-person POS	Yes on fee-bearing website plans	Yes	New and legacy plan families coexist during rollout
BigCommerce	Yes/partner ecosystem	Broad provider ecosystem	Yes for Open Payment Providers on self-service plans	Yes	Provider classification as Embedded vs Open now matters
WooCommerce	WooPayments available, but architecture is open	Broad gateway/plugin ecosystem	Core WooCommerce has no platform revenue share	Not in the same hosted-builder sense	Merchant manages more hosting, extensions and integration choices

Shopify’s outside-provider selection is location-dependent, and standalone Stripe is not generally offered as an alternative in markets where Shopify Payments itself is available.

Squarespace currently supports Squarespace Payments, Stripe and PayPal for relevant online payment configurations, with availability varying by country.

BigCommerce currently designates 21 Embedded Payment Providers whose orders are not subject to its Open Payment Provider Fee; providers outside that list are treated differently on applicable self-service plans.

Pricing or availability varies by plan, location, provider and account. Verify the current terms in your builder dashboard before switching.

What Changes When You Replace the Builder’s Default Payment Setup?

Do not judge a gateway migration only by the percentage.

The cheaper gateway is not cheaper if it breaks subscriptions, removes a wallet that converts well or creates hours of manual reconciliation every week.

Checkout location

Some integrations keep the card form inside the builder checkout.

Others redirect shoppers to an outside hosted payment page.

Shopify specifically distinguishes direct third-party providers, where the purchase can be completed on the store, from external providers that require an outside checkout page.

Wallet support

Check whether the new configuration preserves:

• Apple Pay;
• Google Pay;
• PayPal;
• accelerated checkout;
• local payment methods;
• buy-now-pay-later options.

Do not assume support at the processor level means the builder integration exposes the feature.

Saved cards

Tokenized stored cards require compatibility between the checkout, gateway and processor.

Existing tokens may not be portable to a new processor.

Subscriptions

Recurring billing deserves its own migration plan.

Changing the payment provider can leave existing customer subscriptions attached to the old processor even when new transactions flow through the new system.

Squarespace, for example, says that when an existing Stripe-connected site switches to Squarespace Payments, the Stripe account remains active for existing subscriptions and those transactions do not move into the Squarespace Payments dashboard.

Ask what happens to active subscriptions before disconnecting anything.

Fraud tools

Changing providers can change:

• address verification;
• card verification;
• device signals;
• 3-D Secure behavior;
• fraud scoring;
• manual-review workflows;
• rules engines.

Tax and shipping

The payment gateway normally should not decide the order tax or shipping charge independently from the store.

Test that the builder sends the correct final total after discounts, tax and shipping.

Authorization and capture

Some businesses authorize first and capture later.

If you use that workflow for preorders, custom goods or delayed fulfillment, make sure the replacement integration supports the same behavior.

Refunds

Confirm whether staff can still initiate refunds inside the builder, whether partial refunds sync, and whether the processor dashboard becomes the authoritative system.

Order synchronization

A payment that succeeded at the gateway but failed to update the builder can leave an order showing “unpaid.”

The reverse problem is equally dangerous: an order may appear accepted even though the processor rejected the payment.

Descriptors

Place a real test purchase and inspect what appears on the card statement.

An unfamiliar descriptor is a preventable source of “I don’t recognize this purchase” disputes.

Reporting

Determine whether you can export:

• builder order number;
• processor transaction ID;
• payment status;
• gross transaction amount;
• fees;
• net amount;
• refund ID;
• payout ID;
• settlement date.

These fields matter more than a pretty dashboard once you reconcile hundreds of transactions.

The Costs You Will Miss If You Compare Only the Headline Percentage

Before you change anything, ask about every fee or cash-flow rule that could affect your real economics.

Not every provider charges every item below.

Cost	What It Means	When It Usually Matters	Where to Verify It
Platform transaction fee	Builder percentage on eligible sales	Fee-bearing plans or outside-provider configurations	Builder pricing/help center
Processor fee	Cost of accepting the payment	Every processed transaction	Processor fee schedule
Gateway fee	Charge for payment gateway service	Separate gateway setups	Gateway contract
Chargeback fee	Cost associated with a dispute	Merchants with disputes	Processor/acquirer terms
Refund-related cost	Original processing cost may not be returned	High-refund businesses	Refund policy
Cross-border markup	Additional charge for foreign-issued cards	International customer base	Processor fee schedule
FX conversion	Cost of changing one currency into another	Multi-currency selling	Processor/settlement terms
Reserve/hold	Funds temporarily unavailable	Elevated processing risk	Processor dashboard/contract
Monthly account fee	Recurring payment-services cost	Dedicated setups	Merchant agreement

Refund costs

Never assume the original processing charge comes back.

Stripe’s current standard-pricing terms state that its original payment-processing, Connect and currency-conversion fees are not returned when a card payment is refunded, although standard card refunds generally do not add a separate refund charge.

Squarespace says its platform transaction fee is returned when an eligible order is refunded, while the Squarespace Payments processing rate is not.

Shopify says its third-party transaction fees are not returned when the merchant refunds an order.

Those are different policies covering different fees.

Cross-border and FX

International pricing can quickly alter a comparison.

For one current U.S. processor example, Stripe lists an additional 1.5% for international cards and 1% where currency conversion is required on its standard U.S. card pricing.

Do not transfer those numbers to another processor or country. Check the fee schedule that applies to your own legal entity and settlement currency.

Failed payments and subscription recovery

A subscription business should ask whether retry tools, account updater, dunning or recurring-billing products have separate fees.

A lower card rate can be offset by additional subscription-platform costs.

Payout Delays, Reserves and Holds Are Different Things

These terms are frequently mixed together.

Normal payout timing

This is the normal interval between successful processing and the money becoming eligible for transfer to your bank.

Every processor has its own settlement and payout mechanics.

Temporary review or payout hold

A provider may temporarily delay payouts while it verifies business information, reviews unusual activity or investigates another account issue.

That is not automatically a reserve.

Rolling reserve

A defined percentage of continuing transactions is held for a stated period, with each reserved amount generally released according to its own aging schedule.

Fixed or one-time reserve

A specific amount is retained rather than a percentage being withheld from each new transaction.

Delayed settlement

The provider may extend the normal time before transactions become available for payout.

Again, that is not necessarily the same structure as a reserve.

Shopify’s current documentation distinguishes reserves from payout holds and says risk factors can include extended billing cycles, higher chargebacks, elevated refunds, long-delivery industries and significant volume surges.

Wix similarly distinguishes normal payouts, rolling or one-time reserves, and payouts placed on hold.

Businesses selling future delivery, custom goods, large-ticket items, annual subscriptions or other delayed-fulfillment products should therefore evaluate cash availability, not merely processing percentage.

Stay, Upgrade, or Bring Your Own Gateway?

Use this as a research matrix rather than a recommendation.

Situation	What to Investigate
Very low sales volume	Simplicity versus new fixed monthly costs
Growing sales	Plan-upgrade break-even
High platform fee	Native payments versus third-party-provider rules
High average ticket	Percentage costs, underwriting and dispute exposure
Large transaction volume	Interchange-based pricing and negotiated rates
International customers	International-card and FX charges
Subscription business	Recurring-payment and token compatibility
High refund volume	Whether original processing fees are returned
Multiple currencies	Presentment, settlement and conversion
Need custom checkout	Gateway, plugin and API capabilities

If your goal is to avoid website builder payment fees, first determine which fee you are actually trying to remove.

Changing the processor cannot fix a platform charge that the builder still imposes on the new provider.

Likewise, paying for a more expensive builder plan makes little sense if your sales are below the plan-upgrade break-even.

Test the Checkout Before Sending Real Customers Through It

At minimum, test:

• one successful desktop purchase;
• one successful mobile purchase;
• one card decline;
• one fraud-rule rejection where testing supports it;
• a full refund;
• a partial refund;
• an authorization followed by capture where applicable;
• an authorization followed by void;
• each enabled wallet;
• international checkout where relevant;
• subscription signup;
• recurring charge behavior;
• cancellation;
• tax calculation;
• shipping calculation;
• discount codes;
• confirmation emails;
• order-status synchronization;
• descriptor display where a real small transaction is necessary;
• payout reconciliation.

A technically “connected” gateway is not necessarily a production-ready gateway.

How to Reconcile Builder Orders With Processor Payouts

A common accounting mistake is expecting:

order total = bank deposit

Usually it does not.

A payout might combine several customer transactions and then subtract:

• processing fees;
• refunds;
• disputes;
• reserves;
• prior negative balances;
• adjustments.

Simple reconciliation example

Suppose your builder shows these three orders:

• Order 1001: $120
• Order 1002: $80
• Order 1003: $200

Gross orders are $400.

Your workflow should be able to follow each payment through:

Builder order number
→ gateway transaction ID
→ processor transaction record
→ payout or settlement batch
→ bank deposit
→ accounting entry

Now suppose the payout contains:

• $400 in gross charges;
• $12 in processing costs;
• a $50 refund from an earlier order.

The bank receives:

$400 − $12 − $50 = $338

The $338 deposit is not evidence that the three new orders totaled $338. It is a settlement event containing several components.

Your accounting system should retain gross revenue and payment expenses separately rather than posting only the net deposit as sales.

Exact IDs and payout structures differ by provider.

How Refunds Work After a Gateway Change

Before switching, determine where the refund is supposed to begin.

Possible models include:

• refund from the builder dashboard;
• refund from the processor dashboard;
• builder initiates the refund through the processor;
• manual processor refund followed by a separate builder status update.

The risky setup is one where employees can perform refunds in either system but only one direction synchronizes.

Full refunds

Verify:

1. the customer receives the money;
2. the order status changes correctly;
3. inventory behavior is correct;
4. fees are booked correctly;
5. the refund appears in reconciliation.

Partial refunds

A $20 partial refund against a $100 order should not mark the entire payment as fully refunded.

Check both the builder and processor records.

Original fees

Never assume the processor returns its original charge.

As noted earlier, current Stripe standard pricing, Squarespace Payments and Shopify third-party transaction fees each have their own refund treatment. Check the policy applying to the exact payment path you use.

FAQs

Website Builder Transaction Fees Explained: What to Do Next

Pull three things before making a payment decision:

1. your current builder plan and its transaction-fee rules;
2. at least several months of processor or payout data;
3. the complete fee schedule for the alternative setup.

Calculate the annual platform percentage at your real volume. Then calculate any upgrade break-even. Finally, model the proposed processor with its fixed fees, card mix, international charges, refunds, gateway expenses and any builder fee that survives the switch.

For a low-volume beginner, the integrated builder setup may remain economically sensible because simplicity and low fixed overhead matter.

For a scaling merchant, the same extra percentage can become substantial enough that a plan change deserves attention.

At higher volume, comparing native flat-rate processing with interchange-based acquiring can be worthwhile—but only on total effective cost.

And if you decide to connect your own payment gateway to a website builder, treat it as an operational migration. Prove the checkout, refunds, subscriptions, reporting, payout flow and PCI responsibilities before sending normal customer traffic through it.

That is the practical value of having website builder transaction fees explained correctly: you can stop comparing isolated percentages and start comparing the complete payment architecture.