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 thread,
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 as
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 l
>
> So in summary the spec needs daily as an option, and to specify the
> recurring cycle as every n*period >(one of daily, weekly, monthly,
> yearly): and you can drop quarterly since it's just expressed as per
> >3*monthly.
If you're going to go the direction of a {unitType, unitsPerInter
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
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 merchant_
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 ser
Kevin,
We did a second iteration on the prototype to implement subscription
cancellation and upgrade/downgrade. We checked in both the bitcoinj and php
server to be able to test it.
We also worked on our side of the merchant implementation (Kill Bill) to feel
confident that the protocol will su
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,
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...
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
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" wrote:
> Mike and all,
>
> Pierre and I just committed a prototype implementation of the recurr
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 tr
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.
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 l
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
Let's keep fund raising off this mailing list, please. PS bounties don't
work.
On Tue, Jan 28, 2014 at 1:08 AM, Odinn Cyberguerrilla <
odinn.cyberguerri...@riseup.net> wrote:
> Greatly appreciate seeing this discussion occur. This is something that
> potentially could be supported through a bo
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
wi
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 ne
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
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
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.
Note: This is ONE
--
Jeff Garzik
Bitcoin core develo
+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
24 matches
Mail list logo