path: root/design-documents
diff options
authorFlorian Dold <>2020-08-09 00:33:24 +0530
committerFlorian Dold <>2020-08-09 00:33:24 +0530
commit069bf92a566cc83054f553be68a3f3fdc9f2a430 (patch)
treef7b839ccb14f072917c97dc59757731ca595ec51 /design-documents
parenta61621982aa6d77dbeff5fe98b22c7ab2e37bed4 (diff)
more problems
Diffstat (limited to 'design-documents')
1 files changed, 8 insertions, 2 deletions
diff --git a/design-documents/007-payment.rst b/design-documents/007-payment.rst
index 4a0998b..c797cd5 100644
--- a/design-documents/007-payment.rst
+++ b/design-documents/007-payment.rst
@@ -50,6 +50,10 @@ When *resource-URL* is requested, the storefront runs the following steps:
and return to the client the content for *resource name*. **Terminate.**
9. Otherwise, the *order-status* is unpaid. Redirect the client to *client-order-status-URL*. **Terminate.**
+.. note::
+ When a refund is given, the corresponding tuple must be removed from the *session-page-cache*.
Backend Private Order Status
@@ -140,8 +144,8 @@ Covered Scenarios
Problematic Scenarios
-Bookmarks of Lost Purchases
+Bookmarks of Lost Purchases / Social Sharing of Fulfillment URLs
Let's say I bought some article a few months ago and I lost my wallet. I still have the augmented fulfillment URL
for the article bookmarked. When I re-visit the URL, I will be prompted via QR code, but I can *never* prove
@@ -153,6 +157,8 @@ It's not clear if this is a common/important scenario though.
But we might want to make clear on the client order status page that it's showing a QR code for something
that was already paid.
+The same concern applies when sending the fulfillment URL of a paid paywalled Web resource to somebody else.
The Back Button