Author: Mike Hearn 2014-02-25 16:29:44
Published on: 2014-02-25T16:29:44+00:00
The protocol discussed includes an enum for PaymentFrequencyType with four options, as well as two messages: RecurringPaymentDetails and RecurringPaymentContract. The former includes a string for the merchant ID, bytes for subscription ID, and repeated contracts. The latter includes bytes for contract ID, string for polling URL, uint64 for starting timestamp, optional uint64 for ending timestamp, optional PaymentFrequencyType, optional uint64 for maximum payment per period, and optional uint64 for maximum payment amount. The writer suggests making RecurringPaymentDetails optional instead of required to avoid backwards compatibility issues, and also questions why there are only four options for recurrences. They also suggest being more explicit about units of measurement for amounts and timestamps, and ask for clarification on the purpose of repeating max_payment_amount. Additionally, they question when payments would occur based on the given contract, and suggest moving comments above field definitions. Finally, the writer suggests involving BitPay, Jeff, and Stephen to gain a better understanding of customer requirements, and notes that bitcoinj implementation may need restructuring to allow for recurring payments.
Updated on: 2023-06-08T01:57:56.340815+00:00