I'm writing a recurring billing system and I want to be able to contact a customer and request a certain amount of money. Is this possible via bitcoin?

If not, could a URL be provided the customer so he can simply click it and it opens the bitcoin app and initiates a payment process?

  • 2
    There is talk of adding multi-signature transactions in the near future. Depending on how it is implemented it may become possible to allow a business the privilege of initiating the transaction by signing with their private key but not complete the transaction until the customer also signs. In future clients we may see a "needs approval" transaction queue for precisely such an occasion. I leave this as a comment instead of an answer because at present the below answers are entirely correct and there is no way to easily implement recurring billing within Bitcoin itself. Oct 12, 2011 at 15:56
  • You can now use the Bitcoin payment protocol to do this, more info below. Mar 29, 2014 at 20:01

5 Answers 5


You can now use the Bitcoin payment protocol to do this.

Here is an easy to use implementation from Bitpay.

There are already a few wallets that support this (including the reference client). More will be released soon.



There is no way to send messages within the Bitcoin system, and there is no URL link in the Bitcoin client yet. Generally, what you do is provide the customer a Bitcoin payment address and an amount either in the web page, by email, or by some other method.


You can't "contact" a bitcoin user via their address and likely never will because that could be used to compromise the anonymous nature of addresses. Likewise there is no mechanism to request payments or send bills. User can simply choose to pay you.

Thus you will need to contact the user, link unique payment addresses to a user account and track "time remaining" all "out of band".

Say you have a webhosting service which costs 1 BTC per 30 days, prepaid. While there is no concept of periodic billing you could setup your website to create a unique payment address for for each user. By recording user information and payment address in a database you know how a method to match incoming payments to users. When you receive payments by looking up the user account by the address you can "credit' the correct user account. The advantage of doing it this way is the user doesn't need to wait for a bill, pay at any preset time, or wait for service to expire. The concept of periodic payments will need to adapt to bitcoin unique features and limitations.

To improve payment rates at every login you could advise the user on the numbers of days remaining and remind them of payment. User could at anytime send a payment to their unique payment address from any wallet and gain x more days of service based on payment size. You could also have the webservice send the user an email at 7 days remaining, 3 days remaining, and when service is expired.

Actually creating this infrastructure to make it turn key for other companies would be a good bitcoin service.

  • that could be used to compromise the anonymous nature of addresses Not necessarily. You could use something like bitmessage. Of course, that would have all the scaling problems that bitcoin itself has.
    – Nick ODell
    May 16, 2013 at 1:52

If you look at the Bitcoin Wallet app for Android, there is a URI schema used to request money from other users. Unfortunately this isn't part of the desktop version of the application.


There's obviously a demand for a recurring payment system. In my opinion, there are two ways to implement such a system. One is a change to the bitcoin base client itself so that, with explicit authorization of the user, it will send x address x # of bitcoins each x number of days. That kind of implementation would probably have a better chance of getting implemented than something that pulls money from the bitcoin wallet since that kind of action defies the anonymous (and fairly libertarian) nature of bitcoin.

While it's possible that it could be it could be implemented, in my opinion, a better way would actually be to create an API to do this. DeathAndTaxes had a good outline of what such an API would need to do.

My idea of it is somewhat different, but builds on what DeathAndTaxes said. The email reminder would be essential if it's going to be a "push" payment rather than an automatic "pull" payment.

I put this in a bitcointalk thread, but this is really a better place for it.

Here's my idea for an API:

1) Customer submits initial payment for x bitcoins. Future payments are then pegged to the exchange rate for x bitcoins to x dollars (or whatever currency the merchant uses).

2) The service asks for authorization for "recurring billing"

3) If the user accepts, a recurring payment schedule is setup. Email reminders are sent out for payment like DeathAndTaxes said. At the 30 day mark, service is shut off if user has not paid. This could be an automatic thing, or more likely, the API would contact whoever is implemented it that x user hasn't paid and thus needs to have x service disabled.

Actually, another way to implement recurring payments that would make a lot of sense would be with a deluxe wallet client like Armory and not touch the base bitcoin client. In a way, this type of implementation would make much more sense than the API implementation because it can be totally recurring without the user having to do anything other than ensure that the proper amount of bitcoins is in his or her wallet and that it's not an offline wallet. The problem with this type of implementation, of course, is that it would limit recurring payments to Armory (or whatever other wallet client implemented it).

Over time, I wouldn't be surprised if both types of implementations occur. I don't see any reason why they can't both occur at the same time.

  • Who would host the API?
    – Nick ODell
    May 16, 2013 at 1:54
  • @NickODell, I'd say whoever created it would host it. If it's going to be an offical API that everyone would be inclined to use, I'd say bitcoin.org would be the perfect place to host it. But I doubt it would be quite THAT official, unless it gets implemented in one of the clients in which case it wouldn't really be an API.
    – Evan Lynch
    May 16, 2013 at 3:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.