This tool allows you to calculate estimated monthly fees for six digital goods services (DGSs): E-junkie, FetchApp, Gumroad, Pulley, Digital Goods Store and Sellfy.
Because there’s such a variety of ways in which the DGSs make their money. My Selling Digital Products the Simple Way report explains them, and also explains the arithmetic of how to calculate your own scenario. But there are so many different ifs, buts and maybes that it seemed like a good idea to create a tool to crunch the numbers and come up with the results, thus saving the time spent by countless individuals scrabbling around for a pencil and paper to do all those tedious sums.
I haven’t taken all the work out of it. You’ll still have to do a couple of bits of addition yourself (or get someone to do it for you), and you’ll also need to get out your crystal ball and predict how many sales per month you’ll be making. But I’ve seriously cut down on the legwork for you, so you can save your time for doing stuff that’s less mind-numbing.
How this tool works
The six DGSs charge sellers in one of two different ways: by storage (the number and/or aggregate file size of the products sold) or by transactions (a percentage of the proceeds and/or a flat fee per transaction). Calculating the fees requires different information in each case.
Charging by storage
These DGSs each have their own scale of plans according to the amount of storage space needed and/or the number of products sold. To identify which plan fits your requirements, you’ll need to identify how many separate products you’re planning to sell, and how many megabytes they add up to in total. (These DGSs aren’t interested in how many sales you’re making, or in how much you’re charging – as long as you’re paying their storage charge, they’ve made their money.)
Charging by transaction
These DGSs take their cut from your earnings, so they’re interested in how many sales you’re making (for their flat fee per transaction, if any) and the amount you’re being paid (for their percentage). (They don’t charge for storage space, so the number of products and file size are of no interest to them.)
Payment processors’ fees
Payment processors such as PayPal, Google Checkout and Stripe also typically charge per transaction by applying a flat fee per transaction and levying a percentage on the amount you’re being paid. However, not all the DGSs require you to use a payment processor – and even those that do may not limit you to any particular one. So to get a fair comparision across the DGSs, you’ll need to enter the current fee rates charged by your preferred payment processor.
So what happens after I hit the Submit button?
The form adds up the total number of products, the total amount of storage space required, the total number of transactions and the total earnings, and checks them against the DGSs’ current pricing plans to apply the appropriate charge for each DGS. It then also calculates the payment processor’s fee. Finally, it deducts both fees from your total earnings to show you what you’ll actually get paid.
Why don’t you ask for individual product details?
Because the tool doesn’t need them!
It does need to know the price of each product, so that it can calculate your total turnover (and thus the fees of the transaction-based DGSs and the payment processors). This is why you’re asked to assign your products to price-based categories – so that the tool can calculate your total turnover based on your total projected monthly sales in each price category. (It doesn’t need to know how many sales of each individual product. If you have ten lovingly crafted WordPress themes all priced at $30, it doesn’t matter whether you sell 10 of each, or 91 of one and one each of all the others – as far as the transaction-based DGSs and the payment processors are concerned, it’s 100 sales at $30.)
No other individual detail matters. The storage-based DGSs aren’t interested in individual file sizes, only the aggregate. None of the DGSs care about what type of file each product is; to the DGSs, they’re all just megabytes.
If individual product details don’t matter, why do you need to know how many there are?
Because the storage-based plans often have an upper limit for product numbers as well as for storage space in megabytes.
Why do I have to enter product details at all? Couldn’t we just run the calculations based on price and number of sales?
We could do that, but it wouldn’t make for a very useful tool as it would rule out any storage-based DGSs from the calculations, including several of the biggest.
All clear? Great. Let’s get started!