# Production guide — Sell personalised products and recover the right artwork

Manuscript: [Build a personalised-product catalogue](../appmint-sell-custom-products-online.md). Rechecked24 September2026. Use actual product screens and customer/operator actions. An unpaid order and actual order-artwork retrieval are verified. The payment section is not ready to film as a successful paid sale.

## Story and visual sequence

Open with the practical problem: two people buy the same sign, but their names, sizes and artwork differ. The audience should learn how those differences stay attached to the correct line from product selection into the operator's cart view.

| Scene | Show | Explain / verify |
| --- | --- | --- |
| 1. Give the product a clear offer | Product editor, saved gallery, description andSKU SIGN-WELCOME-01 | Base price 45, 45cm adds12; gallery imagery describes the offer while uploaded artwork describes one customer's design. |
| 2. Ask for the information fulfilment needs | Attribute definitions and product attachment | Required name and size; optional single PNG/SVG artwork. Zoom to the required switches and0/12 option prices. |
| 3. Make the shop reachable | Saved store page, Storefront attachment and live catalogue | Follow the actual saved page into the product. Use current local screenshots; earlier failure frames are repair history. |
| 4. Buy as two different designs | Product form, sign-in link, email-link completion, upload | Omit required name once, show rejection, then enter the full first design. Keep credentials and email-link tokens out of footage. |
| 5. Check the money and the details | Two cart lines | Read both names/sizes/files. Highlight45 +114 =159 merchandise,8 delivery,167 total. Change Maya's quantity2→1→2 and show110→167. |
| 6. Recover after a browser interruption | Empty cart → sign in → Restore saved cart | Same customer account; both original lines return. Explain that restoration does not place an order. |
| 7. Work as the operator | Studio → Storefront → Cart → customer row → each artwork link | Match each file to its own name, size and quantity. Open the actual SVG tabs. A filename alone is not retrieval proof. |
| 8. Retrieve from the placed order | Order RPSDCGHC4 → Items (2) → both artwork links; Payments tab | Both original designs survive server-cart clearing. Show Paid$0, Balance$167, Unpaid. This order was submitted through the authenticated API; do not portray it as a completed gateway checkout. |
| 9. Complete the paid sale | Pending capture | Needs configured sandbox, actual payment-screen checkout, provider transaction, shipment and refund/return reconciliation. Do not simulate successful payment. |

## Current usable stills

Paths below are under `../../application-fixes/assets/` relative to this guide.

| Asset | What it establishes |
| --- | --- |
| `store-personalisation-readback.png` | Saved product options and required/optional settings. |
| `store-required-name-fixed.png` | Required-name rejection and57 price for the larger size. |
| `store-two-cart-lines-fixed.png` | Original two customer designs and correct totals. |
| `store-cart-restored.png` | Restored names, sizes, files, quantities and167total. |
| `store-owner-artwork-fixed.png` | Operator view of the original two lines and artwork controls. |
| `account-layout-checkout-fixed.png` | Payment configuration is missing; this is not a completed sale. |
| `store-unpaid-customer-order.png` | Actual New order, both personalised lines and159+8=167 total. |
| `store-unpaid-operator-artwork.png` | Actual placed-order Items tab; each link was opened and checked. |
| `store-fresh-artwork-operator.png` | Additional verification only: temporary third line used to test a fresh upload. Do not present it as one of the two tutorial purchases. |

`store-owner-artwork-proof.json`, `store-fresh-artwork-proof.json` and `store-cart-continuity.json` contain sanitized verification results, not video footage. Screen-record the actions in the script when preparing the companion video; no finished recording is claimed here.

## Recording controls and pitfalls

Use the manuscript's two named designs consistently. Hide sign-in URLs, passwords, API keys and signed artwork URLs. Keep a visible pause while uploads and pricing finish. Capture the final totals after the request resolves. Show a complete action and its readback instead of unrelated project clips.

The two original cart lines were converted once into unpaid order RPSDCGHC4, and the selected server cart was cleared. The temporary fresh-upload line had already been removed. No paid order exists; do not resubmit the original cart for a recording. Login and checkout now render without the unrelated portal preview. Use `account-layout-login-fixed.png` and `account-layout-checkout-fixed.png`; their mobile counterparts are also available. The old preview captures are repair history, not the current customer flow.

Before filming scene9, verify the paid order number, attachments, payment state and provider transaction independently. Return/refund status must not stand in for money returned or stock restored. Those screenshots and claims remain unavailable until the corresponding live actions pass.

## Return-inspection insert

Use `store-return-independent-decisions.png` only as the explicitly labelled synthetic inspection exercise. It demonstrates why two personalisations with one SKU need separate decisions: reject the$45 line, accept the$57 line. The fixture did not originate from a paid sale or shipment. Never intercut it as proof that order RPSDCGHC4 was delivered or refunded. Screen-record **Return → Returns → row Actions → Start Inspection**, the independent controls and the saved accepted-value readback when producing this insert.

## Current Stripe sandbox checkout — 24 September

The fresh single-sign payment rehearsal is separate from the earlier two-design artwork/order exercise. Use [the actual Stripe test form](../../application-fixes/assets/stripe-sandbox/02-checkout-test-card.png) and [paid confirmation](../../application-fixes/assets/stripe-sandbox/03-order-confirmed-paid.png). Narrate $45 merchandise plus $8 shipping, total $53, and retain the order number AZ1QTIMKN. The matching provider intent is succeeded with `livemode: false`; no real money moved. Do not imply the earlier unpaid RPSDCGHC4 was paid, that the new single-sign cart contained both original artworks, or that confirmation establishes shipment/refund. Those operator checks are tracked separately.

## Verified fulfillment, refund and return continuation

Use the actual [manual form](../../application-fixes/assets/stripe-sandbox/05-manual-tracking-form.png), [saved Shipping summary](../../application-fixes/assets/stripe-sandbox/12-manual-shipping-fixed.png), [refunded Payments summary](../../application-fixes/assets/stripe-sandbox/11-refund-summary-fixed.png), [RMA approval](../../application-fixes/assets/stripe-sandbox/09-rma-approve.png), [completion form](../../application-fixes/assets/stripe-sandbox/14-rma-complete-form.png) and [completed RMA](../../application-fixes/assets/stripe-sandbox/15-rma-completed.png).

Narrate the actual sequence: paid sandbox order → fictional manual tracking → one 53.00 provider refund → customer API return request → approve/receive/inspect → record45.00 merchandise against that existing refund. Explain the remaining8.00 as order shipping. Do not imply a real parcel, purchased label, restock or second refund. The original167.00 unpaid artwork order is a separate earlier fixture.

The RMA starts through a documented customer API call, not an unobserved storefront button. Show the saved request number, then the actual Studio controls. The current Payments labels are Gross collected, Uncollected balance, Refunded and Net retained; older captures used Paid and Balance. Use the latest summary for teaching those labels. Preserve the original payment row as history. Do not repeat payments, tracking or refunds for filming; reopen the saved records.