Payment method to sell licenses to an app
Hi,
I need your advice on payment method. I've never done this before and am very new to selling something of my own.
Some facts
- I'm working on an electron app. I'm targeting only mac.
- I don't intend to put it on App Store.
- It's a one-time payment, no subscription.
- After payment, I'm thinking of providing a license key where they put in their app and the app validates it with my server.
Some thoughts
- Gumroad seems good but I'm not convinced if I need their platform. Will it require too much work if I do it by myself?
- Stripe or Snipcart looks good.
- Is there something else that I don't know about (like handling tax or whatever) that Gumroad takes care of and that Stripe or Snipcart won't?
- While writing this, I've just found this: https://help.gumroad.com/article/76-license-keys It looks like it will solve all my problems though 😅
Still leaving this post to hear what you think and what you've done.
Thanks for reading!
Trending on Indie Hackers
I haven't used them personally, but I've heard good things about https://keygen.sh/ for handling the license key side of things.
I've used both Stripe and Paddle successfully for the payment-processing side of things and would recommend them both.
keygen looks good, but it's a bit overkill for me to pay monthly while I don't have any estimation on the number of users. Gumroad provides the feature to whomever purchases my product without any API limitation.
I will look into Stripe and Paddle as well.
Thanks for the comment!
I use Paddle with a custom license key (a file actually), which is generated on my server. It works well. You can do all sort of things with license files both on client and on server.
BTW, as a Mac user and developer, I wonder why did you develop your app exclusively for Mac with Electron? Swift and Cocoa is really much better regarding all aspects. The only reason for that would be to make it available under Windows / Linux.
Hey thanks for the comment. I have no experience with Swift and Cocoa and I'm a web developer. The reason why I'm targeting only mac is, because the app I'm building is sort of an extension for a mac only app.
Hey @eunjae,
It was super easy to set up payment and verification using Gumroad for my app https://norde.io which is also an Electron app.
Gumroad issues the key, then it's just a simple function that sends a call to Gumroad to verify it's legit. The call has to be made by Electron though, not the front-end.
I'm fairly new with Electron too, and can you tell me a little more about this?
What I was thinking is, when my electron app starts, I will run a node server and the frontend will call its APIs. And one of the API is going to interact with Gumroad API. Does it make sense? Or is there any better pattern in Electron world?
A follow-up question: If I do what I am thinking of doing, the API key for Gumroad ends up being included in the app. It will be used by my node server, not on the frontend, though. As long as my server code is minified, can I consider it secure enough? Or is there any better solution?
Yeah that should be fine I think. My electron app doesn't rely on any servers, so I didn't bother going that way and the call is just made from by Electron on the users computer.
If somebody really wanted they could probably bypass it, but if someone is really that broke that they would put in the work to do that, they would probably be much better off by just contacting me and asking for a discounted key :D
I'm not so involved in the Electron way so I have no idea what the best pattern would be, but I imagine the recommended way would be something like you described :)
Thanks for your opinion. I tried not to think too much about hacky users, but just wanted to check if there's a quick win :)
I should just continue what I was thinking of!
Well be in touch if you decide to go the other way. I wouldn't mind sharing my code if that would help you.
I've just followed you! I'm still not in the phase where I implement the payment. I've put this post in advance to learn stuff. I will let you know how it goes and if I have any question :)
Cool, good luck with the project!
Hey @eunjae,
Have you also considered Paddle ? What are your thoughts on them?
Hey, I've recently heard of Paddle. So I haven't looked at it much. I need to check it more :)
Hi @eunjae I'm in exactly the same place right now - Electron app, initially targeting Mac, one-time payment, need some licence / verification system, never done this before! So I'm interested in this thread, will take a look at Gumroad solution. :)
Hey, let me know how it goes. Gumroad seems to be the easiest & fastest & complete solution so far, but I'm still going to take a look at Stripe and Paddle.
You can make use of both Gumroad and Stripe and provide users with two options to Check out, rather than one.
On a side note, if you are targeting only Mac, why are you using electron and why not a native app?
Hey, I don't have experience with Swift or Cocoa, but I'm a web developer. I'm trying to launch this as soon as possible, and the experience will be good enough on electron, IMO. (Plus, I don't want to learn Swift 😅)
And the reason why I'm targeting mac only is, my app is an extension to a mac only app.
Good luck then! Keep us posted on how it goes!
Thank you. I'll keep you posted! :)
I’m not the one you replied to but I’m guessing time-to-market might explain the use of Electron.
I agree with your unspoken premise that Electron is a resource hog, but the reality is that it allows devs to ship stuff quickly using skills they already have. This is safer than investing time and effort into developing for macOS The Right Way(TM) only to find out that the market cannot bear the higher prices you are asking for due to your sunk costs, or perhaps the market is too small to justify your continued investment.
I would say building native for macOS is easier than most people assume, which I found first hand building Swimbols.
I did it only because my app makes only sense on the Mac and other alternatives can't really achieve what I was aiming for. So I started learning AppKit only because I had no other option and as days passed, I have found it to be extremely easy to use with a lot of features baked in and given to the developer in simple API. Yeah, I know it is verbose, but it does a fantastic job.
One specific thing about developing for Apple platforms is that if you want your app to have features from the cool UI/UX that many Apple apps have, most likely there will be a very simple API to achieve it. In case of Mac, it sometimes will be hard to find the right API because of the poor documentation, but the platform itself is super powerful. And since the API is verbose, just reading it you can guess what it will do and most likely it will do what you guessed.
I assume, if @eunjae finds the market too small, he'll not be starting only with the Mac app.
Thanks for the thoughtful reply.
Your app looks great, though there’s a tiny typo at the end of your app description where you wrote “two weeks free trail” instead of “trial”.
Thanks for checking out my app.
I've already changed that in version 1.0.1 and submitted a couple of days ago. It's still "Waiting for review" from the App Store team.
Oh I see, no worries then.
BTW, I followed you on Twitter 😉.
I checked your profile earlier but can't find out what you are doing or tweeting about. I think it will be better to add a bio in your profile.
I could not figure out anything clear from the website either.
Thanks for the heads up.
I write about software engineering & product management.
I’ve since updated my Twitter bio.