So you own the private keys and the cost is about 1% but you will do a call-back to web-servers or page that is running the script.
Both ETH and BTC have priced themselves out of the small payments market due to transaction costs so IOTA sounds good as does Ripple
for taking payments (Cheap as chips) but then use an accumulator maybe and make payments to clients in BTC or better still ETH to keep
external costs down.
Use the notes field in the transaction to add your order number so that the two ends tie up with each other
The idea is that services choose what coins to accept, and with our service they can accept multiple coins without extra effort or multiple API integrations.
We don't keep anyone's money, as soon as it is received it is forwarded to the address provided by the service. We also don't plan to provide currency conversion (accepting in IOTA but receiving in BTC).
We do own the private keys for the temporary addresses created by our system for the payments. But, like I said before, the payments are forwarded almost instantly, there is no user's money sitting there.
When the payment is confirmed our service does a callback to the URL provided.
It is in that URL that the users should provide the indications they will need to verify the payment along with a nonce to verify that the callback is coming from us.
The callback URL should look something like this:
http://example.com?invoice=12345&nonce=DSsdf432Dee342dfHG
then, when our system makes the request, it will use the URL (with the parameters already provided), and append the rest of the parameters, like value, TXID in, TXID out, number of confirmations, etc
