clean up merchant payment tx spec

1 files changed, 14 insertions, 16 deletions

diff --git a/design-documents/037-wallet-transactions-lifecycle.rst b/design-documents/037-wallet-transactions-lifecycle.rst
index e9380862..35a9fab2 100644
--- a/design-documents/037-wallet-transactions-lifecycle.rst
+++ b/design-documents/037-wallet-transactions-lifecycle.rst
@@ -55,6 +55,9 @@ include more information information relevant to the transaction in `abortReason
 ``suspended``: Similar to a ``aborted`` transaction, but the transaction was could be
 resumed and may then still succeed.
 
+``suspended-aborting``:  Network requests or other expensive work
+to abort a transaction is paused.
+
 ``failed``: Similar to ``done``, but the transaction could not be completed or
 possibly not even be aborted properly.  The user may have lost money.  In some
 cases, a report to the auditor would make sense in this state.
@@ -327,18 +330,18 @@ Transaction Type: Payment to Merchant
   We received a ``pay`` URI. Download (claim) the proposal from the merchant.  Can fail if
   the proposal was already claimed by someone else.  If repurchase detection
   tells us that we already paid for this product, we go immediately to
-  ``delete`` state for this transaction, but with a side-effect of
+  ``failed(repurchase)`` state for this transaction, but with a side-effect of
   transitioning the UI into a ``pending(repurchase-session-reset)`` on a
   *different* transaction (which before was in ``done``).
 
-  * ``[error: already claimed] => deleted``  -- the proposal was
-    already claimed by someone else; we go directly into the ``deleted``
-    state and only show a transient warning.
-  * ``[error: invalid proposal] => deleted`` -- the merchant provided a
-    proposal that is invalid (e.g. malformed contract
-    terms or bad signature); we go directly into the ``deleted`` state
-    and only show a transient warning.
+  A ``failed(repurchase)`` transaction will eventually be GCed (=deleted)
+  automatically.
 
+  * ``[error:already-claimed] => failed(already-claimed)`` -- the proposal was
+    already claimed by someone else.
+  * ``[error:invalid-proposal] => failed(invalid-proposal)`` -- the merchant provided a
+    proposal that is invalid (e.g. malformed contract
+    terms or bad signature).
 
 * ``pending(proposed)``
 
@@ -347,19 +350,14 @@ Transaction Type: Payment to Merchant
   * ``[action:pay-accept] => pending(submit-payment)``
   * ``[action:pay-refuse] => ``aborting(unclaim)`` -- The user explicitly
     decided not to proceed (at least not with this wallet).
-  * ``[expired] => deleted`` -- The offer has expired before the user made any
-    decision. (We can keep pending contracts even in a 'pending transaction'
-    list to allow the user to choose to not proceed, but then this transition
-    would clean up that list). Note that we should use this transition at
+  * ``[expired] => failed(expired)`` -- The offer has expired before the user made any
+    decision. Note that we should use this transition at
     least a few seconds before the offer *actually* expires to avoid
     encountering an expiration during ``pending(submit-payment)`` in most
     real-world scenarios. Basically, we should prevent last-second payments to
     be event attempted client-side.
 
-* ``aborting(unclaim)``
-
-  Tells the merchant that some *other* wallet is now again free to claim this
-  offer.
+    The ``failed(expired)`` might be automatically deleted upon GC.
 
 * ``pending(submit-payment)``