Recurring payments

[2_Thumbs_Up]

The topic of recurring payments came up on reddit regarding Github subscriptions. So I started to think a little bit and wondered what the plans are for this. Currently some services such as Coinbase apparently offer this but it would be good if the Bitcoin ecosystem offered some standard way to do this, in order to not lock people up to specific companies.

First, if there has been any discussions on this previously someone could please link it to me.



I think we need a standardized adress book in order to seemlessly make this happen.

Say I would like to subscribe to an internet service. Ideally, it should be as easy as clicking on a link to download all the information for the recipient and store it in my Bitcoin client. The Bitcoin client could then tell the user when a payment is coming up, and the user can choose wether to pay the bill or end the subscription.

There are a few things that this adress book needs. It needs the name of the recipient, some information about the subscription, a seed that lets the user generate new adresses by himself and preferably a link that lets the client look up the current price in BTC and any other info that may change every time a payment needs to be done.

If a user of a service had all of this information stored locally, subscriptions and bill payments would be as easy as opening your client and click a button that acknowledges the transaction. The user could also set it to allow automatic payments to trusted services.

Unfortunately I'm not good enough on the technical side of things to really speak about how this would best be implemented. So this thread is about general discussion on how to best allow recurring payments in the bitcoin ecosystem in a standardized way. It seems to me that there are two important things to allow this. A standardized way to add recipients in the Bitcoin client such as a contact csv file with some extra fields for bitcoin information, and a standard for internet services to let the users look up information that may change from payment to payment (such as the BTC denominated price).

Thoughts?

[Peter R]

There are many ways recurring payments can be implemented with the existing protocol.  Here are three off the top of my head:

1.  Use a third-party wallet like Coinbase and grant direct-debit permission to the service provider;

2.  Receive a notification (email, wallet app, etc.) that a bill is due and pay it as a standard bitcoin payment;

3.  Fund a 1-of-2 wallet where both you and the service provider have signing authority.

[franky1]

the OP started off taking about recurring payments then meandered off into th direction of explaining addressbooks.

if i wanted to repeatedly pay someone then addressbooks are not REQUIRED

some wallets can easily develop a feature that simply uses a fresh bitcoin address keypair. that is designated as monthly payments, that way the user can keep their random spending separate from contractual monthly spends. and ensure the contractual spend address is always topped up

the feature could also has a calendar that sets reminders or an auto send to whomever they are contracted to pay each month at specific times.

having a global address book can be useful at times. but some people dont want to see the blockchain showing when a gas/water rate or electricity bill is processed publicly (blockchain.info tags for instance). but they can easily use address labels in their own wallet to know who is who, privately

[2_Thumbs_Up]

There are many ways recurring payments can be implemented with the existing protocol.  Here are three off the top of my head:

1.  Use a third-party wallet like Coinbase and grant direct-debit permission to the service provider;

The goal was to avoid solutions that lock you up to specific services. We don't want a situation where you need a coinbase account to subscribe to the New York Times and a Bitpay account to pay your rent.

2.  Receive a notification (email, wallet app, etc.) that a bill is due and pay it as a standard bitcoin payment;

Yes email is possible, but adds unneccessary steps. I don't get my regular bills in the mail. They go directly to my e-bank, and I just need to verify them. Similarly a bitcoin client should be able to handle recurring payments all by itself.

My proposal consists of wallet notifications and regular bitcoin payments. But there are some propblems that you are not adressing, such as the price of BTC may have doubled since your last payment so your client can't know how much it needs to pay.

Fund a 1-of-2 wallet where both you and the service provider have signing authority.

Sure, that could be useful. But the point was to make a standard easy way to set this up. Click a link and be done with it. I want a standard way to set up recurring payments so that all web sites could easily set up bitcoin subscriptions. This suggestion could be part of it if neccessary, but it's not solving the problem I'm talking about.

the OP started off taking about recurring payments then meandered off into th direction of explaining addressbooks.

Sorry if I was a bit unclear. I'm not necessarily talking about an adress book in the usual sense, more of a database of all the services you subscribe to. This is quite close to an adress book though since it's just a list of recipients you do regular payments to. I'm also talking about how to make the best use of this database to make the user experience as good as possible.

To make my self short, my suggestion consists of three things:

1. A database of recipients with standardized entries (recipient name, service info, payment info, adress seed, a link so the client can automatically look up info that changes with time). We need a standard for this so that all clients are compatible with all subscription based services.

2. A standard way to easily add entries to the database. I should be able to go to a subscription based web site, click "pay with bitcoin" and automatically download the neccessary info to my bitcoin client, and be able to handle all payments from the client from that point on.

3. A standard for web sites to provide information that changes with every payment, such as the price in BTC, so that a bitcoin client could look it up at the moment of payment.

I hope that was a lot clearer.

The reason I was talking about an adress book was that number 1 above is very close to it, and it may make sense to store recurring payment recipients in the same database as regular recipients (friends), but this is not necessary.

[xDan]

Automated payments built into a wallet are a great idea!

Maybe just some kind of API? The service we are subscribing to provides a http end point where our wallet can regularly poll for invoices from.

Implemented like the bitcoin URL format.

bitcoin-subscription:http://service.com/subscription/id_12345?btc-price=0.01&subscriptionFrequencyDays=30

We click this then our wallet software lets us confirm the BTC amount and subscription payment frequency in our wallet (the wallet converting BTC to our local currency, and storing *that* amount as well, so it can ensure future BTC invoices are within a certain tolerance of this price).

Polling this URL just returns info on due invoices:

{dueInvoices : [{productName:"your monthly llama socks", priceBTC:"0.0001",address:"1bitcoinaddress"}], {subscriptionInfo:"In good standing"}}

Our wallet would then pay automatically assuming the BTC quoted is within some tolerence value of the original quote (converting to our local currency to perform this check) and no more than the desired number of times per month.

[franky1]

The reason I was talking about an adress book was that number 1 above is very close to it, and it may make sense to store recurring payment recipients in the same database as regular recipients (friends), but this is not necessary.

your idea has nothing to do with recurring payments.. your just trying to make a business directory.

now here is some flaws.

imagine i had to pay XYZ inc.

they would NEVER use 1 bitcoin address for all transactions. but they would however use one address PER customer. so your third party service directory would be filled with 1000 addresses linked to XYX inc, because 1000 customers use them regular.

a dirctory service which links businesses to a bitcoin address is only useful when the address is a global address. such as a donation address or an address that does not require auditing payments and linking paymnets to customers.

recurring payments would in your examples not require your service. as it is easier for the customer to use their own wallet address label s to identify who they are paying.

as for those 'donation addresses' blockchain.info already has tags, making it easy for people to see their payment was made to seans outpost or other charities listed.

im still failing to se what point your trying to make that a service you provide is an essential tool for recurring payments. seems more like an information grab to make bitcoin addresses more transparent and less Pseudonymous.

either way, i wont be using your business directory. so have a nice day


 

[Peter R]

@ 2_Thumbs_Up

Should the service provider "pull" the funds from you?  Or should you "push" the funds to the service provider?  I think you are "overthinking" this:


PUSH SOLUTION #1
=============

Coinbase-style email invoice that dynamically adjusts the bitcoin price encoded in the QR code.  You open the email, scan the QR code with your phone, and press "send" if you agree to the charges.  


PULL SOLUTION #1
=============

User's wallet creates a 1-of-2 bitcoin address based on one key controlled by the user, and another key controlled by the service provider¹.  The user then keeps this multisig address funded and the trusted service provided can debit the appropriate amount whenever necessary.  If the user wants to cancel the service or begins to lose trust in the service provider, he can withdraw all his funds to an address under his sole control.


There are probably lots of other ways to do it too.  And "yes" you will need to do some work to get this working


¹The service provider just needs to provide a ECDSA public key.  In fact, the service provider could even use the same key pair for all his customers.

[franky1]

Automated payments built into a wallet are a great idea!

Maybe just some kind of API? The service we are subscribing to provides a http end point where our wallet can regularly poll for invoices from.

Implemented like the bitcoin URL format.

bitcoin-subscription:http://service.com/subscription/id_12345?btc-price=0.01&subscriptionFrequencyDays=30

We click this then our wallet software lets us confirm the BTC amount and subscription payment frequency in our wallet (the wallet converting BTC to our local currency, and storing *that* amount as well, so it can ensure future BTC invoices are within a certain tolerance of this price).

Polling this URL just returns info on due invoices:

{dueInvoices : [{productName:"your monthly llama socks", priceBTC:"0.0001",address:"1bitcoinaddress"}], {subscriptionInfo:"In good standing"}}

Our wallet would then pay automatically assuming the BTC quoted is within some tolerence value of the original quote (converting to our local currency to perform this check) and no more than the desired number of times per month.

yep i get your idea:
bitcoin URi
bitcoin: bitcoin:1Ar4nd0m4ddr3ssBlahBlahBlah?amount=1&label=NewYorkTimes&recurring=yes&duration=30days
and the wallet does the rest

PUSH SOLUTION
==========

PULL SOLUTION
==========

bitcoin is always a PUSH system. no one should take fund without authorization.

when having funds in coinbase, coinbase owns the keys, so you simply set up an arrangement that you allow funds to go to XYZ inc once a month, and coinbase pushes it to XYZ inc on those dates

same goes for (hopefully future) personal wallet apps. you set up the wallet feature to push transactions to XYZ/newyorktimes once every 30 days and our wallet automatically does it.

all that new york tiimes or XYZ inc can and should do, is to provide the customer with an URi that helps users setup the payment schedule faster. thus giving the customer full control of keeping the schedule active, or cancelling. and not allowing the end recipient any authority to just take funds as they please

[Peter R]

PUSH SOLUTION
==========

PULL SOLUTION
==========

bitcoin is always a PUSH system. no one should take fund without autherisation.

Bitcoin is a PUSH system from the perspective of the protocol, but a 1-of-2 address with one key controlled by a service provider is a PULL-style payment system from the perspective of the user's wallet.  

[2_Thumbs_Up]

Automated payments built into a wallet are a great idea!

Maybe just some kind of API? The service we are subscribing to provides a http end point where our wallet can regularly poll for invoices from.

Implemented like the bitcoin URL format.

bitcoin-subscription:http://service.com/subscription/id_12345?btc-price=0.01&subscriptionFrequencyDays=30

We click this then our wallet software lets us confirm the BTC amount and subscription payment frequency in our wallet (the wallet converting BTC to our local currency, and storing *that* amount as well, so it can ensure future BTC invoices are within a certain tolerance of this price).

Polling this URL just returns info on due invoices:

{dueInvoices : [{productName:"your monthly llama socks", priceBTC:"0.0001",address:"1bitcoinaddress"}], {subscriptionInfo:"In good standing"}}

Our wallet would then pay automatically assuming the BTC quoted is within some tolerence value of the original quote (converting to our local currency to perform this check) and no more than the desired number of times per month.

Thank you for your comment.

An API of some sort is definitely part of what I'm talking about, altough I'm not knowledgeable enough to comment on your specific proposal.

your idea has nothing to do with recurring payments.. your just trying to make a business directory.

now here is some flaws.

imagine i had to pay XYZ inc.

they would NEVER use 1 bitcoin address for all transactions. but they would however use one address PER customer. so your third party service directory would be filled with 1000 addresses linked to XYX inc, because 1000 customers use them regular.

The ideal way to use bitcoin is one adress per transaction, not per customer. That is why I specifically said the database should contain an adress seed, not just an adress. That lets the customer generate a new adress for every transaction. It was implicit that every customer should have their own wallet seed.

See HD Wallets for what I'm talking about.

[2_Thumbs_Up]

bitcoin-subscription:http://service.com/subscription/id_12345?btc-price=0.01&subscriptionFrequencyDays=30

[...]

{dueInvoices : [{productName:"your monthly llama socks", priceBTC:"0.0001",address:"1bitcoinaddress"}], {subscriptionInfo:"In good standing"}}

A small thought on this part. This is most definitely along the lines of what I had in mind.

However, I don't think that the URI should necessarily be limited to only subscriptions. I do think there is a need for an easy way to add recipients of any kind. Subscriptions are only a subset of all the people you ever send bitcoins to multiple times. So maybe the URI should be more generic, and have a field that specifies what type of recipient it is so the bitcoin client knows when to handle it as a subscription, rather than a friend or a business.

[franky1]

im kind of understanding now..

your not trying to be a business directory
your not trying to lobby wallet developers to add automatic payments features into bitoin-core.

what you propose is that you are a payment processor. where people pay you an amount and you ensure the funds get distributed to the agreed recipient list..

and your last post where you make these address seeds, i guess you will be the account manager for the business recipients too. in which case you can pay thos businesses OFF-CHAIN and simply allow them to withdraw funds.. there is no need for seeded addresses on your server, for businesses to get paid. either the business themselves provide their own virgin addresses. or they use yor service to receive funds and simply receive the lump sums and a list of who paid what.

the flaw.. bitcoin is suppose to be about self management. so most of us would prefer to get dev's to implement self controlled auto repayments. instead of having third party services hold our stash with promises they will pay out on time.

[xDan]

bitcoin-subscription:http://service.com/subscription/id_12345?btc-price=0.01&subscriptionFrequencyDays=30

[...]

{dueInvoices : [{productName:"your monthly llama socks", priceBTC:"0.0001",address:"1bitcoinaddress"}], {subscriptionInfo:"In good standing"}}

A small thought on this part. This is most definitely along the lines of what I had in mind.

However, I don't think that the URI should necessarily be limited to only subscriptions. I do think there is a need for an easy way to add recipients of any kind. Subscriptions are only a subset of all the people you ever send bitcoins to multiple times. So maybe the URI should be more generic, and have a field that specifies what type of recipient it is so the bitcoin client knows when to handle it as a subscription, rather than a friend or a business.

You mean, you want a way to get a recurring unique payment address each time you just send money to a friend?

A key problem I see with this "seed" idea is that the person is not guaranteed to keep the same wallet. They may lose the seed. You really do need to ask them for a new address each time. There has to be some communication there - hey pal, still using the same wallet/seed? In which case it may as well be: hey pal, give me a new address.

The simple answer is a centralised service, but of course we don't want that I don't really see much of a solution here, unless there is direct communication between wallets, which may be tricky...