How do I integrate payment options? I've seen 3rd party solutions.
This is the heart of your business right here. This is the inner sanctum. The actual way that money transfers from
victim customer to coder. Everything else is just for show. This is the real meat and potatoes.
Before we decide how it's done, we have to consider:
What exactly is this nightmare scenario?
Well it's different for every person.
It could be:
You know, these guys:
Or it could be:
Or it could be:
But for me, none of those are the real nightmare scenario.
The nightmare scenario is just this:
That's the one that has me waking in the night, trembling with fright.
Building the wrong product, with no marketing plan, is far more damaging to your business than having a flawed copy protection mechanism.
Expensive 3rd party solutions give me no solace in the face of that fear. And the hackers don't scare me. People who prefer a cracked version of your product: those people are not your customers.
With this in mind, I write my own very, very simple copy-protection mechanism. It's easy to write and it's easy to change.
Here's an outline of my technique. It's straightforward, causes very little disruption to the end user, and it certainly works.
(Of course there is a lot more detail in the book but I don't need to oversell, do I?)
The customer (hmm, let's call the customer "Daphne"), OK, Daphne clicks a "Buy Now" button that takes her to PayPal.
Daphne takes out her credit card, enters her details and completes the payment.
Daphne is then redirected back to your website, on a specific page, as part of a form POST. This form post is an instant payment notification which includes Daphne's name, email address and a PayPal id.
You check with PayPal if this PayPal id is legitimate: it is, so you store the details of Daphne's purchase and generate a unique, un-guessable, easy-to-type 'key' for Daphne to use.
Now that you know Daphne is a legitimate customer, you present her with the key. You display it on screen, along with a warm welcome message, a few words about your eternal gratitude and some helpful instructions for making use of the key. Secondly, you email the key to Daphne along with the same welcome message and the same instructions on using the key to unlock the application.
Inside the application, Daphne clicks the 'register' button. She enters her key.
The application takes some information about Daphne's machine (more details — see book!), plus the product id, plus the key and sends them to your website. These details are checked (is this key OK? Have we seen it too many times?)
If everything checks out, then the result is salted with a "shared secret", hashed and returned to the application.
The application also performs the same procedure (machine info + product id + key + shared secret, hashed) and compares its own result to the result received from the server.
If all is good then the program is 'unlocked'. The result of the hashing is stored. It is also re-calculated and checked every single time the program is run, and also at random intervals.
Note that this is not a perfect solution: a hacker could circumvent it. Here's the kicker: So long as the license code is executed on a customer's machine it's impossible to write a perfect solution. You can spend years of your life looking for a perfect technique: or you can ship a working product this month and see real customers spend real money.
People who are willing to expend considerable energy circumventing it are not your customers. And real customers know that if they look online for a 'cracked' copy they're more likely to end with a virus than an actual cracked copy. There's a great justice in that.
I'm not interested in getting into an arms race against crackers. All that matters is that it's a good enough solution to stop potential customers from considering circumventing it. For this reason I also obfuscate my assemblies. (More details about this... you know where to look!)
There are many more security improvements that could be made but they generally involve a tradeoff between Daphne's convenience and my security. (I've thought about many of the potential tradeoffs and can write about them in detail if you need more information, or remain unconvinced.)
This technique relies on the customer's computer being connected to the internet (during initial registration only). Eventually you'll get customers who need offline activation. But on day 1, when you're shipping the product you don't need to worry about offline activation. (Funnily enough... the book covers that pretty darn well too!)
If you have feedback on this technique, or if you have further questions, please do not hesitate to email me:
leonignore this@ignore this tooyourfirstproduct.com
I'll be sure to respond with a personal and thoughtful reply.