Just wondering, wouldn't be the cheaper to code a rather simple solution like this:
- generate a new receiving address for the customer, which he can use to pay (the private key can be hashed and stored)
- have a background process in the server which checks the amount paid received enough confirmations
- send payment confirmation to the customer
Or there is some problem with it / not so easy as it seems?
This is the general flow of such an action, except for the stored hash of the private key (that's not necessary at all and non-usable).
The devil is in the detail. How do you generate a new address, how do you store the private key, where do you map it to the customer ?
How do you keep the private keys secure enough so that nobody can access it ?
How exactly does the 'background process' work ? Is it safe against each kind of manipulation or could an attacker simply simulate a payment ?
There is a lot to consider when building such a system.
People who want to have software which handles payments coded for a cheap price, will receive low quality work. And this will cost you way more in the end.
The proper way is to either get some good developer to build the system properly themselves (with security in mind) or to review/audit and setting up an open-source server.
