Agree what is being delivered
This workflow helps merchants and frontend developers review a self-hosted component, not operate a prize service. Record the campaign owner, dates, eligibility wording, redemption conditions and result source. Choose a wheel, scratch card or mystery boxes for presentation; the animation is not evidence of allocation. Local mode must remain visibly labeled as a demo. API mode requires a merchant system that owns authentication, odds, stock and redemption.
Export one revision and retain its original files. Host index.html, widget.css and widget.js together, or deliberately choose the single-file HTML export. The editable config.json snapshot is not a secret store. Offers in exported code can be read by visitors. Optional image URLs cause requests from visitors' browsers to those hosts. Use synthetic examples in supporting review tools and do not upload private keys, customer records or real claim codes.
Reconcile configuration and the response contract
Use a JSON Schema derived from the current export documentation, not an invented generic prize format. Check version, campaignId, mode, endpoint and configured prize IDs. Verify unique IDs and an exact 100% local probability total separately; a basic schema result does not establish every cross-field invariant. Equal-size sectors are visual only and do not express actual local odds. Compare baseline and proposed JSON, explaining changes to rules, labels, probabilities and result source. Regenerate component files after an approved configuration change rather than mixing revisions.
The export posts version, campaignId and requestId. Merchant JSON must echo the requestId and name a configured prizeId; optional receipt and claim fields follow the exported contract. Validate sanitized success and no-prize fixtures and keep malformed examples for negative tests. Passing a schema does not execute the endpoint or prove eligibility and inventory enforcement. The editor preview never calls your endpoint.
Make rules and outcomes readable
Check the actual ink/background and button text/background pairs, including result messages. A passing color pair is not a complete accessibility audit. Inspect exported HTML with the accessibility checker for common labels, landmarks and related issues, then confirm findings in a browser. Test keyboard entry, focus visibility, result announcements and whether interaction remains usable without animation. Static analysis does not certify a scratch interaction or an iframe.
Long translations, larger text, prize images and claim links can change the result layout. Review all states rather than approving the empty starting view. Keep campaign rules available outside any animation-only explanation. Record unresolved interaction defects instead of treating a themed preview as acceptance.
Test the actual hosted and embedded page
Upload the chosen files to an authorized HTTPS staging host. Responsive comparison can reveal clipping at selected widths; screenshots record a view, not a successful draw. They may not inspect cross-origin frame contents or reach authenticated states. Record viewport, URL and revision, then open the real shop embed yourself and test scrolling, frame height, keyboard access and external claim links.
The runtime uses same-origin credentials. A relative endpoint resolves against the widget origin, not the surrounding shop origin. A separate HTTPS endpoint needs CORS, but CORS does not make cross-origin cookies get sent. Third-party cookie blocking can also break iframe authentication. Use a dedicated widget origin you control and review the exported sandbox permissions; they permit merchant integration and are not a promise of isolation from trusted merchant code.
Manually exercise success, configured no-prize results, non-success HTTP status, malformed JSON, unknown prize IDs, mismatched request IDs and a delayed response exceeding the documented 15-second timeout. Failure must not award a local fallback prize. Manual retry reuses an unresolved request ID on this page only; reloads are not protected by that mechanism. The backend must persist idempotent outcomes transactionally and handle a response lost after allocation. Use test outcomes, not real prizes, for these checks.
Hand off an identifiable revision
Hash final files only after the last approved change. Include the configuration diff, deployment origin, endpoint contract, sanitized browser evidence, unresolved checks and responsible owners. SHA-256 identifies bytes; it does not prove fair odds or safe server behavior. Real inventory, eligibility, redemption and campaign authorization remain separate launch gates.
Use campaign-link preflight when the task becomes tracking or QR delivery, responsive change review for before/after page evidence, and Stripe batch preflight for candidate discount import files. None of those replaces the widget's merchant integration acceptance.