path: root/05/cd4c174ffedaf5080fc7d4c93e91511f98f13e

Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mh.in.england@gmail.com>) id 1W9Ib9-0004K9-Ms
	for bitcoin-development@lists.sourceforge.net;
	Fri, 31 Jan 2014 18:13:51 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.214.181 as permitted sender)
	client-ip=209.85.214.181; envelope-from=mh.in.england@gmail.com;
	helo=mail-ob0-f181.google.com; 
Received: from mail-ob0-f181.google.com ([209.85.214.181])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1W9Ib6-0000WZ-Bw
	for bitcoin-development@lists.sourceforge.net;
	Fri, 31 Jan 2014 18:13:51 +0000
Received: by mail-ob0-f181.google.com with SMTP id va2so5392733obc.12
	for <bitcoin-development@lists.sourceforge.net>;
	Fri, 31 Jan 2014 10:13:43 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.182.92.231 with SMTP id cp7mr1424762obb.82.1391192022924;
	Fri, 31 Jan 2014 10:13:42 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.76.99.112 with HTTP; Fri, 31 Jan 2014 10:13:42 -0800 (PST)
In-Reply-To: <D6BCC0C4-EF22-4DE8-868E-825D19C387E3@kill-bill.org>
References: <E1FDB3F2-25ED-4B99-979E-12CE943CBD66@kill-bill.org>
	<CANEZrP10z6_UAHD97mj22kVEGyXgHPQ2PdP_8RxHT5Py+xRP_A@mail.gmail.com>
	<D6BCC0C4-EF22-4DE8-868E-825D19C387E3@kill-bill.org>
Date: Fri, 31 Jan 2014 19:13:42 +0100
X-Google-Sender-Auth: 9Q5Kv5uyTaR0N3Uhonzxq5gIwp8
Message-ID: <CANEZrP0FzTGmp1zbaW1VHJLk5117ZnTSehfF4uMX=+UFS+R_Dw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Stephane Brossier <stephane@kill-bill.org>
Content-Type: multipart/alternative; boundary=001a11c302cc57422d04f14822e0
X-Spam-Score: -0.5 (/)
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
	(mh.in.england[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	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: 1W9Ib6-0000WZ-Bw
Cc: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>,
	Pierre-Alexandre Meyer <pierre@kill-bill.org>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 31 Jan 2014 18:13:51 -0000

--001a11c302cc57422d04f14822e0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 i=
s
> 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 consensu=
s
> via email. I am certainly open to follow 'the way' if there is one, but o=
ne
> 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 whic=
h
> I am interested to pursue if that makes sense.We have quite some experien=
ce
> 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 mig=
ht
> have missedSo, 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 mai=
n
> goal here is to have the customer subscribe to a service of some kind (th=
at
> is, agreeing on the terms of that subscription contract), and then have t=
he
> wallet make recurring payments without any intervention from the customer
> as long as the payments match what the customer agreed on paying.An examp=
le
> of such service would be an online streaming website, to which a user pay=
s
> 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 typ=
e
> of billing is more complicated and there are many variations to it used i=
n
> the industry (pre-paid, =E2=80=A6). For the sake of discussion, we=E2=80=
=99ll focus on
> fixed recurring payments only, but we will keep usage in mind to make sur=
e
> 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=E2=80=99s push model presents new a=
dvantages
> 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 th=
e
> 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 mor=
e
> 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 t=
o
> the merchant.6. The merchant confirms the subscription was created.Ongoin=
g
> 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 credit=
s,
> invoice adjustments, etc. since the last invoice, so the amount to pay fo=
r
> a given billing period may be lower than the regular amount. It could eve=
n
> 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 ope=
ns
> 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 matc=
h
> the subscription contract; that is, the amount, frequency of payments, =
=E2=80=A6
> 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 walle=
t
> 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 ver=
y
> similar to the initial registration.1. The customer clicks 'upgrade',
> 'downgrade', =E2=80=A6 -> A msg is sent to the merchant.2. The merchant s=
ends back
> a msg to the wallet with the detail of the NEW subscription. 3. The walle=
t
> 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 th=
e
> subscription was cancelled.*
>

--001a11c302cc57422d04f14822e0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">That looks OK at a very high level. Things you probably wa=
nt to think about:<div><ul><li>How to trigger it off the existing payment p=
rotocol (no new top level messages or mime types or uri extensions please)<=
/li>
<li>Data structures to define the payment schedule</li><li>Do you allow pre=
-submission of time locked transactions or not?</li></ul><div>I think as yo=
u prototype these things will become clearer. =C2=A0You could try prototypi=
ng either in Bitcoin Core (C++) or bitcoinj (java, look at the PaymentSessi=
on class).</div>
</div><div><br></div></div><div class=3D"gmail_extra"><br><br><div class=3D=
"gmail_quote">On Wed, Jan 29, 2014 at 3:47 AM, Stephane Brossier <span dir=
=3D"ltr">&lt;<a href=3D"mailto:stephane@kill-bill.org" target=3D"_blank">st=
ephane@kill-bill.org</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><b><div =
style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span style=3D"=
font-size:15px;font-family:Arial;font-weight:normal;vertical-align:baseline=
;white-space:pre-wrap">From what I have seen so far, there seems to be an a=
greement that this is a nice feature to add. </span><b><div style=3D"line-h=
eight:1.15;margin-top:0pt;margin-bottom:0pt;display:inline!important">
<span style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical=
-align:baseline;white-space:pre-wrap">We are pretty new to that community a=
nd so we don&#39;t know exactly what the process is, and in particular how =
we reach consensus via email. I am certainly open to follow &#39;the way&#3=
9; if there is one, but one solution would be to follow Mike&#39;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.</span=
></div>
</b></div><br><span style=3D"font-size:15px;font-family:Arial;font-weight:n=
ormal;vertical-align:baseline;white-space:pre-wrap"></span><br><span style=
=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-align:base=
line;white-space:pre-wrap"></span><div style=3D"line-height:1.15;margin-top=
:0pt;margin-bottom:0pt">
<span style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical=
-align:baseline;white-space:pre-wrap">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:</span></d=
iv>
<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span styl=
e=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-align:bas=
eline;white-space:pre-wrap">* some feedbacks on the high level proposal</sp=
an></div>
<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span styl=
e=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-align:bas=
eline;white-space:pre-wrap">* additional requirements we might have missed<=
/span></div>
<br><span style=3D"font-size:15px;font-family:Arial;font-weight:normal;vert=
ical-align:baseline;white-space:pre-wrap"></span><div style=3D"line-height:=
1.15;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:15px;font-f=
amily:Arial;font-weight:normal;vertical-align:baseline;white-space:pre-wrap=
">So, below is a high level description of what we have in mind. If this so=
unds reasonable, we could start working on an implementation.</span></div>
<br><span style=3D"font-size:15px;font-family:Arial;font-weight:normal;vert=
ical-align:baseline;white-space:pre-wrap"></span><br><span style=3D"font-si=
ze:15px;font-family:Arial;font-weight:normal;vertical-align:baseline;white-=
space:pre-wrap"></span><p dir=3D"ltr" style=3D"line-height:1.15;margin-top:=
0pt;margin-bottom:0pt">
<span style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical=
-align:baseline;white-space:pre-wrap"> </span></p><div style=3D"line-height=
:1.15;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:15px;font-=
family:Arial;vertical-align:baseline;white-space:pre-wrap">I. Abstract</spa=
n></div>
<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span styl=
e=3D"font-size:15px;font-family:Arial;vertical-align:baseline;white-space:p=
re-wrap">---------------</span></div><br><span style=3D"font-size:15px;font=
-family:Arial;vertical-align:baseline;white-space:pre-wrap"></span><div sty=
le=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt">
<span style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical=
-align:baseline;white-space:pre-wrap">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.=
</span></div>
<br><span style=3D"font-size:15px;font-family:Arial;font-weight:normal;vert=
ical-align:baseline;white-space:pre-wrap"></span><div style=3D"line-height:=
1.15;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:15px;font-f=
amily:Arial;font-weight:normal;vertical-align:baseline;white-space:pre-wrap=
">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. resourc=
es). Note that there is also usage based billing: for example, the user may=
 need to purchase additional access for premium videos (overage charges). T=
his type of billing is more complicated and there are many variations to it=
 used in the industry (pre-paid, =E2=80=A6). For the sake of discussion, we=
=E2=80=99ll 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.</span=
></div>
<div><b><br></b></div><br><span style=3D"font-size:15px;font-family:Arial;f=
ont-weight:normal;vertical-align:baseline;white-space:pre-wrap"></span><div=
 style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span style=3D=
"font-size:15px;font-family:Arial;vertical-align:baseline;white-space:pre-w=
rap">II. Motivation</span></div>
<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span styl=
e=3D"font-size:15px;font-family:Arial;vertical-align:baseline;white-space:p=
re-wrap">------------------</span></div><br><span style=3D"font-size:15px;f=
ont-family:Arial;vertical-align:baseline;white-space:pre-wrap"></span><div =
style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt">
<span style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical=
-align:baseline;white-space:pre-wrap">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. </span></div>
<br><span style=3D"font-size:15px;font-family:Arial;font-weight:normal;vert=
ical-align:baseline;white-space:pre-wrap"></span><div style=3D"line-height:=
1.15;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:15px;font-f=
amily:Arial;font-weight:normal;vertical-align:baseline;white-space:pre-wrap=
">Bitcoin=E2=80=99s push model presents new advantages for the customer com=
pared to traditional payment methods: the user has control over the subscri=
ption (for example, there is no need to call the merchant to explicitly can=
cel the credit card payments). It also opens the door to subscription manag=
ement tools in wallets (e.g. Hive apps), which would give user an overview =
of what they are paying each month.</span></div>
<br><span style=3D"font-size:15px;font-family:Arial;font-weight:normal;vert=
ical-align:baseline;white-space:pre-wrap"></span><br><span style=3D"font-si=
ze:15px;font-family:Arial;font-weight:normal;vertical-align:baseline;white-=
space:pre-wrap"></span><div style=3D"line-height:1.15;margin-top:0pt;margin=
-bottom:0pt">
<span style=3D"font-size:15px;font-family:Arial;vertical-align:baseline;whi=
te-space:pre-wrap">III. Flow of Operations</span></div>--------------------=
--------------------</b><div><b><br><span style=3D"font-size:15px;font-fami=
ly:Arial;vertical-align:baseline;white-space:pre-wrap"></span><br>
<span style=3D"font-size:15px;font-family:Arial;vertical-align:baseline;whi=
te-space:pre-wrap"></span><div style=3D"line-height:1.15;margin-top:0pt;mar=
gin-bottom:0pt"><span style=3D"font-size:15px;font-family:Arial;vertical-al=
ign:baseline;white-space:pre-wrap">Creation of the subscription:</span></di=
v>
<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span styl=
e=3D"font-size:15px;font-family:Arial;vertical-align:baseline;white-space:p=
re-wrap">- - - - - - - - - - - - - - - - - - - - - - </span></div><br><span=
 style=3D"font-size:15px;font-family:Arial;vertical-align:baseline;white-sp=
ace:pre-wrap"></span><div style=3D"line-height:1.15;margin-top:0pt;margin-b=
ottom:0pt">
<span style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical=
-align:baseline;white-space:pre-wrap">1. The customer clicks &#39;subscribe=
&#39; -&gt; A message is sent to the merchant.</span></div><div style=3D"li=
ne-height:1.15;margin-top:0pt;margin-bottom:0pt">
<span style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical=
-align:baseline;white-space:pre-wrap">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.</span></div>
<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span styl=
e=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-align:bas=
eline;white-space:pre-wrap">3. The wallet prompts the customer for authoriz=
ation.</span></div>
<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span styl=
e=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-align:bas=
eline;white-space:pre-wrap">4. The customer authorizes (or denies) it.</spa=
n></div>
<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span styl=
e=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-align:bas=
eline;white-space:pre-wrap">5. The wallet sends the confirmation to the mer=
chant.</span></div>
<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span styl=
e=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-align:bas=
eline;white-space:pre-wrap">6. The merchant confirms the subscription was c=
reated.</span></div>
<br><span style=3D"font-size:15px;font-family:Arial;font-weight:normal;vert=
ical-align:baseline;white-space:pre-wrap"></span><div style=3D"line-height:=
1.15;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:15px;font-f=
amily:Arial;vertical-align:baseline;white-space:pre-wrap">Ongoing payments:=
</span></div>
</b><div class=3D"im"><b><div style=3D"line-height:1.15;margin-top:0pt;marg=
in-bottom:0pt"><span style=3D"font-size:15px;font-family:Arial;vertical-ali=
gn:baseline;white-space:pre-wrap">- - - - - - - - - - - - - - - -</span></d=
iv>
<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span styl=
e=3D"font-size:15px;font-family:Arial;vertical-align:baseline;white-space:p=
re-wrap"><br></span></div></b></div><b><span style=3D"font-size:15px;font-f=
amily:Arial;vertical-align:baseline;white-space:pre-wrap"></span><div style=
=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt">
<span style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical=
-align:baseline;white-space:pre-wrap">From that time on and since Bitcoin i=
s a &#39;push&#39; 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.</span></div>
<br><span style=3D"font-size:15px;font-family:Arial;font-weight:normal;vert=
ical-align:baseline;white-space:pre-wrap"></span><div style=3D"line-height:=
1.15;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:15px;font-f=
amily:Arial;font-weight:normal;vertical-align:baseline;white-space:pre-wrap=
">Note that we can&#39;t simply have the wallet push X bitcoins every month=
: the user account on the merchant side may have gotten credits, invoice ad=
justments, etc. since the last invoice, so the amount to pay for a given bi=
lling 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 bala=
nce to make sure how much it should pay. This also opens the door for the s=
upport of overage charges.</span></div>
<br><span style=3D"font-size:15px;font-family:Arial;font-weight:normal;vert=
ical-align:baseline;white-space:pre-wrap"></span><br><span style=3D"font-si=
ze:15px;font-family:Arial;font-weight:normal;vertical-align:baseline;white-=
space:pre-wrap"></span><div style=3D"line-height:1.15;margin-top:0pt;margin=
-bottom:0pt">
<span style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical=
-align:baseline;white-space:pre-wrap">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&#39;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.</span></div>
<br><span style=3D"font-size:15px;font-family:Arial;font-weight:normal;vert=
ical-align:baseline;white-space:pre-wrap"></span><br><span style=3D"font-si=
ze:15px;font-family:Arial;font-weight:normal;vertical-align:baseline;white-=
space:pre-wrap"></span><div style=3D"line-height:1.15;margin-top:0pt;margin=
-bottom:0pt">
<span style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical=
-align:baseline;white-space:pre-wrap">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, =
=E2=80=A6 match what the customer agreed on. If so, the payment is made wit=
hout 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 transact=
ion is sent to the btcnet. The merchant sends an ACK to the wallet and of c=
ourse checks the states of the transactions on the btcnet to mark that paym=
ent as successful.</span></div>
<br><span style=3D"font-size:15px;font-family:Arial;font-weight:normal;vert=
ical-align:baseline;white-space:pre-wrap"></span><div style=3D"line-height:=
1.15;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:15px;font-f=
amily:Arial;vertical-align:baseline;white-space:pre-wrap">Subscription chan=
ge (optional):</span></div>
</b><b><div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><sp=
an style=3D"font-size:15px;font-family:Arial;vertical-align:baseline;white-=
space:pre-wrap">- - - - - - - - - - - - - - - - - - - - - - - - </span></di=
v>
<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span styl=
e=3D"font-size:15px;font-family:Arial;vertical-align:baseline;white-space:p=
re-wrap"><br></span></div></b><b><span style=3D"font-size:15px;font-family:=
Arial;vertical-align:baseline;white-space:pre-wrap"></span><div style=3D"li=
ne-height:1.15;margin-top:0pt;margin-bottom:0pt">
<span style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical=
-align:baseline;white-space:pre-wrap">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.</span></d=
iv>
<br><span style=3D"font-size:15px;font-family:Arial;font-weight:normal;vert=
ical-align:baseline;white-space:pre-wrap"></span><div style=3D"line-height:=
1.15;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:15px;font-f=
amily:Arial;font-weight:normal;vertical-align:baseline;white-space:pre-wrap=
">1. The customer clicks &#39;upgrade&#39;, &#39;downgrade&#39;, =E2=80=A6 =
-&gt; A msg is sent to the merchant.</span></div>
<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span styl=
e=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-align:bas=
eline;white-space:pre-wrap">2. The merchant sends back a msg to the wallet =
with the detail of the NEW subscription. </span></div>
<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span styl=
e=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-align:bas=
eline;white-space:pre-wrap">3. The wallet prompts the customer for authoriz=
ation.</span></div>
<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span styl=
e=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-align:bas=
eline;white-space:pre-wrap">4. The customer authorizes (or denies) it.</spa=
n></div>
<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span styl=
e=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-align:bas=
eline;white-space:pre-wrap">5. The wallet sends the confirmation to the mer=
chant.</span></div>
<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span styl=
e=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-align:bas=
eline;white-space:pre-wrap">6. The merchant confirms the change in the subs=
cription.</span></div>
<br><span style=3D"font-size:15px;font-family:Arial;font-weight:normal;vert=
ical-align:baseline;white-space:pre-wrap"></span><div style=3D"line-height:=
1.15;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:15px;font-f=
amily:Arial;vertical-align:baseline;white-space:pre-wrap">Cancellation of t=
he subscription:</span></div>
</b><b><div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><sp=
an style=3D"font-size:15px;font-family:Arial;vertical-align:baseline;white-=
space:pre-wrap">- - - - - - - - - - - - - - - - - - - - - - - - - </span></=
div>
<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span styl=
e=3D"font-size:15px;font-family:Arial;vertical-align:baseline;white-space:p=
re-wrap"><br></span></div></b><b><span style=3D"font-size:15px;font-family:=
Arial;vertical-align:baseline;white-space:pre-wrap"></span><div style=3D"li=
ne-height:1.15;margin-top:0pt;margin-bottom:0pt">
<span style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical=
-align:baseline;white-space:pre-wrap">The cancellation is initiated from th=
e customer:</span></div><br><span style=3D"font-size:15px;font-family:Arial=
;font-weight:normal;vertical-align:baseline;white-space:pre-wrap"></span><d=
iv style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt">
<span style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical=
-align:baseline;white-space:pre-wrap">1. The customer clicks &#39;cancel&#3=
9; -&gt; The wallet is informed that it =C2=A0should not accept any new pay=
ment associated to that subscription.</span></div>
<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span styl=
e=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-align:bas=
eline;white-space:pre-wrap">2. The wallet sends a message to the merchant t=
o inform about the cancellation.</span></div>
<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span styl=
e=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-align:bas=
eline;white-space:pre-wrap">3. The merchant confirms the subscription was c=
ancelled.</span></div>
<br><span style=3D"font-size:15px;font-family:Arial;font-weight:normal;vert=
ical-align:baseline;white-space:pre-wrap"></span><br><span style=3D"font-si=
ze:15px;font-family:Arial;font-weight:normal;vertical-align:baseline;white-=
space:pre-wrap"></span></b></div>
</div></blockquote></div><br></div>

--001a11c302cc57422d04f14822e0--