Sell Your Game Outside Steam: Keys, Downloads and Direct Sales

To sell a game outside Steam, first decide what the buyer receives. A Steam activation code, an itch.io download URL, a downloadable build and a license checked by your application are different products of different systems. Calling all of them a “key” hides the most important part of the purchase.

A separate sales channel can support your own audience, backers or a desktop tool sold alongside a game. It also needs a clear delivery, update and support process. A payment button by itself does not replace the services your current build depends on.

Choose the access you are selling

Steam-issued activation keys

A Steam key grants access through Steam to the relevant platform package. It is requested through Steamworks, not generated by PermitCore. Selling it on your own website still leaves the buyer with a Steam entitlement and the associated platform requirements.

Read the current Steam Key rules and guidelines before planning inventory, discounts, backer rewards or release timing. Requests can be reviewed or declined; do not promise buyers an unlimited supply of future keys. The guidance addresses comparable treatment of Steam customers and distinguishes retail keys from testing access. Release-state override keys are intended for limited testing, not retail sales.

itch.io download keys

An itch.io download key is a private URL granting access to a project's files. It is not a PermitCore license and does not automatically activate a game on Steam. itch.io also supports separately supplied external keys under its own rules and stock limits.

Its current guidance normally expects downloadable project files when external keys are offered; read the documented exceptions rather than assuming a key-only listing will qualify. The creator FAQ explains its hosting and distribution model. itch.io does not add DRM to your uploaded files. Any licensing code already inside your build is your own integration.

A build without an application license check

You can distribute a build that does not ask the player to validate a license. Decide how buyers obtain updates and recover their downloads. A restricted download page controls distribution; it does not prevent a downloaded file from being copied. Explain the usage terms and the actual delivery process without suggesting a private link makes the binary unshareable.

Your own application license

You can distribute an independent build whose protected behavior checks a PermitCore entitlement. Your app integrates the SDK, checks the expected product and enforces the result. That key is not redeemable on Steam, and it does not create an itch.io purchase.

PermitCore does not mint Steam keys or provide a built-in Steam entitlement bridge. If you offer more than one kind of access, explain and operate each delivery path explicitly. Do not imply that a PermitCore Store purchase automatically adds a game to another platform's library.

Describe the build before the buyer pays

State the supported operating systems, edition, download source, required account or launcher, device allowance, offline behavior and included updates. If the purchase is an independent build, say so beside the price. If it includes a platform-issued key, say which platform and when the code becomes available.

Confirm distribution rights for the game and its bundled assets. Review applicable platform and publisher agreements for a separate build; a generic licensing service cannot decide those rights for you. Keep your checkout description, game UI, support page and refund policy consistent.

Inventory platform-dependent features too. Cloud saves, achievements, workshop content, multiplayer identity and a platform backend do not become independent merely because you change the license check. Test the actual build without the dependencies you intend to remove.

Demo, backer and paid editions

For your own build, product-scoped license features can distinguish access such as a full campaign or an editing tool. The application must gate the corresponding work. A flag does not create Steam DLC ownership or automatically distribute another platform's content.

A public demo can remain usable without a paid key, with the full edition unlocked only after a valid entitlement check. If you use a trial, explain its expiry and the recovery or upgrade path. Early-access and backer promises should specify which build, updates and support are included rather than relying on an ambiguous “lifetime key”.

See feature-based licensing and the trial guide for the existing controls. A feature name is an application policy input; adding it in Admin does not implement the game feature for you.

Plan offline use on the platforms you actually ship

For supported targets and plans, configure trusted public verification keys, a stable device identity and the intended signed offline policy before disconnecting. SDK 2.1.1 does not trust a public key merely because it sits beside a token in an editable cache. No configured trust keys means no cached authorization.

Check product, device and signed deadline as well as the signature. Offline proof does not renew a floating session, discover a refund or immediately learn about revocation. Nor does it make server-dependent game features work offline. A copied identity or patched client remains a separate limitation.

Test a clean installation, restart, suspended session, lost connection and expired proof on your actual Windows, macOS, Linux or handheld build as applicable. A portable library compile is not Steam Deck, console or Unity target certification. Unity WebGL uses the online validation path; consult the Unity reference for target-specific limits.

The offline setup reference and shutdown-planning guide help separate access promises from services the game still needs.

Payments and license delivery are separate steps

A vendor Store uses one saved provider: Stripe or Paddle. Choose and configure that account for the whole Store. PermitCore takes no Store commission; provider fees and the terms of your own agreement still apply. Paddle merchant-of-record purchases use provider-issued payment documents. A Stripe setup has its own seller and tax responsibilities; review the provider comparison and current provider terms.

Paddle includes games in its supported software categories, subject to its acceptable-use policy and seller/product review. Confirm approval for your own account and offering before launch. A donation or crowdfunding campaign is not automatically an approved software purchase. Connecting a Store does not bypass that process.

After canonical paid evidence is verified, PermitCore issues the configured license and queues its delivery email. The success redirect alone is not payment evidence, and a queued email is not proof that the inbox received it. Test delivery and give buyers an account/support recovery path.

Existing purchases and subscriptions retain their original provider binding when a vendor changes the Store selection. Test the intended renewal, cancellation and refund behavior. A credit-only or zero-total subscription update is not a new paid game sale. The payment lifecycle guide covers those boundaries.

Configure the underlying product's download URL for your release host when appropriate. The Store can include that link in delivery email; it is not a game CDN or automatic patching service. Operate file hosting, update delivery and download-access controls for your build.

Example: an independent Unity build

1. Create the software product and decide the edition, validity and device policy you will sell.
2. Integrate the current Unity 2.1.1 application tutorial. Supply your own product/key inputs and game UI. Validate the expected product before protected work, and use activation where registration is required.
3. Create the matching Store listing. Explain that it delivers a license for your independent build, not a Steam key. Add the release download URL and support instructions.
4. Configure the saved Stripe or Paddle connection, matching catalog prices and signed webhooks. Use consistent sandbox credentials for your test.
5. Complete a test purchase. Confirm canonical payment, correct product/features/key, delivery email and buyer access to the actual download.
6. Test invalid, expired, revoked and wrong-product outcomes in the game, plus the configured device and offline behavior. Validation alone does not register a device or reserve a floating seat.

This is the existing Store and SDK integration flow. It does not create an external platform key, install an updater or configure your game's protected features automatically. Follow the Store reference for account setup and the customer portal reference for supported self-service.

Keep recovery and support straightforward

Tell the buyer where to find its purchase, license and download, how to replace a device and whom to contact when delivery fails. A Store customer account is not automatically an authenticated identity inside your game. Choose the portal access policy deliberately before sharing a team key.

Removing a device or refunding a purchase does not uninstall a binary already downloaded or erase every offline proof. Your app must enforce the chosen validity policy. Read the key-sharing guide for realistic limits rather than treating an always-online prompt as a complete anti-piracy system.

• The checkout says which build or platform entitlement is sold.
• Delivery and update hosting are configured and independently reachable.
• Payment evidence, license issuance and email delivery have each been checked.
• The game handles wrong-product, capacity, expiry and network states without granting unintended access.
• Device transfer, offline deadlines, refunds and support terms match the published promise.
• No claim depends on an unapproved external key supply or an untested target platform.