From 069bf92a566cc83054f553be68a3f3fdc9f2a430 Mon Sep 17 00:00:00 2001 From: Florian Dold Date: Sun, 9 Aug 2020 00:33:24 +0530 Subject: more problems --- design-documents/007-payment.rst | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) (limited to 'design-documents') diff --git a/design-documents/007-payment.rst b/design-documents/007-payment.rst index 4a0998b0..c797cd56 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 ^^^^^^^^^^^^^^^ -- cgit v1.2.3