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 support advanced business cases. At this point
it is looking promising, but more work is needed to conclude.
We wanted to follow up on a few pervious points you raised:
> However, continuing to think about this even more, maybe the simple memo
> field along with an empty set of outputs is enough already.
From our merchant side (Kill Bill), we do indeed use this field to report
successes or errors. Maybe it would be useful to extend PaymentACK with a
boolean success field (so the wallet doesn't commit the transaction in case of
failures)?
> 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.
We extended our RecurringPaymentDetails message to support this use case, as it
solves the problem of subscription changes and cancellations for free.
We introduced the concept of a subscription, referred to by a unique id (the
tuple merchant_id,subscription_id should be globally unique), which has
multiple contracts (RecurringPaymentContract). Besides payment bounds, each
contract has a validity period: generally, a subscription will have a unique
active contract at a given time and potentially one or more pending ones.
For example, say you are on the gold plan (1 BTC/mo.) and want to downgrade to
a bronze plan (0.5 BTC/mo.) at your next billing date. Wshen you click
"Downgrade" on the merchant site, you will update your wallet with two
contracts: the current valid one until your next billing date (for up to 1
BTC), and a pending one, starting at your next billing date (for up to 0.5
BTC/mo. and without an ending date).
Upon cancellation of the bronze plan, the end date of the contract will be
updated and polling will stop eventually.
All of this contract metadata is returned to the wallet so the user can make an
informed decision.
Thanks for your feedbacks!
S.
On Feb 11, 2014, at 10:37 PM, Kevin Greene <kgree...@gmail.com> wrote:
> 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 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". Because of that, 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?
------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience. Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
