Thanks for the explanation. I agree that makes sense, and you did actually
explain this before, I just didn't connect the dots :)
The accompanying BIP should explain all this, so the rationale for the
design and how you use it is made clear to developers.
I've CCd Jeff and Stephen on this
Hey there,
So the essence of this protocol is as follows:
enum PaymentFrequencyType {
WEEKLY = 1;
MONTHLY = 2;
QUARTERLY = 3;
ANNUAL = 4;
}
message RecurringPaymentDetails {
// Namespace for the merchant such as org.foo.bar
required string
Forgive me if I missed it, but the spec doesnt look like it can handle only
handle periods of per week, per month, per quarter rather than 'n period'.
I take Paypal as a reference example for subscription payments where you
can set recurring to every: n days, n weeks, n months, n years. That way a
Given the enormous number of variations on time periods for a
recurring payment, might it be better to simple allow a list of
timestamps? It costs almost nothing, bandwidth wise, and shifts the
thinking to the merchant platform. That doesn't give you an infinite
time frame, but you just get a new
Hi Mike, Jeremy, Drak,
Before going through your questions, I would like to bring some clarity on a
few key elements in that protocol. There are really two aspects to it:
The contract negotiation; when the user first subscribes, it is prompted by a
contract that will define the payment bounds
Mike,
Just want to follow up with you and the community in general regarding the
BIP0070 extension for recurring billing. At this point we have a working
prototype that we checked-in in our fork of bitcoinj
(https://github.com/killbill/bitcoinj). We tested it by extending the php
'payment
Hi Kevin,
On Feb 11, 2014, at 2:00 AM, Kevin Greene kgree...@gmail.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 you! It's always nice to meet
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,
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 :)
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
Hey guys,
I'm on vacation now so won't be able to take a look until I'm back in a
couple of weeks but the approach sounds reasonable based on your
description.
On 8 Feb 2014 08:28, Stephane Brossier steph...@kill-bill.org wrote:
Mike and all,
Pierre and I just committed a prototype
Sending this again and truncating since apparently the message body was too
long.
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
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:
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
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
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
Hi,
[I sent this email 2 days ago prior my registration to the mailing list; please
forgive me if this is a duplicate]
I would like to propose an extension to the Payment Protocol (bip-0070) to
address the case of recurring payments in Bitcoin -- new bip or modification of
bip-0070.
There
+1 to the idea of recurring payment requests.
Perhaps one way to realize this would be to add an optional URL to the
PaymentRequest object where the next PaymentRequest can be fetched and the
date at which the merchant expects the next payment.
On Mon, Jan 27, 2014 at 6:36 PM, Stephane Brossier
Yes, recurring payments and subscriptions is a frequently-requested
feature. It needs a new BIP. Here is an outline:
The situation is somewhat analogous to HTML5 local storage. The remote
(merchant) wants to initiate a persistent behavior. This is bitcoin, so we
have a push model for payment,
It could be useful to schedule x payments for y amount every z time
period, but you'd want to be able to pause or cancel at any time.
If you want the merchant to be able to request a series of payments
like a subscription, the merchant might also be able to request that
the subscription be paused
Greatly appreciate seeing this discussion occur. This is something that
potentially could be supported through a bounty - possibly a process BIP?
Possibly related: https://gist.github.com/ABISprotocol/8515891
Yes, recurring payments and subscriptions is a frequently-requested
feature. It
I think the right approach for this is to actually implement it and
*then* propose
a BIP. There are so many possible features we could add to the payment
protocol, any other approach would rapidly turn into lots of people
deciding to do the fun bits and often leaving others doing the hard work
21 matches
Mail list logo
