Refund Fees Explained

Refund Fees Explained: What Returns and Cancellations Really Cost Merchants

A merchant processes 1,000 successful orders. Later, 100 of them are refunded.

At first glance, the payment economics may still look like the economics of 1,000 transactions. But the merchant kept the revenue from only 900 orders. If some of the payment cost attached to the other 100 transactions is not returned, that cost has to be absorbed by the commerce that remains.

That is the central problem with refund fees: a refund can reverse the sale without returning the payment economics to zero.

For a low-refund merchant, the difference may be modest. For ecommerce, travel, marketplace, or other businesses where returns and cancellations are commercially significant, it can change which payment provider is actually cheaper.

The right question is therefore not simply:

“What does my provider charge to issue a refund?”

It is:

“After accounting for every order that was later reversed, what did payments actually cost me for each order I kept?”

A refund is another payment event, not an accounting reset

A refund is related to the original purchase, but it should not be thought of as an “undo” button that automatically erases the original transaction's costs.

Card-network rules illustrate why the distinction matters. Mastercard's June 2026 Transaction Processing Rules describe a refund as a transaction used to credit funds to a cardholder for returned products, canceled services, or a price adjustment. Visa likewise describes a refund through a credit transaction tied to a previous purchase.

Commercial pricing sits on top of those transaction mechanics. Depending on the merchant's provider, payment method, geography, product, and negotiated agreement, a refund can involve several economically different components:

•a separate fee for processing the refund;

•some or all of the original payment fee remaining with the provider;

•payment-method or third-party refund costs;

•currency-related effects where currencies differ;

•and internal operational work required to approve, process, reconcile, and support the refund.

These costs should not be collapsed into one generic “refund fee.”

Refund-specific fee

This is an additional charge triggered by processing the refund itself.

It might be structured as a fixed amount per refund, a percentage, another method-specific charge, or a combination. Whether one exists at all is provider- and contract-specific.

Unrecovered original processing cost

This is different.

The merchant already paid to process the original sale. If all or part of that charge is not returned after the transaction is refunded, the original fee becomes a cost attached to an order that produced no retained revenue.

That distinction can matter more than the headline refund charge.

A provider with a zero-dollar refund-event fee but no recovery of the original processing cost is not necessarily providing economically “free refunds.”

What happens to the original payment fee?

There is no safe universal answer.

Merchants should determine, from their own commercial terms, whether a full refund results in:

•full recovery of the original payment fee;

•partial recovery of certain components;

•no recovery of the original fee;

•an additional refund-processing charge;

•method-specific treatment that changes the answer by transaction.

That distinction is commercially important.

Suppose an order generates a $3 original processing charge and is later fully refunded:

•If $3 is returned and there is no refund-specific charge, payment cost associated with that transaction may approach zero.

•If the original $3 is retained, the merchant has a $3 payment cost despite keeping no revenue.

•If the original $3 is retained and another $0.25 refund charge applies, the payment-related cost becomes $3.25.

•If internal support and reconciliation work is included in the merchant's economic model, the all-in refund cost is higher still.

The numbers above are examples, not live provider pricing.

Refund fees and chargebacks are not the same thing

A merchant refund and a chargeback can both remove transaction value from the merchant, but they are different events.

A refund is generally a merchant/provider-initiated return of funds associated with a purchase. A dispute begins through the cardholder's issuer and can result in the value of the transaction being reversed through the dispute process. Visa describes disputes as the reversal of all or part of transaction value by the issuer to the acquirer and, ordinarily, onward to the merchant.

The economics should therefore remain separate:

Refund economics

= original payment-fee treatment

•refund-event charges

•attributable method/FX cost

•operational handling

Chargeback economics

= dispute fee

•transaction loss where applicable

•goods or service loss

•dispute operations

•other attributable loss

A voluntary refund should not be booked analytically as a chargeback simply because both reduce net revenue.

Full refunds are simpler than partial refunds

With a full refund, the revenue denominator is straightforward: the order generated no retained sales value.

Partial refunds complicate the model.

Imagine a customer pays $200 and later receives $50 back. The merchant retained $150 of revenue, so classifying the entire order as either “retained” or “refunded” loses useful information.

For merchants with meaningful partial-refund activity, track both:

•order-based refund metrics, and

•value-based refund metrics.

The article's primary unit-economics measure—payment cost per retained order—is still useful. But it should be paired with payment cost as a percentage of net retained revenue when partial refunds are common.

That prevents a $5 partial goodwill credit and a $200 full cancellation from being treated as economically equivalent.

Multiple refunds introduce an event-count problem

Partial refunds also create another possible cost driver: the number of refund events.

Suppose an order eventually has $60 returned.

Economically, these are not necessarily equivalent:

•one $60 refund;

•two $30 refunds;

•three $20 refunds.

If a provider charges a fixed amount per refund event, splitting the same refunded value across several refund transactions can increase cost.

If pricing instead depends only on refunded value, event count may matter less.

And if the payment method or provider does not support repeated partial refunds, the scenario may not be possible at all.

The contract and technical documentation must answer the question. Do not infer it from the word “refund.”

For this reason, refund analytics should track both:

refunded amount

and

number of refund events.

Merchant initiation is not customer receipt

Another distinction is operational rather than purely financial.

A merchant can successfully initiate a refund before the customer's bank has made the funds visible to the customer.

The analytical point is broader: measure separately—

•refund requested;

•refund approved;

•refund submitted to the payment system;

•refund confirmed by the provider;

•customer receipt where observable.

Otherwise customer-support teams may call a refund “late” while payment operations calls the same refund “complete.”

Payment method and provider rules can change the economics

There is no single global refund model.

Variables can include:

•whether refunds are supported;

•whether partial refunds are supported;

•the permitted refund window;

•whether the refund must return through the original method;

•whether the original transaction fee is returned;

•whether a separate refund charge applies;

•whether each partial refund counts as a separately billable event;

•whether an alternative refund method generates additional cost;

•and how currency differences are treated.

Network mechanics also vary. Mastercard's current rules, for example, generally require its refund transaction to use the same currency as the related purchase, subject to the rule's qualifications and regional variations. Visa's rules contain their own requirements and exceptions for credit refunds. Those network rules should not be generalized to non-card payment methods.

That is why a merchant with 12 payment methods should not calculate refund economics from one blended PSP number and assume every method behaves the same.

Build a method-level view first. Blend it only afterward.

The Refund Cost Model

For each refunded order, classify cost into four buckets.

•Unrecovered original payment cost

Original payment fee × portion not recovered

For an order whose original fee was $3.00:

•100% fee recovery → unrecovered cost = $0

•50% fee recovery → unrecovered cost = $1.50

•0% fee recovery → unrecovered cost = $3.00

The recovery treatment must come from the actual commercial arrangement.

•Refund-specific cost

Include only charges triggered by the refund itself:

**fixed refund fee

•percentage-based refund fee

•method-specific refund charge**

If pricing is per event, multiply the fixed element by the number of refund transactions—not merely the number of orders affected.

•Method and FX effects

Where relevant, identify separately:

•payment-method refund costs;

•third-party processor costs;

•currency-conversion charges;

•exchange-rate differences attributable to the refund.

Do not assume a currency cost exists simply because the original purchase was cross-border.

For detailed currency treatment, link to Refunds and Currency Conversion rather than turning this article into an FX guide.

•Operational handling

A financially complete merchant model may also include attributable internal work, such as:

•support review;

•fraud or policy review;

•manual refund initiation;

•finance reconciliation;

•exception handling;

•customer follow-up.

Use a documented internal methodology if labor is monetized.

Do not invent an hourly cost.

Refund-related cost

For each refunded order:

**Refund-related cost

= unrecovered original payment cost

•refund-specific charges

•attributable method/FX effects

•attributable operational handling**

Then calculate the article's primary metric:

Refund-adjusted payment cost per retained order

Total payment and refund cost

÷ retained completed orders

And a useful companion metric:

Payment cost as a percentage of net revenue

Total payment and refund cost

÷ revenue retained after refunds

Avoid double counting

There are two valid ways to build the numerator, but they should not be mixed.

If total original processing fees across all transactions are already included, do not add “unrecovered original fees” again.

Alternatively, build the numerator from:

**processing fees on retained transactions

•unrecovered original fees on refunded transactions

•refund-event charges

•other included refund costs**

Both approaches can arrive at the same answer when applied consistently.

What happens when the denominator changes?

Consider a deliberately hypothetical merchant.

•1,000 completed orders

•$100 average order value

•original payment pricing: 2.5% + $0.25

•original payment fee per order: $2.75

•no recovery of original payment fees after refund

•hypothetical separate refund fee: $0.25 per refund

•all refunds are full refunds

•no FX or operational cost included

At zero refunds, payment fees equal:

1,000 × $2.75 = $2,750

That is 2.75% of $100,000 in retained revenue.

Now change only the refund rate:

Refund rate

Retained orders

Net retained revenue

Total payment/refund fees

Cost per retained order

Cost as % of net revenue

0%

1,000

$100,000

$2,750.00

$2.75

2.75%

5%

950

$95,000

$2,762.50

$2.91

2.91%

10%

900

$90,000

$2,775.00

$3.08

3.08%

20%

800

$80,000

$2,800.00

$3.50

3.50%

30%

700

$70,000

$2,825.00

$4.04

4.04%

The separate refund charge barely changes in absolute terms.

The more important effect is the denominator.

At a 10% refund rate, an apparent 2.75% original payment cost becomes approximately 3.08% of net retained revenue under these assumptions.

At 30%, it is approximately 4.04%.

The processing rate did not change.

The commerce over which the merchant can economically absorb that cost did.

That is why refund-heavy merchants can misread payment pricing when they divide cost by gross transactions rather than retained commerce.

High-refund merchants need a different comparison

Ecommerce and retail

A merchant with material returns should model provider proposals against its own refund profile.

The critical questions are not just transaction rate and authorization performance. They include:

•How many completed orders are later refunded?

•What percentage are full versus partial?

•How many refund transactions occur per affected order?

•Which original payment fees are recovered?

•Which methods create separate refund charges?

•How much net revenue remains?

Two providers with the same headline processing rate can therefore produce different economics after returns.

Travel

Cancellations can be especially important when ticket values are high, fulfillment occurs well after payment, or payment and settlement currencies differ.

That does not automatically mean travel refunds are more expensive per transaction.

It means the merchant should model the actual cancellation profile, transaction value, method mix, currency path, and contract terms instead of using a generic refund-rate assumption.

Marketplaces

For marketplaces, one customer refund can interact with seller balances, commissions, reserves, or previously initiated disbursements.

Those downstream payout mechanics belong in the relevant payout or marketplace-economics analysis.

For this article, keep the question narrower:

What payment cost remained attached to the customer transaction after its value was refunded?

What merchants should compare between providers

A refund comparison should be a structured pricing exercise, not a binary “refund fee: yes/no” field.

For every provider and payment method, record:

Question

Why it matters

Is there a separate refund-event fee?

Establishes the direct incremental charge.

Is it fixed, percentage-based, or both?

Determines whether transaction count or refunded value drives cost.

Are original processing fees returned?

Can be the largest payment-cost component of a refunded order.

If partially returned, which components are recovered?

Prevents misleading all-or-nothing assumptions.

Are full and partial refunds priced differently?

Important for merchants using adjustments and goodwill credits.

Can an order receive multiple partial refunds?

Establishes operational capability and potential event count.

Is each refund event separately charged?

Determines whether refund fragmentation raises cost.

Do rules differ by payment method?

Blended assumptions can hide expensive methods.

What happens if the original method cannot accept the refund?

Alternative refund routes may change cost.

Are FX or currency-adjustment costs possible?

Relevant to multi-currency commerce.

Who bears costs for provider-initiated refunds?

Important where the provider can refund independently under agreed terms.

What refund window applies?

Affects operational policy and method availability.

What reporting fields identify fees and reversals?

Required for reconciliation and measurement.

Measure refunds against retained commerce

At minimum, a finance or payment-operations dashboard should track six measures from the editorial brief.

Refund rate

Fully refunded completed orders

÷ completed paid orders

When partial refunds are material, add a second metric:

Refunded value

÷ captured payment value

Refund-specific fee

Track:

total refund-event fees

÷ refund events

If multiple refund events can occur against one order, also track:

refund events

÷ refunded orders

Original fee recovery

Measure both:

original fees recovered

÷ original fees attributable to refunded transactions

and:

unrecovered original fees per refunded order

Partial-refund incidence

orders receiving partial refunds

÷ all refunded orders

Also monitor the percentage of refunded value represented by partial refunds.

Refund-adjusted payment cost per retained order

Total payment/refund cost

÷ retained completed orders

This is the article's primary denominator.

Refund-adjusted payment cost as a percentage of net revenue

Total payment/refund cost

÷ net revenue after refunds

This becomes particularly useful when partial refunds or widely different order values make an order-count denominator less representative.

Operational data matters as much as contract language

A contract explains what can be charged.

Reconciliation data shows what was charged.

A merchant should therefore test its refund model against:

•provider invoices;

•settlement or payout reports;

•transaction exports;

•refund IDs;

•original transaction IDs;

•payment-method codes;

•refund amounts;

•currencies;

•refund-event fees;

•original-fee credits;

•other adjustments.

Sample several full refunds, partial refunds, and—where supported—orders with multiple refund events.

The objective is to reconcile one order all the way from:

capture → original fee → refund → fee adjustment → settlement impact

If finance cannot perform that trace, the merchant does not yet have enough information to calculate refund-adjusted payment economics reliably.

Those capabilities address the operational side of refund management.

The commercial side still requires the merchant's current fee schedule.

•its negotiated pricing and fee schedule;

•the actual payment methods enabled;

•method-level refund capability;

•observed original-fee recovery;

•refund-event charges appearing in reconciliation;

•the merchant's historical refund rate and partial-refund profile.

Final recommendation: price payments against retained commerce

A payment transaction that is later refunded should not disappear from payment-cost analysis simply because it disappeared from revenue.

For merchants with meaningful returns or cancellations, provider pricing should be modeled in three stages:

First, calculate what it costs to process the original transaction.

Second, calculate what payment and operational cost survives when that transaction is refunded.

Third, allocate the resulting cost across the orders and revenue the merchant actually retained.

That changes the commercial question.

Instead of asking which PSP has the lowest transaction rate, ask:

Which provider produces the lowest defensible payment cost per retained order under our actual refund behavior?

For a merchant with a low refund rate, the answer may barely differ from the headline rate.

For a merchant with a high refund rate, it can change the economics of the provider relationship entirely.

Refund Fees Explained: What Returns and Cancellations Really Cost Merchants

Editorial brief interpretation

Field

Decision

Ancillary-cost problem

A refunded sale can reverse revenue without reversing all of the payment cost incurred to create that sale.

Cost classification

Primarily an event-based direct cost, plus potentially unrecovered original processing fees, method/FX effects, and operational handling cost.

Trigger

A merchant, provider, or other authorized party processes a refund against a completed payment.

Cost owner

The merchant bears the economic cost; the PSP, acquirer, payment method, processor, or other participant may impose individual fee components according to the applicable commercial terms.

Evidence anchor

Revenue can disappear while some payment-related cost remains.

Editorial position

Payment pricing for refund-heavy merchants should be evaluated against retained commerce, not gross transaction count alone.

Assumption challenged

“When the customer gets their money back, the merchant gets its payment fees back too.”

Merchant decision

Compare providers using the merchant's actual refund profile and calculate refund-adjusted payment cost per retained order and as a percentage of net revenue.

Selected format

Refund-adjusted unit-economics analysis.

Structural rationale

Follow the economics of one successful payment through a later refund, then change the denominator from gross transactions to retained orders.

This interpretation follows the brief's instruction that the article own refund-event economics, distinguish refund-specific charges from original-fee treatment, and build toward refund-adjusted payment cost per retained order.

Proposed architecture

•The sale disappeared; did the payment cost?

•A refund is another payment event, not an accounting reset

•What happens to the original processing cost?

•Full, partial, and multiple refunds

•Why payment method and provider rules matter

•The Refund Cost Model

•How the denominator changes the economics

•High-refund merchant scenarios

•What merchants should compare in PSP terms

•How to measure refund-adjusted payment economics

•Final recommendation: price payments against retained commerce

Original practical asset: Refund Cost Model

Per refunded order

A. Unrecovered original payment cost

Original payment fee × unrecovered percentage

B. Refund-event cost

Fixed refund charge × number of refund events

•percentage refund charge × refunded value

C. Method/FX cost

Verified method-specific and currency-related costs attributable to refund

D. Operational handling

Documented attributable internal cost

Total refund-related cost = A + B + C + D

Merchant-level metrics

Refund-adjusted payment cost per retained order

Total included payment/refund cost

÷ retained completed orders

Refund-adjusted payment cost as % of net revenue

Total included payment/refund cost

÷ net retained revenue

Recommended implementation fields

•Order ID

•Original transaction ID

•Payment method

•Original captured amount

•Original currency

•Original processing fee

•Refund ID

•Refund date

•Refund amount

•Refund currency

•Full/partial flag

•Refund event number

•Refund-event fee

•Original-fee credit

•Other method cost

•FX adjustment where attributable

•Operational exception flag

•Net retained revenue

•Settlement/reconciliation reference

SEO metadata

H1: Refund Fees Explained: What Returns and Cancellations Really Cost Merchants

Meta description: Learn how refund fees, unrecovered processing charges, partial refunds, payment methods, FX and operational costs change payment cost per retained order.

Suggested URL slug: /refund-fees-explained

Secondary keywords:

•payment refund fees

•PSP refund fees

•card processing refund fee

•merchant refund costs

•payment processor refund fees

•ecommerce refund processing cost

•refund transaction fees

•payment fee after refund

Related entities:

•refund transaction

•payment service provider

•payment processing fee

•partial refund

•cancellation

•payment method

•chargeback

•payment reconciliation

•net revenue

•retained order

•refund API

Article excerpt: A refunded sale does not necessarily erase the cost of processing it. This guide shows merchants how to separate refund-event charges from unrecovered original fees and calculate payment cost against the orders and revenue they actually retain.

Suggested structured data: Article plus BreadcrumbList. Add FAQPage only if a genuine FAQ section is added to the published version.

Internal links

Refunds for Cash Payments — use when discussing methods where the refund path differs materially from a standard card credit.

Refunds and Currency Conversion — link from the FX section rather than duplicating currency mechanics.

Payment Method Fees — link where method-level fee structures require broader explanation.

PSP Contract Fees — link when explaining how refund terms fit into the wider provider fee schedule.

Chargeback Fees Explained — optional contextual link from the refund-versus-chargeback distinction, without reproducing that article's dispute-cost model.

Authoritative source recommendations

•Merchant-specific signed agreement and fee schedule — primary source for actual refund charges, original-fee treatment and any negotiated terms.

•Mastercard Transaction Processing Rules, 9 June 2026 — authoritative card-network source for Mastercard refund-transaction mechanics.

•Visa Core Rules and Visa Product and Service Rules, effective 18 April 2026 — authoritative source for Visa credit-refund mechanics and relevant regional qualifications.

•Visa dispute documentation — useful only for the narrow refund-versus-chargeback distinction.

Supporting visual

Refund Cost Model waterfall

Panel 1 — Original sale

Customer pays $100

→ merchant records $100 gross sale

→ original payment fee is incurred

Panel 2 — Refund event

$100 returned to customer

→ retained revenue falls to $0

Panel 3 — Costs that may remain

•unrecovered original processing fee

•refund-specific charge

•method/FX effect

•operational handling

Panel 4 — Merchant denominator

Total payment/refund cost

÷ retained orders

Visual takeaway: The revenue can reverse while the payment cost does not.

Suggested alt text: “Refund Cost Model showing how unrecovered original processing fees, refund-specific charges, payment-method or FX costs and operational handling increase payment cost per retained order.”

Proposed author and review structure

Names should be added only after actual assignment; no contributor or completed review should be invented.

Primary reviewer: [Named Payment Operations Lead]

Financial-methodology reviewer: [Named Finance Analyst]

Optional operational reviewer: [Named Refund/CX Specialist]

Human contribution to request before publication: one anonymized refund-cost analysis showing original transaction fees, refund adjustments and the resulting cost per retained order from real reconciliation data.

Provider and contract fact-check items

Before publication, verify:

•Does the applicable merchant agreement contain a separate refund fee?

•Exact amount or rate.

•Currency.

•Fixed versus percentage structure.

•Whether the charge is per refund, per order or another unit.

•Original transaction-fee treatment after a full refund.

•Original transaction-fee treatment after a partial refund.

•Whether different original fee components receive different treatment.

•Whether multiple partial refunds are technically supported.

•Whether multiple refund events create multiple charges.

•Whether refund economics differ by payment method.

•Whether an alternative refund method creates additional processor cost.

•Applicable refund windows.

•Contract effective date.

•Whether terms differ by Merchant/MoR model, product, entity or geography.

•Whether any waiver is permanent or conditional.

These checks are consistent with the brief's requirement that provider-specific refund behavior be verified rather than generalized.

Refund-specific fact-check items

Confirm with current authoritative documentation:

•Full-refund mechanics.

•Partial-refund support.

•Maximum cumulative refundable amount.

•Multiple-refund behavior.

•Refund reversal/cancellation behavior.

•Original-payment linking requirements.

•Currency rules.

•Customer receipt timing.

•Refund status definitions.

•Manual versus API workflow.

•Refund-reporting fields.

•Treatment of unsuccessful or rejected refund attempts.

Merchant-model assumptions to obtain

A real merchant model requires:

•completed order count;

•gross payment volume;

•average and distribution of transaction values;

•full-refund rate;

•partial-refund incidence;

•refunded-value rate;

•average refund events per affected order;

•payment-method mix;

•geographic mix;

•currency mix;

•observed original-fee recovery;

•actual refund-event fees;

•attributable operational handling methodology;

•net revenue after refunds.

Do not substitute an industry-average refund rate for the merchant's own data when it is available.

Regulatory and contract-review flags

This article provides general information and does not constitute legal, regulatory, financial, tax, accounting, or contractual advice. Merchants should verify applicable fees and contractual obligations in their own agreement and seek qualified legal, financial, or payments advice where appropriate.

Specific legal review may be warranted for:

•statutory cancellation or refund rights;

•merchant refund-policy disclosures;

•network-rule interpretation;

•refund timing obligations;

•alternative refund methods;

•regional consumer-protection requirements.

Card-network rules should not be presented as if they govern every local payment method.

Amber-flag claims

The following statements should not be published without current verification:

A public support page says original transaction fees are not refunded, but it is dated 2020 and current merchant-specific fee schedules should control the publication claim.

No universal amount should be supplied without the applicable current fee schedule.

“Refunds are free.”

A zero separate refund fee would not establish zero refund cost if original fees, third-party costs or operations remain.

“All methods support partial refunds.”

“Multiple partial refunds are supported.”

Verify method and API behavior before claiming this.

“Every partial refund incurs another fixed fee.”

Only true where the applicable pricing is per refund event.

“Cross-border refunds create an FX loss.”

Possible in some structures, not universal.

“Customers receive refunds within X days.”

“Refund fees are negotiable.”

Some commercial terms may be negotiable, but negotiability cannot be guaranteed.

Before this draft is approved for publication:

•Confirm whether that treatment differs by product, payment method, geography, Merchant versus MoR arrangement, or negotiated contract.

•Verify how “Refund Costs” is presently defined in applicable agreements and fee schedules.

•Confirm current partial-refund support by payment method.

•Verify whether repeated partial refunds are supported and any limits.

•Confirm the current manual/API refund workflow.

•Verify current customer-facing refund timing language before quoting a number.

•Confirm which reporting fields allow merchants to reconcile original fees, refunds and adjustments.

•Do not publish confidential or merchant-negotiated rates.

Cluster sameness-audit fields

Title: Refund Fees Explained: What Returns and Cancellations Really Cost Merchants

First two sentences: A merchant processes 1,000 successful orders. Later, 100 of them are refunded.

Opening device: Denominator shift from 1,000 transactions to 900 retained orders.

Merchant cost problem: Revenue reverses while payment cost may remain.

Cost classification: Event-based direct cost plus unrecovered transaction and operational components.

Triggering event: Processing a refund against a completed payment.

Fee/cost owner: Merchant bears the economics; specific charges may be imposed by PSP/acquirer/method/processor.

Merchant archetype: High-refund ecommerce, travel and marketplace merchant.

H2 pattern: Transaction lifecycle → original-fee treatment → partial/multiple refunds → method variation → cost model → denominator analysis → comparison → measurement.

Primary format: Refund-adjusted unit economics.

Unique evidence anchor: Payment expense can remain after sale revenue has been reversed.

Editorial position: Payment pricing should be evaluated against retained commerce.

Merchant decision: Select or negotiate payment terms using actual refund-adjusted cost rather than headline transaction pricing.

Original framework: Refund Cost Model.

Primary metric: Refund-adjusted payment cost per retained order.

Secondary metric: Payment/refund cost as percentage of net retained revenue.

Conclusion: The relevant commercial comparison is the cost of payments for orders the merchant ultimately keeps.

CTA: Build a provider comparison using the merchant's historical refund profile and current fee schedules.

Closing element: Refund Cost Model and measurement plan rather than a generic hidden-fee FAQ.