It's just bitcoind + about 200 lines of code. BitPay and Coinbase are only (maybe) useful if you need a guaranteed USD value right away when someone pays you. If you're willing to accept a little exchange-rate risk, I
highly recommend handling payments yourself.
Until very recently, I was using the bitcoind accounts pattern (getaccountaddress & getbalance) recommended from about 2011 to 2014. But this has been deprecated for a few years, and it seems to be
broken in 0.16. In order to quickly work around the 0.16 bug, I switched to the one-address-per-user anti-pattern (getaddress -> put this address in your database for the user -> getreceivedbyaddress) which you should really
not do because it involves address reuse. (But the forum's case of reusing addresses once or twice isn't
the end of the world, which is why I'm accepting it for now.)
I haven't decided yet how I'll handle payments in the long-term. Bitcoind-accounts were kind of nice in how they handled payments as user balances rather than invoices. It allows for easier, closer integration with your site, I think, and it makes it easier to think about a lot of edge cases. It wouldn't be all that difficult to basically re-implement bitcoind-accounts on my end so as to keep things roughly as they are while avoiding address reuse.
On the other hand, I feel like the ecosystem is mainly moving in the direction of invoices rather than balances. Bitcoind's development seems to be focused on that use-case, and LN fits far more naturally into an invoice-based system. For this, I'd be inclined to switch to BTCPay (which will support LN when possible), but that'd require a total rethink and rewrite of my payments code.
So:
If you want an invoice-based system similar to PayPal, Coinbase, or BitPay, or if you want to be more future-proof, use
BTCPay.
If you want to do what the forum does and deal in user balances rather than invoices, it's pretty easy to use bitcoind directly. Something like (pseudocode):
# you have a SQL table `addresses` with columns user, time, address
# and a table `spends` with columns user, time, amountSpent
def getAddress(username):
address = sqlQuery("select address from addresses where user=% order by time desc limit 1", username)
if address is null or bitcoindQuery("getreceivedbyaddress % 0", address) is not 0:
address = bitcoindQuery("getnewaddress")
sqlQuery("insert into addresses values (%, NOW(), %)", username, address)
return address
def logUserSpend(username, amount):
sqlQuery("insert into spends values (%, NOW(), %)", username, amount)
def getBalance(username, minConfirmations):
balance = 0
for address in sqlQuery("select address from addresses where user=%", username):
balance += bitcoindQuery("getreceivedbyaddress % %", address, minConfirmations)
totalSends = sqlQuery("select sum(amountSpent) from spends where user=%", username)
return balance - totalSends
# The above is conceptually how you do it, but you may want to
# add something to avoid so many calls to bitcoindQuery, which is
# a slow operation. As written, this doesn't scale to hundreds of
# addresses per user. For example, you may want to store balances
# for old addresses and assume that the user will not reuse them,
# or poll bitcoind's listsinceblock looking for addresses for
# whom you should update the balances in your database.
def exampleBuyItem(phase, user):
if phase is entry:
print "Please pay to %", getAddress(user)
elif phase is registerPayment:
sqlQuery("set transaction isolation level serializable")
sqlQuery("start transaction")
if getBalance(user, 6) >= price:
sendUserTheItem()
logUserSpend(user, price)
else:
print "Not enough money"
sqlQuery("commit")
