Re: payments - it depends on the country, but generally Stripe + PayPal + bank wires for larger/enterprise purchases. Alternatively, Braintree.
An altogether different option is to pay 2x the commission and use "full-service" reseller frontends like Digital River, PayProGlobal, etc. These are referred to as "registrators" and they used to be useful, because getting a merchant account and processing cards was a royal pain the ass. But now there's Stripe, so virtually no value in them. In fact, they tend to make thing more difficult to the clients than needed to justify their own existence (like requiring phone numbers, calling customers back to "verify" purchases and other artificial b/s like that).
Re: piracy protection - wildly depends on whom you ask. There is a camp of people that put minimum effort (literally a a single "if" check in the code) and embrace having their stuff cracked and hacked. The logic is that this acts as extra marketing and helps converting pirates (lol). There are also people who use packaged solutions like VMprotect and (previously) Armadillo. This tends to nip piracy in a bud, but creates issues with antivirus false positives. It also makes the software heavier and more fragile. There's also a middle ground of custom protection schemes that, if deployed wisely, can create 100x more headaches to crackers vs the effort spent on coding them in. Not that hard to do, but these aren't drop-ins, obviously.
Also, closely related, is the question of how the licensing works. Previously, most of the shareware used completely offline licensing using "keys" that were either hardcoded into the program or verified algorithmically (read, with elaborate checksums and such). This caused an emergence of keygens and it also fed credit card fraud with people smash-n-grabbing keys in bulk and then published them for the street cred. Surprisingly, a lot of shareware still uses this method and they still bitch and moan about the consequences. The alternative, obviously, is to use online activation. That is, what is sold is an activation token that can be swapped for a machine-specific license, via an exchange with the licensing server. This nearly completely eliminates the CC fraud and it allows for finer control over licensing. There are some drop-in solutions for this, but all of them are really quite basic and almost universally suck. However, the good news is that is fairly simple to roll out your own online licensing scheme in a matter of few work-days (assuming you know a bit of web backend and frontend).
> There are some drop-in solutions for this, but all of them are really quite basic and almost universally suck. However, the good news is that is fairly simple to roll out your own online licensing scheme in a matter of few work-days (assuming you know a bit of web backend and frontend).
I wouldn't say all of them suck. But that's because I built one [0] for the sole reason that, back in 2016, I too thought all of other ones sucked.
The calculator assumes that there's no cost to integrating with your system. It also assumes that the developer is salaried, which is almost never the case when it's a single-person shop.
The amount of effort required to learn your system, to do the integration, to test and to support it is absolutely on par with the time it would take to make a simple licensing framework from scratch. Except that the latter doesn't create an external dependency for a critical part of customers' experience.
This is all from a perspective of desktop software vendor. Perhaps things are different when your service is used for WP plug-ins or web apps, but for desktop apps - IMNSHO - the value of it is fairly low.
> The calculator assumes that there's no cost to integrating with your system.
Thanks for the feedback! And that’s correct, but I think you misunderstand the calculator. This is for the cost of the licensing server alone, not the integration into a software application, which will of course cost additional time/money either way. Regardless, the real build vs buy savings in almost any third-party are in often forgotten long-term maintenance costs.
> It also assumes that the developer is salaried, which is almost never the case when it's a single-person shop.
If you don’t have a salaried developer, or at least have an average spend per-year to be able to input (even if it’s yourself at an hourly rate), then you likely aren’t my target market. And that’s totally fine. One-person shops like to unnecessarily build things in-house because they typically value their time at near-zero. They’ll spend weeks building something they could have paid $19/mo for. (Which is fine -- they churn more often and require more support, in my experience.)
> The amount of effort required to learn your system, to do the integration, to test and to support it is absolutely on par with the time it would take to make a simple licensing framework from scratch.
Keyword here would be “simple.” In my experience from running the business for nearly 6 years, most licensing systems aren’t simple. And if they are, they likely don’t even need a licensing server in the first place -- just do signed license keys.
I have testimonial after testimonial of the opposite conclusion -- that the API saved significant time and money -- especially for the long tail, years after integration.
Unless your licensing system is incredibly simple (and in my experience they rarely are), there’s money to be saved in not building and maintaining it in-house.
If you’re the developer, I repeatedly tried to contact you to ask some questions. Since i never heard back, and I didn’t like the other options, I too ended up rolling my own.
I am. That’s very atypical for my support, and I sincerely apologize for that. Searching for your emails landed me in early 2020. And it looks like I forgot to respond to you. That was a busy time. After 4 years, I was in the process of quitting my full-time job to go full-time on Keygen, and I was in the middle of moving all support from Intercom to email. So my email was kind of flooded and I often forgot to respond to some discovery emails. It’s no excuse, but I figured I’d share. Again, sorry for the poor experience.
No problem! My apologies for sounding angry, I am not - I can understand how these things happen. I am quite interested to know that you're still keeping up with it, and I may be interested in trying out keygen again.
Handling taxes (VAT, sales tax) when you are selling worldwide is a nightmare. That is why many vendors pay the extra to use 'full fat' payment processors, rather than Stripe.
Also, it's worth checking with the accountants first before taking on a role of a tax collector. When yet another random country demands a sales tax on purchases made by its citizens, it's just a spherical pony in a vacuum. Best to first check if their demands have merit.
An altogether different option is to pay 2x the commission and use "full-service" reseller frontends like Digital River, PayProGlobal, etc. These are referred to as "registrators" and they used to be useful, because getting a merchant account and processing cards was a royal pain the ass. But now there's Stripe, so virtually no value in them. In fact, they tend to make thing more difficult to the clients than needed to justify their own existence (like requiring phone numbers, calling customers back to "verify" purchases and other artificial b/s like that).
Re: piracy protection - wildly depends on whom you ask. There is a camp of people that put minimum effort (literally a a single "if" check in the code) and embrace having their stuff cracked and hacked. The logic is that this acts as extra marketing and helps converting pirates (lol). There are also people who use packaged solutions like VMprotect and (previously) Armadillo. This tends to nip piracy in a bud, but creates issues with antivirus false positives. It also makes the software heavier and more fragile. There's also a middle ground of custom protection schemes that, if deployed wisely, can create 100x more headaches to crackers vs the effort spent on coding them in. Not that hard to do, but these aren't drop-ins, obviously.
Also, closely related, is the question of how the licensing works. Previously, most of the shareware used completely offline licensing using "keys" that were either hardcoded into the program or verified algorithmically (read, with elaborate checksums and such). This caused an emergence of keygens and it also fed credit card fraud with people smash-n-grabbing keys in bulk and then published them for the street cred. Surprisingly, a lot of shareware still uses this method and they still bitch and moan about the consequences. The alternative, obviously, is to use online activation. That is, what is sold is an activation token that can be swapped for a machine-specific license, via an exchange with the licensing server. This nearly completely eliminates the CC fraud and it allows for finer control over licensing. There are some drop-in solutions for this, but all of them are really quite basic and almost universally suck. However, the good news is that is fairly simple to roll out your own online licensing scheme in a matter of few work-days (assuming you know a bit of web backend and frontend).