commit 75b441a3e048d73c4868e91d3c6713287eb80f4e
parent 98080756b2419ff5b75202a1257227739207576b
Author: bohdan-potuzhnyi <bohdan.potuzhnyi@gmail.com>
Date: Sat, 8 Nov 2025 17:47:17 +0100
update 073
Diffstat:
1 file changed, 9 insertions(+), 19 deletions(-)
diff --git a/design-documents/073-extended-merchant-template.rst b/design-documents/073-extended-merchant-template.rst
@@ -73,14 +73,12 @@ Proposed Solution
Schema extensions
-----------------
-Add a derivative of the existing public ``/instances/$ID`` endpoints that lets
+Add an endpoint that lets
wallets download product images via ``GET
/instances/$ID/products/$IMAGE_HASH/image``.
-//TODO: describe in more colors
-
-Introduce an explicit template type discriminator so existing contracts remain
-stable and new behaviour can be negotiated per template version.
+Introduce template type discriminator so processing
+of the template can be done per template version.
.. ts:def:: TemplateType
@@ -171,15 +169,10 @@ New contract type has next structure:
Wallets that do not recognise ``"inventory-cart"`` continue to expect
template-level fields such as ``minimum_age``, and when new type supplied
-it will inevitably crash, KABOOM!
+it will inevitably, KABOOM!
-The merchant backend merges ``selected_categories`` and ``selected_products``
-into a concrete product list at template creation time.
-(WHICH IS VERY BAD BECAUSE IF
-MERCHANT CHANGES THE CATEGORY, KABOOM, maybe it has to stay in 2 arrays until we
-pre-calc the GET to wallet)
-Duplicates are removed, and products outside the merchant's inventory produce a
-404 not found.
+The merchant simply saves id's of ``selected_categories``
+and ``selected_products``.
``choose_one`` dictates whether the wallet must restrict the user
to a single product/quantity combination (``true``) or allow arbitrary
@@ -207,11 +200,8 @@ Wallet discovery API
--------------------
Enhance the public ``GET /instances/$INSTANCE/templates/$TEMPLATE_ID`` response
-to include both the inventory configuration and the resolved product metadata.
-
-``template_contract`` now reuses a dedicated wallet-facing sum type so the
-payload can unambiguously switch between classic contract terms and the
-inventory capsule.
+to include both the inventory configuration and the resolved product metadata,
+by using ``TemplateWalletContractPayload``.
.. ts:def:: TemplateWalletContractPayload
@@ -388,7 +378,7 @@ Wallet UX
Wallets handle inventory templates as follows:
1. Fetch ``WalletTemplateDetails`` and cache the resolved inventory.
-2. Render a cart builder respecting ``choose_one`` and field defaults.
+2. Render a cart builder respecting ``choose_one``.
3. Show a running total computed from per-product prices; totals must match the
backend response before displaying the payment acceptance dialog.
4. Gracefully handle outdated caches by retrying the ``GET`` when the ``POST``
