Selling Your Game Outside Steam: Keys, Downloads and a Direct Sale That Delivers Itself

Originally published on the PermitCore blog.

Selling your game directly, next to or instead of a big store, starts with one question: what exactly does the buyer get after paying? A Steam activation code, an itch.io download link, a DRM-free build and a build that checks its own license are four different things. They come from different systems and need different delivery and support. Naming the right one on your sales page is the first step to a smooth direct sale.

1. Pick the kind of access you sell

Steam keys. A Steam key activates the game inside Steam. You request keys through Steamworks, and selling them on your own site still gives the buyer a Steam entitlement. Read the current Steam Key rules and guidelines before you plan bundles, backer rewards or discounts.

itch.io download keys. An itch.io download key is a private URL to your project's files on itch.io. It is a great fit when itch.io hosts your builds and you want to hand out access to backers or press.

A DRM-free build. You sell a download and trust the buyer. Here the important parts are clear usage terms, a reliable download page and an easy way to get updates.

Your own licensed build. Your game checks an entitlement you issued: the right product, a valid key, and the device policy you chose. This is the option that gives you full control over editions, trials, device limits and offline play, and it is the one the rest of this post focuses on.

Selling more than one kind? That works well as long as each listing says clearly which one it delivers.

2. Write the promise next to the price

Before the buyer pays, tell them:

• supported operating systems and the edition they are buying
• where the download comes from, and whether an account or launcher is needed
• how many devices they can activate
• how the game behaves offline
• which updates are included

Keep the same wording on the checkout page, in the game UI, on the support page and in your refund policy. If the build depends on platform features (cloud saves, achievements, workshop content, multiplayer identity), test the direct build on its own before launch so the listing matches what players get.

3. Use editions for demos, backers and the full game

With your own license you can model editions as features on one product: for example full_campaign or level_editor. The game checks the feature before unlocking that content.

• Demo: playable without a key; the full game unlocks after a valid license check.
• Trial: a time-limited license with a clear end date and an obvious upgrade button.
• Backers / early access: say which builds and which updates are included instead of promising a vague "lifetime key".

More on this: feature-based licensing and free-trial licenses.

4. Design offline play deliberately

Players expect a single-player game to run on a train. A good pattern:

1. Activate once online and bind the license to a stable device identity.
2. Store a signed offline token and verify it locally against a public key that ships with your game.
3. Check the product, the device and the token's expiry, not only the signature.
4. Refresh the token in the background whenever the player is online.

Then test the real situations on every platform you ship: clean install, restart, suspend and resume, lost connection, and an expired token. The offline licensing docs walk through the setup.

5. Connect payment and delivery into one flow

The smoothest direct sale is one where the payment itself triggers delivery:

1. The buyer pays through your payment provider (for example your own Stripe, Paddle or Lemon Squeezy account).
2. A verified payment webhook, not the success page, confirms the purchase.
3. The license is issued for the right product and features.
4. The buyer receives an email with the key and the download link, and can find both again in a customer account.

Renewals, cancellations and refunds should run through the same flow, so the license always matches the payment state. If you are deciding between a merchant of record and your own Stripe account, this comparison covers VAT and fees.

6. Example: a Unity game sold from your own store

Here is how this looks with PermitCore, which connects licensing to a branded Store on your own payment account with 0% sales commission:

1. Create the product and choose the edition, validity and device policy.
2. Add the Unity SDK and validate the expected product before the protected content runs; activate the device where registration is needed.
3. Create the Store listing, describe the build clearly and add the download URL of your release host.
4. Connect your payment account, matching prices and signed webhooks.
5. Run a sandbox purchase and check the whole chain: payment, correct product and features, delivery email and the download.
6. In the game, test the valid, expired, revoked and wrong-product outcomes, plus your device and offline rules.

The Store docs and the customer portal docs cover setup and self-service.

7. Make support boring

Tell buyers where to find their purchase, key and download, how to move to a new PC and whom to contact if an email does not arrive. Self-service device deactivation and re-download from a customer account remove most support email. Pair a fair device limit with that self-service and honest buyers stay happy while casual key sharing gets awkward; this guide goes deeper.

Before launch, check this list:

• The checkout says which build or platform key is sold.
• Download and update hosting work on their own.
• Payment, license issuance and the delivery email have each been tested.
• The game handles wrong product, device limit, expiry and no network without unlocking paid content.
• Device transfer, offline time, refunds and support match what the page promises.

If you sell (or plan to sell) a game outside the big stores: which part took the most work for you, payments, delivery or keeping keys from being shared?