Author: Mike Hearn 2014-02-26 10:30:46
Published on: 2014-02-26T10:30:46+00:00
In this email thread, Stephane Brossier explains the recurring payment protocol and its two aspects: contract negotiation and recurring payments. The contract defines the payment bounds associated with a subscription, and the wallet is in charge of issuing payments within these bounds as requested by the merchant. The protocol introduces a max amount per payment and a max amount per period to account for unknown costs like taxes and shipping. The type of contract used depends on the merchant's decision to specify none, any, or both bounds. The payment frequency type only defines the max amount per period in the contract; the wallet has to poll the merchant to understand if there are any pending payments. Mike, Jeremy, and Drak have some questions and comments about the protocol design. They suggest making the RecurringPaymentDetails field optional, being more flexible in specifying periods, explicitly stating that amounts are in satoshis and timestamps are UNIX time, and documenting the implicit value constraint for max_payment_amount. They also ask about the "merchant ID" namespace and the "subscription ID," which is used to identify contracts associated with a subscription. Stephane clarifies that having >1 contract per payment request can happen when a customer decides to downgrade their subscription later. He explains that the protocol is designed so that the wallet does not have to know what the exact date of payment is but instead polls the merchant for pending payments. This flexibility is essential because specifying an exact payment date is not always an option. Lastly, Stephane agrees to talk to BitPay and get Jeff and Stephen involved to receive feedback on the protocol design.
Updated on: 2023-06-08T01:50:08.047184+00:00