I'm creating a subscription-based desktop application, but there is no authentication on the platform as the "user" is the computer upon which the application is installed. This means no user sign up nor login.

I thought of an external website that did the following:

  1. User goes to purchase a subscription.
  2. A session is created for them.
  3. They put in their credit card/crypto wallet info.
  4. The info is processed to create a payment.
  5. A unique, temporary token is generated.
  6. The session is destroyed at the same time as the token.

When this token is created, the user would paste this into the desktop application. The app verifies and validates the token and sets the app to function with paid features.

Is there a viable way of processing payment information without having to implement user accounts and logging in?

  • This is basically an activation code/key... best to tie that to an e-mail address so they can always recover it if necessary. (computers crash, or are upgraded, etc...) At that point you don't necessarily have a user account, but an e-mail/key pair stored. So the key/code is verified by your home server and once it is, the app or features are unlocked. Also consider an offline validation method, and keep track of how many times a particular key/code has been used. (If that number gets really large you might ban/remove that key.) Dec 1, 2021 at 21:42
  • It seems like the flow that you describe could be implemented using Paypal Instant Payment Notification. See developer.paypal.com/api/nvp-soap/ipn
    – mti2935
    Dec 31, 2021 at 22:28

1 Answer 1


The approach you described is viable, although you might want to explicitly delete the session token from the browser. (Or maybe not, if you want them to be able to continue acting within that session from the browser). You should of course collect the user's email and send them a receipt, which can later be used for troubleshooting (people will have issues with activation, either at time of payment or upon e.g. moving to a new machine).

With that said, a few thoughts:

  • Would it be viable to just put the purchase experience in the app itself? Either through desktop UI controls or an embedded browser. That avoids the process of copying the token, etc.
  • Since a user might well need to re-activate the software (e.g. if they have to wipe and re-install their OS), you might want to simplify this process. One way to do that would be to store a cryptographic hash of user information, normalized in some way, so that user can prove their identity automatically.
  • Obligatory comment: you're trying to implement a DRM system (where the software is fully capable but artificially limited depending on licensing). These are inherently impossible to "do right"; if person X can run the software with full access, there is some means by which person Y can do the same even if only one of them paid (you can make it so that somebody has to pay; you can't make it so that the payer can't then put a cracked copy online for everybody else). That's not to say you shouldn't bother - lots of popular software, from simple phone apps to the Windows operating system have similar DRM - but it's impossible to make it unbreakable and difficult to even come close, and some people will break it if you get any non-trivial number of users.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .