How to Sell Software Online in 2026 Without Giving Up 30% to Marketplaces
Finishing the code is only one part of shipping software. A buyer also needs to know whether the product runs on their machine, what the licence permits, how updates work, how to verify a purchase, and what happens when activation infrastructure is temporarily unavailable.
Those operational details determine whether a software store earns trust. They also determine the real cost of a sales platform; a low headline fee is not useful if the seller must rebuild delivery, licensing, tax, and support systems from scratch.
This guide provides a release workflow for desktop applications, plugins, developer tools, scripts, and other downloadable software. It separates verified platform facts from general engineering advice so you can evaluate each decision rather than accept a promotional comparison.
Editorial verification note, 12 August 2026: We rechecked the platform fees and technical statements below against Apple, Gumroad, Payhip, OWASP, and current 3DIMLI documentation. This review corrected an earlier description of the 3DIMLI verification API: it requires a seller bearer token, and that secret must remain on the seller's server. Fees, regional terms, and APIs can change; verify the linked primary sources before implementation.
Decide what the buyer is licensing
Before choosing a storefront, define the product boundary.
Perpetual version licence
The buyer receives a specific major version indefinitely. Updates within that version may be included, while a later major version can be a paid upgrade. State the support window and whether security fixes continue after the next major release.
Time-limited licence
Access expires after a defined period unless renewed. This can support recurring maintenance, but the application needs a fair expiry and offline policy. A temporary verification outage should not immediately disable paid work.
Seat or organization licence
The contract is based on users, devices, or an organization rather than a single download. Define how a buyer deactivates an old device, transfers a seat, and recovers access after hardware failure.
Hosted service or hybrid product
A desktop client may depend on cloud processing, storage, or updates. Explain which functions require the service, what data is transmitted, and what happens if the service closes.
Write these rules in ordinary language before implementing them in code. The checkout description, licence document, application behaviour, and support policy should agree.
Build a release package a stranger can verify
A professional package should answer four questions: what is this file, can I trust it, will it run here, and how do I recover if installation fails?
Include:
- a versioned filename rather than
final.zip; - a README with installation and uninstall instructions;
- exact operating-system and architecture requirements;
- dependency and permission requirements;
- release notes and known limitations;
- the end-user licence or a durable link to it;
- a checksum published through a trusted channel;
- a support address and expected response window.
Sign native binaries where the target platform supports code signing. OWASP's software supply-chain guidance recommends enforcing signing and protecting the signing infrastructure because a compromised signing process can harm downstream users. See the OWASP Software Supply Chain Security Cheat Sheet.
Run the exact archive you plan to sell through a clean-machine test. Testing only the developer build can miss missing runtimes, absolute paths, environment variables, and files that were never copied into the release package.
Use a release test matrix
Record evidence for each supported target:
| Area | Minimum evidence |
|---|---|
| Installation | Clean install on every advertised operating system and architecture |
| First launch | No developer tools, local paths, or undocumented accounts required |
| Permissions | Prompts match the documented need and least-privilege expectation |
| Activation | Valid, invalid, refunded, offline, expired, and rate-limited paths tested |
| Update | Upgrade preserves user data; rollback or recovery is documented |
| Uninstall | Installed files and background processes are removed as described |
| Download | Purchased archive opens, checksum matches, and links behave as promised |
| Support | Buyer can find logs, version information, and a contact route |
Keep the matrix with the release record. If a buyer reports a failure, you can distinguish a known limitation from a regression.
Compare sales channels by the responsibility they assume
There is no single marketplace percentage. Fees can depend on discovery source, plan, region, payment method, tax handling, and program eligibility.
Current primary-source examples illustrate the differences:
| Channel | Published platform terms to verify | Responsibility trade-off |
|---|---|---|
| Apple App Store | Apple's Small Business Program publishes a 15% commission for qualifying developers, subject to eligibility and regional terms | Apple controls distribution and store policy; the seller must follow platform rules |
| Gumroad | Gumroad currently publishes 10% + USD 0.50 for direct/profile sales and 30% for Discover sales | Gumroad says it operates as merchant of record and handles applicable tax obligations under its model |
| Payhip | Payhip currently publishes 5% on Free, 2% on Plus, and 0% on Pro, with PayPal or Stripe processing fees separate | Plan cost and tax handling must be evaluated alongside the percentage |
| 3DIMLI | Flexible bills 8% of finalized sales; Fixed is USD 25/month or USD 250/year with a 0% platform fee on sales; gateway fees are separate | Buyers pay the seller through the connected gateway, so seller responsibilities differ from a merchant-of-record model |
Sources: Apple Small Business Program, Gumroad pricing, Payhip pricing, and 3DIMLI pricing.
This table is not a claim that one channel is universally cheaper. Add payment processing, fixed charges, refunds, disputes, currency conversion, local taxes, tax-remittance responsibilities, support labour, and required infrastructure before comparing total cost.
Model the unit economics before choosing a plan
For each channel, calculate:
net revenue per order
= sale price
- percentage platform fee
- fixed platform fee
- payment-processing fee
- tax absorbed by the seller
- expected refund and dispute allowance
- average support cost
Then include monthly software, signing certificates, hosting, monitoring, and licence-server costs. Use actual order values rather than a single percentage because fixed transaction fees affect low-price tools differently from high-price applications.
The operational model matters too. A merchant-of-record service may charge more while assuming tax responsibilities that a direct-payment storefront leaves with the seller. Compare like with like.
Set licence tiers that map to enforceable differences
Avoid creating tiers only to produce a pricing table. Each tier should correspond to rights or service levels that a buyer can understand and you can support.
A practical structure might distinguish:
- individual use on a defined number of devices;
- a team licence with a stated seat count;
- organization-wide internal use;
- redistribution or embedding rights;
- update and support duration;
- access to source code or premium integrations.
Do not call a licence "commercial" without explaining the permitted commercial activity. Clarify whether the buyer may use the tool for client work, redistribute generated output, embed a library, or resell the software itself.
Configure a software listing on 3DIMLI
3DIMLI publishes a dedicated software-product workflow. Its current documentation requires at least one software licence, a downloadable archive, a README, and product previews. Sellers can describe platform requirements, create licence tiers, and upload one supported archive up to the documented limit. Review the live 3DIMLI software-product documentation for current fields and accepted formats.
A careful listing should include:
- a title that says what the software does;
- screenshots of the actual interface rather than only a logo;
- supported operating systems and architectures;
- file size, dependencies, permissions, and offline requirements;
- version number and last verified release date;
- installation, activation, update, and uninstall steps;
- licence rights and restrictions for every tier;
- support and refund expectations;
- a link to documentation or a changelog.
Product-specific claims in this section come from 3DIMLI's own documentation. They should be evaluated as first-party information.
Implement licence verification without exposing the seller token
Each eligible 3DIMLI software purchase receives an Order Item ID that can act as a licence key. The current verification endpoint is:
POST https://www.3dimli.com/api/software/v1/verify
The endpoint requires both Content-Type: application/json and an Authorization: Bearer <seller_token> header. The request body contains the buyer's key and the product slug.
curl -X POST https://www.3dimli.com/api/software/v1/verify \
-H "Authorization: Bearer $DIMLI_SELLER_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"key": "00000000-0000-0000-0000-000000000000",
"product_slug": "/my-tool"
}'
The placeholder key above is intentionally non-functional.
The safe architecture is:
buyer application -> your licence server -> 3DIMLI verification API
Store the seller token in your server's secret manager or protected environment configuration. Never ship it in a desktop binary, plugin, browser extension, mobile package, or client-side JavaScript. A secret embedded in buyer-controlled software can be extracted.
The API can return a validity result plus product and licence-tier information. Current documentation also describes authentication errors, ownership checks, refunded-order handling, and a per-IP rate limit. Read the full 3DIMLI License Verification API reference before integrating; it is the authoritative source for headers, responses, limits, and token generation.
Design activation for failure, not only success
A production licence system needs behaviour for more than valid and invalid keys.
Cache carefully
Cache a successful verification for a bounded period so a temporary network problem does not disable a legitimate buyer. Decide how quickly refunds or revoked access must propagate, then set the cache window accordingly.
Separate service failure from invalid licence
An authentication error, rate limit, timeout, or 5xx response is an infrastructure problem. Do not display "pirated copy" when your own server is misconfigured or unavailable.
Provide an offline policy
If customers may work offline, define a signed offline entitlement, grace period, or support-assisted activation path. State that policy before purchase.
Minimize collected data
If you bind seats to devices, document what the device identifier represents, how long it is retained, and how a buyer resets it. Avoid collecting hardware or personal data that the licence model does not require.
Protect support recovery
Account recovery and manual activation can become the easiest path around otherwise strong controls. Require enough evidence to help the buyer without exposing order details or allowing social-engineering abuse.
Build a buyer-facing documentation set
At minimum, publish:
- a quick-start installation guide;
- activation and deactivation steps;
- system requirements;
- common error messages and recovery steps;
- an update policy and changelog;
- a privacy notice for telemetry or licence-server data;
- licence terms;
- a support route.
Documentation reduces pre-sale uncertainty and gives searchers something more useful than a generic feature list. It also forces the developer to resolve ambiguous behaviour before buyers encounter it.
Launch in a controlled sequence
- Create a release candidate and freeze its version number.
- Run the clean-machine and activation matrix.
- Upload the exact tested archive.
- Purchase through a real test path where the platform permits it.
- Verify delivery email, download, checksum, install, activation, and refund behaviour.
- Publish documentation and support contacts.
- Release to a small initial group.
- Monitor download failures, activation errors, refund reasons, and support volume.
- Expand promotion only after the workflow is stable.
Do not treat a successful checkout as proof that the product is ready. The buyer's task ends only after installation and first useful operation.
Final software-selling checklist
- The licence model, update policy, and support window agree.
- Every advertised operating system and architecture passed a clean install.
- The sold archive is the same artifact that was tested.
- Binary signing and checksums are handled through protected infrastructure.
- System requirements, permissions, dependencies, and known limitations are visible before purchase.
- Each tier describes enforceable rights rather than vague labels.
- Platform, processor, tax, refund, dispute, and support costs are included in the pricing model.
- The seller token is kept on a server and never shipped to buyers.
- Valid, invalid, refunded, offline, rate-limited, and service-failure activation paths were tested.
- Buyers can deactivate old devices and recover access.
- Documentation includes install, update, uninstall, privacy, licence, and support information.
- A real end-to-end purchase and delivery test passed before launch.
Sources checked for this update
- Apple App Store Small Business Program — current eligibility and reduced commission description.
- Gumroad pricing — current direct/profile and Discover pricing plus merchant-of-record statement.
- Payhip pricing — current plan and transaction-fee structure.
- OWASP Software Supply Chain Security Cheat Sheet — signing and release-infrastructure guidance.
- 3DIMLI software-product documentation — first-party listing, archive, and licence fields.
- 3DIMLI License Verification API — authoritative authentication, server-side secret, response, and rate-limit details.
- 3DIMLI pricing — first-party plan terms.
Related reading: the SVG product and licensing checklist, the editorial on digital self-reliance for student creators, and the 3DIMLI editorial standards.