Is it possible to send recurring bitcoin payments via the bitcoin protocol? Is there a service which provides an API to do so?
2The bitcoin protocol has no support for recurring payments, as all transactions are pushed rather than pulled. Clients could make their own support for this, but nobody has beyond centralized services like Coinbase.com.– ClarisApr 24, 2015 at 11:50
1@Bitcoin Coinbase's competitor, Bitpay, has recurring payments too.– Nick ODellApr 24, 2015 at 15:11
1@Bitcoin A short note for the truly pedantic like me: such services are known as custodial wallets—in other words, wallets where the user has no control over any of their private keys. The term centralized has a different meaning (e.g. GreenAddress.it is a centralized wallet, though it's not custodial, it's multisig).– Christopher GurneeApr 25, 2015 at 11:23
Not Bitpay, @ChristopherGurnee. Bitpay just sends bitcoin invoices by email every month (for example).– fiatjafSep 16, 2016 at 17:53
1Everywhere I see people saying, like @Bitcoin here, that "the protocol has no support blablabla". There isn't a protocol that has support for this. Credit cards protocol have no support for recurring payments too. What can be done is for a payment service to do like Bitpay does: send an invoice every month to the payer and notify the payee (through a webhook) of the payment -- or, this is important, of the lack of a payment (after, say, 2 days), so the account can be cancelled. That is what should be happening with credit cards that are cancelled or Coinbase accounts that are out of funds.– fiatjafSep 16, 2016 at 17:57
There is no ready-made recurring payment solution at the moment, however this can be achieved at application level by constructing pre-signed transactions or using CLTV's as @Wapac suggested. CLTV approach may have a downside though, you will be paying transaction fees twice in case you decide to cancel.
A more sophisticated mechanism may be creating a non-custodial, multi-sig wallet service that keeps track of your recurring payments and notify you if any action is needed. Disclosure, I am involved in such a solution called: https://www.arf.one
What you can do with Bitcoin protocol is to time-lock your transaction - see BIP 65. This allows you create a transaction that the recipient can not spend for a certain number of blocks while you can (or vice versa, which is more common). So imagine that you create and publish that transaction and set that the recipient could not spend it for about 1 month. This is a building element you can use to create something like recurring payments. For a year long month-by-month subscription (but cancel anytime) you would need 12 of those time-locks. You would publish it and once the recipient would see the transaction confirmed, they would know "this guy just created monthly subscription with us and unless he cancels, we will be able to get the money each month for next 12 months". Obviously, if you create 12 of those and you'd like to have longer subscription, you would need to create more of those later to "prolong". All this can be implemented in the user wallet including some kind of notification that your subscription needs to be prolonged and if you want to do this etc. That's more about UI and UX, however.
So in general, I'd say yes. On API side - depends, there are libraries for various languages for creating your custom transactions, but this is probably not what you were asking for as I believe you were looking for something higher level than manual transaction building.
I'm working on an API service to do this exactly:
STARS (Smart Transaction API Reoccuring Service) Protocol
"An API service to setup reoccuring cryptocurrency payments using a shared private key."
Currently there is no way to do reoccurring bitcoin payments on the protocol itself that is shelf executing. A work around most people do is by using time-lock transactions but it has its limitations. Basically locking your BTC for X amount of time before the recipient can spend it.
I built an API where you provide a private key and load Bitcoin in it, then set the amount and time you want it distributed to the receiver. Obviously, this isn't a decentralized solution as these keys need to be stored on a central server in order to do the processing. I've mitigated most of the security concerns by not giving users the ability to interact with the API via an internet IP address, but using another blockchain to pass the details over encrypted.
As of today, the project is still experimental POC stage, but works. Let me know how it works out. Feedback appreciated!