What the line item carries
When a shopper finishes in the customizer and the item enters the cart, the storefront writes two properties on that cart line. They stay on the line through checkout and onto the order._sudomock_render_uuid is the render the shopper approved. It is the handle
for that one design.
_sudomock_action_receipt_id is the id of the confirmation your store made
before the line was added.
Nothing else is written there. No preview URL, no artwork URL, no mockup id and
no credential. A cart property is written by the browser, so anything sitting
in one is a claim rather than a fact, and the two ids are exactly the two
values that can be checked against something we hold.
Why a receipt id sits beside the render id
Before the item reaches the cart, your store asks us to confirm the design. The confirmation is bound to the mockup, the render, the shop, the product and the variant, and only then is the line added. Confirming the same design twice returns the original receipt instead of a second one, so a retry after a timeout cannot turn into two pieces of work. The receipt id on the line is the id of that confirmation, which is what ties an order line back to the moment the design was accepted.Where the mockup id lives instead
The mapping between a product and a template is kept on the product, in thesudomock metafield namespace.
mockup_uuid is the template the product customizes. mockup_type is psd or
2d, which decides the editor a shopper meets. customization_enabled is
true while the product is live for customizing.
The app writes all three when you map a product and removes them when you
unmap it. Opening the editor needs a mapping to exist and
customization_enabled to read true, and the design confirmation is refused
when the product’s mockup_uuid no longer matches the one the browser asked
for, so remapping a product cannot be used against an editor that is already
open.