Payment processor fees belong in your pricing maths

You make a sale for £50, open your payment dashboard, and feel briefly certain about the result. Then the processing fee appears. A customer asks for a refund. Another pays in a different currency. Tax is due later. The £50 was revenue, but it was never the amount you could safely spend.

Start with the money that reaches you

A useful first calculation is not price multiplied by sales. It is price minus the costs attached to that sale. Payment processing is usually the first deduction to model because it is connected directly to the transaction.

Write down the fee shown by your processor for a typical sale. If the fee has a percentage and a fixed component, calculate both. For a £40 sale with a hypothetical 2% fee plus a hypothetical £0.30 fixed fee, the processing cost would be £1.10: £40 × 0.02 = £0.80, then £0.80 + £0.30 = £1.10. The amount before any other costs would be £38.90.

Use the actual rate and currency for your account rather than copying that example. Fees can differ by processor, payment method, customer location and currency. Your payment provider's fee schedule is the source to check.

Build a per-sale pricing calculation

A small table makes the gap between revenue and usable money visible. You can create one for each product, especially if you sell a mix of downloads, courses, coaching and memberships.

Expected refunds are easier to model as an average than as a surprise. If one out of 20 sales is refunded in full, you can divide one sale's price by 20 and treat that as a simple refund allowance per sale. This is not a prediction of what will happen next month; it is a way to stop a refund from looking like an unexplained loss.

Tax needs separate care. The amount and timing depend on where you live, how your business is registered and where your customer lives. For digital products, customer location can affect the treatment. Keep the tax line in your maths, then confirm the rules with a qualified adviser or the relevant tax authority. Do not treat a payment dashboard's payout figure as your tax calculation.

Do not hide currency conversion in the headline price

A customer may see a familiar currency while your Stripe account receives another. The displayed price, the exchange rate and the amount that settles in your account can therefore be different. Even when the difference on one order feels small, repeated international sales make it part of your margin.

Choose a test order in each currency you regularly accept. Record the customer's displayed price, the processor fee, the converted amount and the amount that reaches your account. Repeat this when you change prices or payment settings. This gives you an observed calculation instead of relying on a rounded exchange-rate assumption.

If you sell through store.fan's payment tools, money goes straight to your own Stripe account. store.fan takes 0% of sales, although Stripe's own processing fee still applies. That distinction matters: a 0% storefront fee does not mean a sale has no payment cost.

Include refunds, discounts and failed payments

A discount changes more than the amount you collect. It can also change the fixed-fee percentage of the sale. A £0.30 fee is 0.75% of a £40 sale, but 1.5% of a £20 sale. The fixed part becomes more significant as the price falls.

1. 1Calculate the normal price after processing.
2. 2Calculate the discounted price after processing.
3. 3Subtract your expected refund allowance from each result.
4. 4Check whether the remaining amount still pays for delivery, support and your target income.
5. 5Set a minimum acceptable price before publishing a discount.

For a digital download, delivery may be largely automated, so the remaining amount can be compared with creation time, software and support. For coaching, the same amount must also cover preparation and the call itself. For a membership, include the work required every month, not only the first sign-up.

If you run regular promotions, use the price you actually expect customers to pay in your forecast. A product that is profitable only at full price may not be profitable under a permanent discount. On store.fan, Pro includes discount codes and flash campaigns, so record the net price for each campaign rather than treating the discount as a marketing detail.

Turn the calculation into a pricing decision

Once you know the amount left per sale, decide what that amount must do. It may need to cover a share of your monthly software costs, your support time, a tax reserve and your desired pay. Divide those monthly costs by a realistic number of sales rather than an optimistic one.

For example, if a product leaves you £32 after the costs you have modelled and you need £640 from it each month, you need 20 sales to reach that target: £640 ÷ £32 = 20. If your recent sales volume is lower, you have three broad choices: raise the price, reduce the work required per sale or change the sales plan. You do not need to force every product to carry the same margin.

Review the calculation after a defined period, such as 30 days or a set number of orders. Compare your assumptions with actual processor fees, refunds, currencies and payouts. Keep the original assumptions beside the new figures; the differences show you which part of the model needs attention.

Make the numbers easy to revisit

Keep one row per product and one column for each deduction. Name the currency clearly. Record whether a price includes or excludes tax under your local rules. If you use several payment methods, record them separately when their fees differ.

Your storefront should make delivery and sales records easier to manage, but it should not replace your own financial record. store.fan's iOS app can send instant sale alerts, which helps you notice activity quickly; you still need to reconcile the figures with Stripe and keep the records required for your business.