Stripe fee calculator

The rates this calculator uses

Every number below comes from Stripe's published pricing for a United States account on standard pricing, read on 4 September 2026. They are in the page source as a single constant, so what the calculator does and what this table says cannot drift apart.

Two caveats that matter more than the decimal places. These are US, standard, published rates — a negotiated contract, a different country or a platform arrangement can all differ, and no calculator on the open web knows yours. And a percentage plus a fixed fee behaves very differently at different sizes: 2.9% + 30¢ is 5.9% on a $10 order and 3.2% on a $100 one. Small-basket businesses are paying a rate nobody quotes them.

What you actually keep

The fee is only half of the question. The other half is where the money is when it is over, and that answer differs by route in a way a single "net" figure hides. One $49 charge, three destinations:

Read the middle column carefully, because the obvious reading of it is wrong. This is not a cheaper Stripe and there is no arrangement here that makes card processing cost less. Clize collects on its own Stripe account, pays Stripe's fee as the merchant of record, and credits your balance with the full amount the buyer paid. What you gained is not a discount — it is the removal of the account, the verification and the key. What you gave up is convertibility: the balance buys things Clize sells and does not become cash. A dollar of Clize credit is worth a dollar if you were going to spend it on a domain or a deploy anyway, and worth less than a dollar otherwise.

So the honest rule is a boundary, not a pitch. If revenue has to reach a bank, use your own Stripe account, pay the 2.9% + 30¢, and take the top row. If you are running an agent that already spends on domains, hosting and generated assets and you would like it to earn some of that back, the middle column is a closed loop rather than a fee comparison. Agent Storefront covers what that loop looks like end to end.

Charging more so you net an exact amount

Invoices are usually written the other way round. You do not want to know what $500 leaves you; you need $500 to arrive, and the question is what to put on the invoice. Adding 2.9% to the total is the intuitive move and it is wrong, because the fee is taken from the larger number you just created.

The arithmetic is one line. To net an amount N at a percentage p with a fixed fee f:

charge = (N + f) / (1 − p)

# net $500 on a domestic card:
charge = (500 + 0.30) / (1 − 0.029) = $515.24

Adding 2.9% instead would have given $514.50 and left you $14.36 short of five hundred — a rounding error on one invoice and a real number across a year of them. The calculator does this on whatever amount you type and shows it as the second figure, so you can read it either direction without changing the input.

Two footnotes. On ACH the formula changes above the cap: once the 0.8% would exceed $5.00, netting an exact figure just means adding $5.00, so a $2,000 invoice becomes $2,005 rather than $2,016. And in most jurisdictions you cannot simply pass the fee to the customer as a surcharge without disclosure and, in some places, without breaking card network rules — the safe version of this is a higher price, not a line item called "processing fee".

Subscriptions: the fixed fee is charged on every renewal

The single most common miscalculation in recurring revenue is treating 30¢ as a one-time cost. It is charged per successful transaction, and a monthly subscription is twelve successful transactions a year.

On a $9 monthly plan, each charge costs 2.9% plus 30¢, so $0.56 — which is 6.2%, not 2.9%. Over a year that is $6.72 against $108 of revenue. Bill the same $108 once a year instead and the fee is $3.43 — an effective 3.2%. The product is identical; the billing decision moved three points of margin. This is why the calculator has a billing selector rather than assuming one-off, and why annual plans are usually discounted more than their churn benefit alone would justify.

Two further costs that only show up on recurring revenue. Failed renewals still cost you: a declined charge does not carry a fee, but the retries, the dunning emails and the involuntary churn are real, and the fix — a card updater, a smarter retry schedule — has its own price. And refunds never return the original processing fee, so a customer who pays for a year and cancels in month two has cost you the full fee on the whole year even after you refund them ten months.

If you are building the checkout that produces those charges, the piece that decides whether any of this arithmetic is even trustworthy is where the price is stored. A price that lives in your page can be edited before it reaches Stripe, and the catalogue generator is the short version of the fix. When you are ready to exercise the failure branches, the test card table has a number for every decline and dispute in the rate sheet above.

One last piece of honesty about this page. It is a calculator, and calculators are the top of a funnel: most people who arrive here are already selling on Stripe and want a number, not a product. That is fine. It is linked into the storefront line because the next question after "what does this cost me" is usually "and who is going to run the store", not because a fee calculator is where anybody's decision gets made.

$ npm i -g @clize/clize && clize login
$ clize pay link --amount 49 --for "invoice 1042"