diff options
Diffstat (limited to 'design-documents/031-invoicing.rst')
| -rw-r--r-- | design-documents/031-invoicing.rst | 19 |
1 files changed, 6 insertions, 13 deletions
diff --git a/design-documents/031-invoicing.rst b/design-documents/031-invoicing.rst index 419c299d..0fcc88fd 100644 --- a/design-documents/031-invoicing.rst +++ b/design-documents/031-invoicing.rst @@ -1,12 +1,10 @@ -DD31: Invoicing -############### +DD 31: Invoicing +################ Summary ======= -This document proposes new endpoints to support invoicing, -that incidentally also address the long-standing tipping -reserve expiration problem. +This document proposes new endpoints to support invoicing. Motivation @@ -36,10 +34,7 @@ Requirements * Reasonable UX and overall design impact. * Wallets may want to pay for the reserve with coins - (reserve fresh, not created via bank transfer), while - tipping merchants likely want to pay from the reserve - balance itself. So both styles of payment should be - supported. + (reserve fresh, not created via bank transfer). Unclear in the current proposal are: @@ -62,12 +57,10 @@ charge the ``account_fee``, bump the number of open purses threshold in the ``reserves`` table and stop auto-closing of the reserve. This will ensure that the users can withdraw the reserve balance into their wallet even after a longer time period. This helps if the invoice is paid after a significant -delay, and also addresses the unwanted tipping reserve closure -problem. Introduce a way to force an immediate closure of a reserve, allowing +delay. Introduce a way to force an immediate closure of a reserve, allowing P2P reserve from invoices to be send to a bank account (this allows a wallet to be used for convenient invoicing and not strictly require the wallet to -receive the funds) and also allowing the user to recover funds from a tipping -reserve after tips are no longer issued. +receive the funds). The solution needs three new tables for: |