Gumroad Discover fee: 30 percent in total, per the code

By yoshibuild · Published 2026-10-10 · Last verified 2026-10-11

One number gets repeated everywhere: Gumroad takes 30 percent of a sale that comes through Discover. The author read the fee code on 2026-10-11, and the number holds up in the default case. This article shows how it is built, when it applies, and where the reading stops.

As of 2026-10 the author has no sales, so there is no payout statement to compare against. This is a source-reading note, not an accounting guide.

What the code has

In purchase.rb (read 2026-10-11) there are these constants. "Per thousand" means 100 is 10 percent.

GUMROAD_FLAT_FEE_PER_THOUSAND = 100 (10 percent)
GUMROAD_DISCOVER_FEE_PER_THOUSAND = 300 (30 percent)
GUMROAD_DISCOVER_EXTRA_FEE_PER_THOUSAND = 100 (10 percent)
GUMROAD_FIXED_FEE_CENTS = 50
PROCESSOR_FEE_PER_THOUSAND = 29 and PROCESSOR_FIXED_FEE_CENTS = 30, used when the sale runs through Gumroad's own merchant account

How the fee is computed

In calculate_fees, the code starts from a base rate: the flat 10 percent, plus the 2.9 percent processor rate if the sale used Gumroad's merchant account. If the Discover fee applies, it then adds 300 - 100 - 29 per thousand (or 300 - 100 without the merchant account). Add the base back and the total is 300 per thousand, which is 30 percent. In other words, the Discover fee replaces the usual rate and does not stack on top of it, at least in the default case the author traced.

The fixed fee also changes. A direct sale carries 50 cents (plus 30 cents more on the merchant account path). When the Discover fee is charged, the code sets the fixed part to 0.

So for a $10 sale, as the author reads it: a direct sale is 10 percent plus 50 cents, and a Discover sale is 30 percent. These are the author's reading of the code, not a payout.

Free products: calculate_fees returns a fee of 0 when the price is 0. That matches the ranking article: a free product earns Gumroad nothing, so a ranking by fees earned has nothing to rank it on.

When the Discover fee applies

charge_discover_fee? is true only when the product is recommendable (or the original subscription purchase already paid it), the sale was marked as coming from a product recommendation, and the recommendation type is not one of the free types. The free types in recommendation_type.rb are library, more-like-this, wishlist and recently-viewed. A sale from a link you shared yourself carries no recommendation, so by this reading it takes the direct rate.

That has an odd effect for a new seller. Your first sale cannot come through Discover (see the first-sale gate article), so it falls under the direct rate. The author has not confirmed this against a real payout.

What can still change the number

link.rb has a per-product discover_fee_per_thousand. It must be 100, or from 300 to 1000 (the message reads "must be between 30% and 100%"). The default for sellers with the boost option on is 300. So a seller can choose to pay more than 30 percent, and the author found no way to pay less.
Custom fee settings on the seller or the purchase (custom_fee_per_thousand) enter the formula. The author did not trace how they get set.
A lower rate for high-volume sellers exists in the code behind a feature flag. It does not apply to a new store, and the code states that Discover keeps its full 30 percent.
Subscriptions and pre-orders use their own branches. This article covers a one-time sale.
Taxes, VAT, refunds and country-specific rules were not traced.

What Gumroad's help page says

The Discover help article was seen only through search summaries on 2026-10-10 and was not loaded directly. Open the live page before you rely on any percentage. A third-party newsletter dated 2026-08-13 describes the fee as 30 percent via Discover and a direct sale as 10 percent plus 50 cents. That matches the code, but the author treats it as a summary and not as proof.

How to check your own numbers

When a real sale arrives, do this instead of trusting any article:

Open the sale in your Gumroad dashboard and note the price, the fee shown, and the payout amount.
Note how the buyer found you. A link you shared is not Discover.
Compute fee divided by price. Write it down with the date.
Compare it with the fee line on the next payout statement.
Repeat for a Discover-sourced sale, if one ever happens, and keep both rows.

Two or three rows are a note. They are not a rule.

Why this matters for pricing

If a Discover sale costs 30 percent in total, a $5 product leaves $3.50 before other costs. A direct sale on the same product would be 10 percent plus 50 cents, which leaves $4.00. For tiny prices the fixed 50 cents matters nearly as much as the percentage. Both numbers are the author's arithmetic from the constants, not a payout.

If you are deciding whether to lower a price or run a promotion, use the worse of the two cases and see whether the numbers still work. If they do not, change the plan before the first sale, not after.

Caveats

Constants and formulas in a public repository are not the same as the live charge. Gumroad could override them elsewhere, and the live service may use settings the repository does not show.
Code read 2026-10-11 on main. It can change.
Nothing here is tax or accounting advice.

The author's 30-day experiment

In 2026-10 the author is preparing a 30-day test on their own store. If a sale happens, the dashboard row will be recorded as described above, including the fee and the source, and written up with the date. If none happens, that gets reported too: [case study link, not yet published].