Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WDTNI-0008NM-Kn for bitcoin-development@lists.sourceforge.net; Wed, 12 Feb 2014 06:32:48 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.160.178 as permitted sender) client-ip=209.85.160.178; envelope-from=kgreenek@gmail.com; helo=mail-yk0-f178.google.com; Received: from mail-yk0-f178.google.com ([209.85.160.178]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WDTND-0008Cn-T6 for bitcoin-development@lists.sourceforge.net; Wed, 12 Feb 2014 06:32:48 +0000 Received: by mail-yk0-f178.google.com with SMTP id 79so14130988ykr.9 for ; Tue, 11 Feb 2014 22:32:38 -0800 (PST) X-Received: by 10.236.114.71 with SMTP id b47mr27197462yhh.42.1392186758464; Tue, 11 Feb 2014 22:32:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.170.94.66 with HTTP; Tue, 11 Feb 2014 22:32:18 -0800 (PST) In-Reply-To: References: <0CC0BE1D-1DAA-4994-B034-EB7712F845CF@kill-bill.org> From: Kevin Greene Date: Tue, 11 Feb 2014 22:32:18 -0800 Message-ID: To: Stephane Brossier Content-Type: multipart/alternative; boundary=20cf301af7fd330baf04f22fbd37 X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (kgreenek[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1WDTND-0008Cn-T6 X-Mailman-Approved-At: Wed, 12 Feb 2014 16:36:19 +0000 Cc: Pierre-Alexandre Meyer , Bitcoin Dev Subject: Re: [Bitcoin-development] Extension for BIP-0070 to support recurring payments X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 06:32:48 -0000 --20cf301af7fd330baf04f22fbd37 Content-Type: text/plain; charset=ISO-8859-1 Thanks for humoring my questions! >I think reporting such errors to the wallet would make complete sense. However i am not clear why we would a separate url for that? Hmm, thinking about this more, adding a simple status_code in PaymentRequest would be a much easier way to achieve this. However, continuing to think about this even more, maybe the simple memo field along with an empty set of outputs is enough already. In bitcoinj, right now the code will throw a PaymentRequestException.InvalidOutputs exception if the set of outputs is empty with a message of "No Outputs". There isn't a good way to tell the difference between a payment request that had no outputs and a payment request that had some invalid output(s). *Question to everyone:* How does bitcoin-qt handle a PaymentRequest with no outputs? On Tue, Feb 11, 2014 at 10:01 AM, Stephane Brossier wrote: > Hi Kevin, > > On Feb 11, 2014, at 2:00 AM, Kevin Greene wrote: > > Figured I would have a crack at reviewing this since Mike is out for a > bit. It was great running into you guys at the bitcoin fair in SF! Small > world :) > > > Indeed! It was great meeting you! It's always nice to meet people in > person... > > I like how simple this is. You just give it an url to fetch the next > payment request and a date to fetch it. > > What should happen if the client tries to fetch the PaymentRequest early > or late? > > > If the client tries to fetch too early, then the merchant will return a > PaymentRequest with no output (there is nothing to pay yet). If it fetches > too late, this is merchant specific. It could be that the service got > discontinued -- extreme case -- or that there are now multiple > PaymentRequest pending or that the merchant decided to aggregate those into > one. In that scenario, it could lead to a case where the amount to pay goes > beyond the contract and the wallet would refuse to make the recurring > payment. > > Does it become valid after some date and stay valid for some length of > time? > > > The protocol we sketched does not include (yet) an expiration date. At > this point the contract is fairly minimal, and we could envision adding > more parameters such as expiration date. So at this point the behavior > would be dictated by the merchant. > > Also, what should happen if the client tries to consume the same > PaymentRequest twice (or multiple times) during the same period? > > > The merchant initiates the PaymentRequest and is in charge to make sure > they match the invoices that the client should pay. On the client side, the > wallet is responsible to verify that the contract is respected, so if a > merchant were to issue multiple times the same PaymentRequest, the wallet > would detect it goes beyond the bonds defined in the contract and would > refuse to make the additional Payments. > > I do not think daily/weekly/monthly is flexible enough. What do you think > about having a concrete start time and end time when the next > PaymentRequest will be valid? > > > I agree that daily/weekly/monthly may not be flexible enough. However > specifying a fixed date may be very tricky because in some cases a monthly > subscription may start on a 31st of a month, and depending on the month, > the due date will vary -- could be 30th, 28th, 29th, ... Also note that the > frequency (daily/weekly/monthly) is not used as a polling interval, but is > only used to verify the contract is respected. > > There are multiple viable options to specify that contract and ideally we > could/should support multiple schemes; different merchants could use > different schemes, and the client would decide wether or not he is ready to > accept the terms that will later be enforced by the wallet. But of course > all this flexibility goes against simplicity and so this is tradeoff... > > > This also prevents the wallet from having to remember when it last sent a > payment and getting skewed over time. > > > Today, our current prototype is polling every day -- which is the lowest > granularity we introduced -- and so there is no risk of getting skewed. > > > When a wallet hits the polling_url to download the next PaymentRequest, it > seems we need a way to communicate an error code to the wallet, for example > if the server canceled the contract without the wallet knowing. Perhaps a > separate polling_status_url, with a corresponding ACK message to indicate > if the PaymentRequest is available. What do you think of that idea? > > > I think reporting such errors to the wallet would make complete sense. > However i am not clear why we would a separate url for that? > > One high-level comment -- the wallet in this design doesn't have any way > of knowing when the payments are supposed to end. I feel this is important > to show to the user before they start their wallet polling infinitely. > > > Subscriptions are non ending by definition, but at any time the client > (through the wallet) or the merchant can decide to terminate the > subscriptions -- we did not yet implement cancellation in that prototype > but we are planning to add it later this week. Think of your Netflix > subscriptions, this is never ending (evergreen) until you decide to > terminate it or Netflix does it (abuse, bills not paid,...) > > Thanks for taking a look! > > > On Sat, Feb 8, 2014 at 6:48 PM, Stephane Brossier wrote: > >> Mike, Gavin, >> >> >> We started to work on the merchant side to test the integration of our >> prototype for the recurring payments. We modified the 'Payment Request >> Generator' from Gavin to include a new check box 'set recurring'. We forked >> the code and checked in our modification here: >> https://github.com/killbill/paymentrequest/commit/e530f6ec528266aacfd076d7c3154ad39267c3f3 >> >> We also found a few issues with the code diff that we sent yesterday for >> bitcoinj and checked in the bug fixes in our fork-- so the diff sent >> yesterday is slightly outdated. >> >> So at this point we have a working prototype for bitcoinj and we are >> waiting for your feedbacks. We also started to look at integrating the >> protocol in Kill Bill to check that what is proposed supports indeed the >> business cases of a full recurring billing platform. >> >> Hope to hear from you guys soon! >> >> >> On Feb 7, 2014, at 6:57 PM, Stephane Brossier >> wrote: >> >> Mike and all, >> >> Pierre and I just committed a prototype implementation of the recurring >> payment protocol using bitcoinj. You can find the diff on our fork: >> >> https://github.com/killbill/bitcoinj/commit/40c657c4191498f12539c60316116aa68af368a7 >> >> We did not write the server (merchant side), but wanted to have some >> feedback before going deeper (merchant implementation and tests). We did >> our best to build it on top of the existing BIP-0070 protocol-- only a few >> additions in the messages, but no new calls and no new uri scheme. We >> created a new package 'recurring' where most of the new code lives. >> >> At a high level: >> >> 1. Creation of the subscription: >> >> The initial handshake for creating the subscription is exactly similar to >> the one for the payment protocol (PaymentRequest is used to provide the >> contract) >> >> 2. Wallet can decide to poll the merchants for its active subscriptions. >> >> Here the flow is exactly similar to the payment protocol but the wallet >> receives a callback to verify the payment matches the contract and should >> go through. >> >> Please give us some feedback whenever you have the chance. In the >> meantime we will start implementing the merchant side and test the code. >> >> Cheers! >> >> >> >> On Jan 31, 2014, at 10:13 AM, Mike Hearn wrote: >> >> That looks OK at a very high level. Things you probably want to think >> about: >> >> - How to trigger it off the existing payment protocol (no new top >> level messages or mime types or uri extensions please) >> - Data structures to define the payment schedule >> - Do you allow pre-submission of time locked transactions or not? >> >> I think as you prototype these things will become clearer. You could try >> prototyping either in Bitcoin Core (C++) or bitcoinj (java, look at the >> PaymentSession class). >> >> >> >> On Wed, Jan 29, 2014 at 3:47 AM, Stephane Brossier < >> stephane@kill-bill.org> wrote: >> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> *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 sufficient. 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 merchant. 2. The merchant sends back >>> a msg to the wallet with the detail of the NEW subscription. 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. * >>> >> >> >> >> > > --20cf301af7fd330baf04f22fbd37 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks for humoring my questions!

<= span style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13= px">>I think reporting such errors to the wallet would make complete sen= se. However i am not clear why we would a separate url for that?

Hmm, thinkin= g about this more, adding a simple status_code in PaymentRequest would be a= much easier way to achieve this. However, continuing to think about this e= ven more, maybe the simple memo field along with an empty set of outputs is= enough already.

In bitcoinj, right= now the code will throw a PaymentRequestException.InvalidOutputs exception= if the set of outputs is empty with a message of "No Outputs". T= here isn't a good way to tell the difference between a payment request = that had no outputs and a payment request that had some invalid output(s).<= /div>

Question to eve= ryone:
How does bitcoin-qt handle a PaymentRequest with no outputs?



On Tue, Feb= 11, 2014 at 10:01 AM, Stephane Brossier <stephane@kill-bill.org&= gt; wrote:
Hi Kevin= ,

On Feb 11, 2014, at 2:00 AM, Kevin Gree= ne <kgreenek@gma= il.com> wrote:

Figured I would have a crack at reviewing = this since Mike is out for a bit. It was great running into you guys at the= bitcoin fair in SF! Small world :)

Indeed! It was great meeting y= ou! It's always nice to meet people in person...

I like how sim= ple this is. You just give it an url to fetch the next payment request and = a date to fetch it.

What should happen= if the client tries to fetch the PaymentRequest early or late?
=

If the client tries to fetch too early, then &nbs= p;the merchant will return a PaymentRequest with no output (there is nothin= g to pay yet). If it fetches too late, this is merchant specific. It could = be that the service got discontinued -- extreme case -- or that there are n= ow multiple PaymentRequest pending or that the merchant decided to aggregat= e those into one. In that scenario, it could lead to a case where the amoun= t to pay goes beyond the contract and the wallet would refuse to make the r= ecurring payment.

Does it become valid af= ter some date and stay valid for some length of time?

The protocol we sketched does not include (yet) an exp= iration date. At this point the contract is fairly minimal, and we could en= vision adding more parameters such as expiration date. So at this point the= behavior would be dictated by the merchant.

<= div class=3D"gmail_default" style=3D"color:rgb(51,102,102)">Also, what shou= ld happen if the client tries to consume the same PaymentRequest twice (or = multiple times) during the same period?

The merchant initiates the PaymentR= equest and is in charge to make sure they match the invoices that the clien= t should pay. On the client side, the wallet is responsible to verify that = the contract is respected, so if a merchant were to issue multiple times th= e same PaymentRequest, the wallet would detect it goes beyond the bonds def= ined in the contract and would refuse to make the additional Payments.

I do not think daily/= weekly/monthly is flexible enough. What do you think about having a concret= e start time and end time when the next PaymentRequest will be valid?

I agree that daily/weekly/monthly m= ay not be flexible enough. However specifying a fixed date may be very tric= ky because in some cases a monthly subscription may start on a 31st of a mo= nth, and depending on the month, the due date will vary -- could be 30th, 2= 8th, 29th, ... Also note that the frequency (daily/weekly/monthly) is not u= sed as a polling interval, but is only used to verify the contract is respe= cted. 

There are multiple viable options to specify that contr= act and ideally we could/should support multiple schemes; different merchan= ts could use different schemes, and the client would decide wether or not h= e is ready to accept the terms that will later be enforced by the wallet. B= ut of course all this flexibility goes against simplicity and so this is tr= adeoff...


This also prevents the wallet from having to remember when it last se= nt a payment and getting skewed over time.

Today, our current prototype i= s polling every day -- which is the lowest granularity we introduced -- and= so there is no risk of getting skewed.


When a wallet hits the polling_url to down= load the next PaymentRequest, it seems we need a way to communicate an erro= r code to the wallet, for example if the server canceled the contract witho= ut the wallet knowing. Perhaps a separate polling_status_url, with a corres= ponding ACK message to indicate if the PaymentRequest is available. What do= you think of that idea?

I think reporting such errors to th= e wallet would make complete sense. However i am not clear why we would a s= eparate url for that?

One high-level= comment -- the wallet in this design doesn't have any way of knowing w= hen the payments are supposed to end. I feel this is important to show to t= he user before they start their wallet polling infinitely.

Subscriptions are non ending by def= inition, but at any time the client (through the wallet) or the merchant ca= n decide to terminate the subscriptions -- we did not yet implement cancell= ation in that prototype but we are planning to add it later this week. Thin= k of your Netflix subscriptions, this is never ending (evergreen) until you= decide to terminate it or Netflix does it (abuse, bills not paid,...)

Thanks for taking a look!
<= div>

On Sat, Feb 8, 2014 at 6:48 PM, Stephane Brossier <s= tephane@kill-bill.org> wrote:
Mik= e, Gavin,


We started to work on the= merchant side to test the integration of our prototype for the recurring p= ayments. We modified the 'Payment Request Generator' from Gavin to = include a new check box 'set recurring'. We forked the code and che= cked in our modification here: https://github.com/killbill/paymentrequest/commit/e530f6ec528266aacf= d076d7c3154ad39267c3f3

We also found a few issues with the code diff that we s= ent yesterday for bitcoinj and checked in the bug fixes  in our fork--= so the diff sent yesterday is slightly outdated.

So at this point we have a working prototype for bitcoinj and we are waitin= g for your feedbacks. We also started to look at integrating the protocol i= n Kill Bill to check that what is proposed supports indeed the business cas= es of a full recurring billing platform.

Hope to hear from you guys soon!

On Feb 7, 2014, at 6:57 PM, Stephane Brossier <stephane@kill-bill= .org> wrote:

Mike and = all,

Pierre and I just committed a prototype implementat= ion of the recurring payment protocol using bitcoinj. You can find the diff= on our fork: 

We did not write the server (merchant side), but wanted to have some f= eedback before going deeper (merchant implementation and tests). We did our= best to build it on top of the existing BIP-0070 protocol-- only a few add= itions in the messages, but no new calls and no new uri scheme. We created = a new package 'recurring' where most of the new code lives.

At a high level:

1. Creation o= f the subscription:

The initial handshake for crea= ting the subscription is exactly similar to the one for the payment protoco= l (PaymentRequest is used to provide the contract)

2. Wallet can decide to poll the merchants for its acti= ve subscriptions.

Here the flow is exactly similar= to the payment protocol but the wallet receives a callback to verify the p= ayment matches the contract and should go through.

Please give us some feedback whenever you have the chan= ce. In the meantime we will start implementing the merchant side and test t= he code.

Cheers!



On Jan 31, 2014, at 10:13 AM, Mike Hearn <mike@plan99.net> wro= te:

That looks OK at a = very high level. Things you probably want to think about:
  • How to trigger it off the existing payment protocol (no new top lev= el messages or mime types or uri extensions please)
  • Data structures to define the payment schedule
  • Do you allow pre= -submission of time locked transactions or not?
I think as yo= u prototype these things will become clearer.  You could try prototypi= ng either in Bitcoin Core (C++) or bitcoinj (java, look at the PaymentSessi= on class).



On Wed, Jan 29, 2014 at 3:47 AM, Stephane Brossier <st= ephane@kill-bill.org> wrote:
From what I have seen so far, there seems to be an a= greement that this is a nice feature to add.
We are pretty new to that community a= nd 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= 9; if there is one, but one solution would be to follow Mike's suggesti= on on providing a (prototype) implementation first and then defining/refini= ng the BIP. Odinn also suggested a possible retribution for our time throug= h 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 B= itcoin technology (and ecosystem at large) we would benefit from:
* some feedbacks on the high level proposal
* additional requirements we might have missed<= /span>


I. Abstract
---------------

This describes a protocol to enable r= ecurring 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 k= ind (that is, agreeing on the terms of that subscription contract), and the= n have the wallet make recurring payments without any intervention from the= customer as long as the payments match what the customer agreed on paying.=

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.


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 th= e prototype implementation this is sufficient.
3. The wallet prompts the customer for authoriz= ation.
4. The customer authorizes (or denies) it.
5. The wallet sends the confirmation to the mer= chant.
6. The merchant confirms the subscription was c= reated.

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

From that time on and since Bitcoin i= s a 'push' model, the wallet is responsible to poll the merchant fo= r due payments associated with that subscription. Note that the merchant co= uld specify hints to the wallet on when to poll (specific dates) or not dur= ing the registration of the subscription.


Quick note on the implementation on t= he 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 ac= count status (unpaid invoices, etc.). This goes often hand in hand with a d= unning system, which progressively restricts access as the user's accou= nt is more and more overdue. Since wallets can be offline for an extended p= eriod of time, payments may be missed and lead to an overdue state (e.g. ex= tra fees, service degraded). It is the responsibility of the customer to en= sure the wallet is up often enough for payments to happen.


In that recurring phase where the wal= let polls the merchant, the wallet is responsible to check that payments ma= tch the subscription contract; that is, the amount, frequency of payments, = … match what the customer agreed on. If so, the payment is made with= out 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 transacti= on is sent to the btcnet. The merchant sends an ACK to the wallet and of co= urse checks the states of the transactions on the btcnet to mark that payme= nt as successful.

Subscription chan= ge (optional):
- - - - - - - - - - - - - - - - - - - - - - - -

Optionally we could implement a chang= e in the ongoing subscription to address the upgrade/downgrade scenarios. O= f course, we could also simply support a cancellation followed by a creatio= n of a new subscription, but having that as a one atomic message is probabl= y better. The steps are very similar to the initial registration.
2. The merchant sends back a msg to the wallet = with the detail of the NEW subscription.
3. The wallet prompts the customer for authoriz= ation.
4. The customer authorizes (or denies) it.
5. The wallet sends the confirmation to the mer= chant.
6. The merchant confirms the change in the subs= cription.

Cancellation of t= he subscription:
- - - - - - - - - - - - - - - - - - - - - - - - -

The cancellation is initiated from th= e customer:

1. The customer clicks 'cancel= 9; -> The wallet is informed that it  should not accept any new pay= ment associated to that subscription.
2. The wallet sends a message to the merchant t= o inform about the cancellation.
3. The merchant confirms the subscription was c= ancelled.








--20cf301af7fd330baf04f22fbd37--