<p>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.</p>

<p>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: <a href="https://www.arf.one" rel="nofollow noreferrer">https://www.arf.one</a></p>

CC BY-SA 4.0
2019-03-01T20:18:56.417Z
2019-03-01T20:18:56.417Z
kozyilmaz
<p>What you can do with Bitcoin protocol is to time-lock your transaction - see <a href="https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki" rel="nofollow noreferrer">BIP 65</a>. 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 &quot;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&quot;. 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 &quot;prolong&quot;. 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.</p>
<p>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.</p>

CC BY-SA 3.0
2017-06-26T19:37:05.040Z
2017-06-26T19:37:05.040Z
2020-06-16T11:10:03.350Z
Wapac
<p>I'm working on an API service to do this exactly:</p>
<p><strong>STARS (Smart Transaction API Reoccuring Service) Protocol</strong></p>
<ul>
<li><a href="https://github.com/patoshii/stars-protocol" rel="nofollow noreferrer">https://github.com/patoshii/stars-protocol</a></li>
</ul>
<p><em>&quot;An API service to setup reoccuring cryptocurrency payments using a shared private key.&quot;</em></p>
<p>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.</p>
<p>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.</p>
<p>As of today, the project is still experimental POC stage, but works. Let me know how it works out. Feedback appreciated!</p>

CC BY-SA 4.0
2020-12-03T17:43:10.050Z
2020-12-03T17:43:10.050Z
Patoshi パトシ
<p>Is it possible to send recurring bitcoin payments via the bitcoin protocol? Is there a service which provides an API to do so?</p>

CC BY-SA 3.0
2015-04-24T11:50:48.003Z
The 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.
Claris
CC BY-SA 3.0
2015-04-24T15:11:03.603Z
@Bitcoin Coinbase's competitor, Bitpay, has recurring payments too.
Nick ODell
CC BY-SA 3.0
2015-04-25T11:23:47.897Z
@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 Gurnee
CC BY-SA 3.0
2016-09-16T17:53:21.253Z
Not Bitpay, @ChristopherGurnee. Bitpay just sends bitcoin invoices by email every month (for example).
fiatjaf
CC BY-SA 3.0
2016-09-16T17:57:24.483Z
Everywhere 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.
fiatjaf
<payment-processors><recurring-payments>
Who provides a Bitcoin recurring payments API?
LibertyVPS
# Who provides a Bitcoin recurring payments API?

(Asked by: username_0 on 2015-04-24)

Is it possible to send recurring bitcoin payments via the bitcoin protocol? Is there a service which provides an API to do so?

**Tags:** payment-processors, recurring-payments

> **Comments:**
> **username_1**: The 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.  
> **username_2**: @Bitcoin Coinbase's competitor, Bitpay, has recurring payments too.  
> **username_3**: @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).  
> **username_4**: Not Bitpay, @username_3. Bitpay just sends bitcoin invoices by email every month (for example).  
> **username_4**: Everywhere 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.  

---

## 3 answers

### Answer by username_5 on 2019-03-01. Score: 1

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 @username_6 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>


---

### Answer by username_6 on 2017-06-26. Score: 0

What you can do with Bitcoin protocol is to time-lock your transaction - see [BIP 65](https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki). 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.


---

### Answer by username_7 on 2020-12-03. Score: 0

I'm working on an API service to do this exactly:

**STARS (Smart Transaction API Reoccuring Service) Protocol**

* <https://github.com/patoshii/stars-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!


---

