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.

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.