From what I have seen so far, there seems to be an agreement that this is a 
nice feature to add. We are pretty new to that community and so we don't know 
exactly what the process is, and in particular how we reach consensus via 
email. I am certainly open to follow 'the way' if there is one, but one 
solution would be to follow Mike's suggestion on providing a (prototype) 
implementation first and then defining/refining the BIP. Odinn also suggested a 
possible retribution for our time through crowd-sourcing which I am interested 
to pursue if that makes sense.

We have quite some experience on the subscription side of things and while we 
are growing our knowledge on the Bitcoin technology (and ecosystem at large) we 
would benefit from:
* some feedbacks on the high level proposal
* additional requirements we might have missed

So, below is a high level description of what we have in mind. If this sounds 
reasonable, we could start working on an implementation.

I. Abstract

This describes a protocol to enable recurring payments in bitcoins and can be 
seen as an extension of BIP-0070. The main goal here is to have the customer 
subscribe to a service of some kind (that is, agreeing on the terms of that 
subscription contract), and then have the wallet make recurring payments 
without any intervention from the customer as long as the payments match what 
the customer agreed on paying.

An example of such service would be an online streaming website, to which a 
user pays a fixed recurring monthly fee to access videos (a.k.a. resources). 
Note that there is also usage based billing: for example, the user may need to 
purchase additional access for premium videos (overage charges). This type of 
billing is more complicated and there are many variations to it used in the 
industry (pre-paid, …). For the sake of discussion, we’ll focus on fixed 
recurring payments only, but we will keep usage in mind to make sure the 
protocol will be able to support it as well.

II. Motivation

Subscription based services have been growing in the past few years and so the 
intent it to make it possible for customers to pay in bitcoins. 

Bitcoin’s push model presents new advantages for the customer compared to 
traditional payment methods: the user has control over the subscription (for 
example, there is no need to call the merchant to explicitly cancel the credit 
card payments). It also opens the door to subscription management tools in 
wallets (e.g. Hive apps), which would give user an overview of what they are 
paying each month.

III. Flow of Operations

Creation of the subscription:
- - - - - - - - - - - - - - - - - - - - - - 

1. The customer clicks 'subscribe' -> A message is sent to the merchant.
2. The merchant sends back a message to the wallet with the details of the 
subscription such as the amount to be paid. In reality, there will be more 
information but for the purpose of the prototype implementation this is 
3. The wallet prompts the customer for authorization.
4. The customer authorizes (or denies) it.
5. The wallet sends the confirmation to the merchant.
6. The merchant confirms the subscription was created.

Ongoing payments:
- - - - - - - - - - - - - - - -

From that time on and since Bitcoin is a 'push' model, the wallet is 
responsible to poll the merchant for due payments associated with that 
subscription. Note that the merchant could specify hints to the wallet on when 
to poll (specific dates) or not during the registration of the subscription.

Note that we can't simply have the wallet push X bitcoins every month: the user 
account on the merchant side may have gotten credits, invoice adjustments, etc. 
since the last invoice, so the amount to pay for a given billing period may be 
lower than the regular amount. It could even be zero if the user decides to 
make a one-time payment to the merchant directly using a different wallet. 
Hence, the wallet needs to get the latest invoice balance to make sure how much 
it should pay. This also opens the door for the support of overage charges.

Quick note on the implementation on the merchant side: an entitlement system is 
a piece of logic on the merchant side which grants the user access to certain 
resources depending on the account status (unpaid invoices, etc.). This goes 
often hand in hand with a dunning system, which progressively restricts access 
as the user's account is more and more overdue. Since wallets can be offline 
for an extended period of time, payments may be missed and lead to an overdue 
state (e.g. extra fees, service degraded). It is the responsibility of the 
customer to ensure the wallet is up often enough for payments to happen.

In that recurring phase where the wallet polls the merchant, the wallet is 
responsible to check that payments match the subscription contract; that is, 
the amount, frequency of payments, … match what the customer agreed on. If so, 
the payment is made without asking for explicit approval from customer, and the 
flow is similar to BIP-0070: The message is sent to the merchant, and in 
parallel, a transaction is sent to the btcnet. The merchant sends an ACK to the 
wallet and of course checks the states of the transactions on the btcnet to 
mark that payment as successful.

Subscription change (optional):
- - - - - - - - - - - - - - - - - - - - - - - - 

Optionally we could implement a change in the ongoing subscription to address 
the upgrade/downgrade scenarios. Of course, we could also simply support a 
cancellation followed by a creation of a new subscription, but having that as a 
one atomic message is probably better. The steps are very similar to the 
initial registration.

1. The customer clicks 'upgrade', 'downgrade', … -> A msg is sent to the 
2. The merchant sends back a msg to the wallet with the detail of the NEW 
3. The wallet prompts the customer for authorization.
4. The customer authorizes (or denies) it.
5. The wallet sends the confirmation to the merchant.
6. The merchant confirms the change in the subscription.

Cancellation of the subscription:
- - - - - - - - - - - - - - - - - - - - - - - - - 

The cancellation is initiated from the customer:

1. The customer clicks 'cancel' -> The wallet is informed that it  should not 
accept any new payment associated to that subscription.
2. The wallet sends a message to the merchant to inform about the cancellation.
3. The merchant confirms the subscription was cancelled.

WatchGuard Dimension instantly turns raw network data into actionable 
security intelligence. It gives you real-time visual feedback on key
security issues and trends.  Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
Bitcoin-development mailing list

Reply via email to