# Test your Embedded API integration > Verify the quickstart, failure recovery, and the experience your app or store controls. Source: https://help.boltapp.com/products/embedded-api-test-plan Run these cases against the [Embedded API quickstart](/products/embeddable-checkout). Copy the tables into your test report and attach redacted evidence. Every case starts **Not run**. ## Scope and setup [#scope-and-setup] | Scope | What is covered | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Quickstart | Hosted fields, one payment attempt per claimed order, server transaction lookup, and status display. | | Merchant integration | Session/CSRF enforcement, immutable pricing, atomic claim, reference persistence, monotonic payment updates. | | Additional launch work | Webhooks/background reconciliation, safe retry policy, full recovery/confirmation, fulfillment, receipts, and optional shopper login/saved cards. | | Inputs | One saved $10.00 USD digital-item order, no tax/discounts; shopper A and unrelated shopper B; billing ZIP 94105. Use the guide’s Bolt Payments sandbox division. | | Evidence | Record build/date, tester, sandbox division, device/browser, case result, order/transaction/seller or link IDs as applicable, and redacted logs/screenshots. Never attach tokens, credentials, or personal banking data. | Use real sandbox execution for Q cases. Label controlled response substitutions, outages, and replay tests separately; mocks do not establish live payment acceptance. Use a fresh order for each payment test and reset store/fixture changes afterward. Do not retry an uncertain payment until it is reconciled. ## 1. Quickstart checkpoints [#1-quickstart-checkpoints] | Test | Input | Steps | Expected output | Result | | ------------------- | ------------------------------- | -------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- | ------- | | Q1 · Set up | Enabled v1 sandbox division | 1. Confirm Bolt Payments and credentials. 2. Reopen Trusted Domains. | All settings belong to the same enabled division; private key stays server-side. | Not run | | Q2 · Connect orders | Shopper A/B; saved order | 1. GET the order as A. 2. Repeat as B. 3. Exercise two concurrent claim calls. | A gets unconfirmed; B gets 404; exactly one claim succeeds and survives restart. | Not run | | Q3 · Add fields | Existing checkout page | 1. Open payment section. 2. Inspect loaded scripts/frames. | Hosted fields mount; Pay enables; only the publishable key is exposed; no raw card fields in merchant DOM. | Not run | | Q4 · Take payment | 4111 1111 1111 1111; 03/30; 737 | 1. Enter card and ZIP 94105. 2. Select Pay once. | POST returns 202; one transaction reference is saved; no claim of completion while capture is pending. | Not run | | Q5 · Verify order | Saved reference | 1. Check status until completed. 2. Refresh/restart app. 3. Compare Bolt Transactions. | Same order/reference, $10.00 USD, and completed payment in app storage and Bolt. | Not run | ## 2. Functional integrity [#2-functional-integrity] | Test | Input | Steps | Expected output | Result | | ------------------------- | ---------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------- | ------- | | F1 · Incomplete card | Missing card fields | 1. Submit incomplete fields. 2. Correct them. | Readable correction; no authorization request before tokenization succeeds; submission can then continue. | Not run | | F2 · Duplicate submission | Same order; two simultaneous requests | 1. Submit from two tabs. 2. Refresh checkout and submit again. | At most one authorization attempt; later claims return 409. Merchant adapter enforces this atomically. | Not run | | F3 · Price tampering | Browser payload with changed amount | 1. Add amount/currency fields to the pay request. 2. Inspect outbound request. | Server uses the saved snapshot; browser-supplied prices have no effect. | Not run | | F4 · Transaction mismatch | Controlled Bolt response: other order, amount, currency, reference, or refund type | 1. Substitute each response at transaction lookup. 2. Request status. | No completed state saved; safe error. A credit/refund never becomes a new purchase. | Not run | | F5 · Uncertain submission | Drop authorization response after Bolt accepts it | 1. Submit. 2. Reload and attempt again. 3. Reconcile via dashboard. | Claim remains reserved; no second charge; app directs shopper to status/support. Recovery requires merchant implementation. | Not run | | F6 · Capture pending | Controlled authorized/pending response | 1. Check status. 2. Change response to completed and check again. | Pending is not shown as paid; only verified completion updates the order. | Not run | | F7 · Access and CSRF | Other shopper; missing/invalid CSRF token | 1. Try GET as B. 2. POST without valid session/CSRF. | Access rejected before a Bolt request; no order data disclosed. | Not run | ## 3. Merchant-owned experience [#3-merchant-owned-experience] | Test | Input | Steps | Expected output | Result | | ------------------------- | ----------------------------------------- | --------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | ------- | | E1 · Clear purchase | Checkout total and digital product | 1. Review checkout before paying. | Product, $10.00 USD, billing details, and Pay action are clear; hosted fields fit the merchant layout. | Not run | | E2 · Load/recovery | Block embed.js; reload | 1. Block script. 2. Restore it and reload. | Pay stays disabled on load failure; helpful message; successful reload mounts one component. | Not run | | E3 · Navigation | Slow script/tokenization; unmount | 1. Navigate away during setup and tokenization. 2. Return. | No late payment submission after leaving; no duplicate controls/listeners; hosted fields clean up. | Not run | | E4 · Accessibility/mobile | Keyboard, screen reader, 390px, 200% zoom | 1. Tab through merchant controls. 2. Trigger errors/status. 3. Rotate/zoom. | Visible focus, named controls, useful announcements, no inaccessible actions. Record Bolt-owned frame issues separately. | Not run | | E5 · Unavailable status | Fail GET after submission | 1. Check payment status. 2. Follow the recovery message. | No false success or raw exception; shopper can recover the existing order without another payment. | Not run | ## 4. Additional launch requirements [#4-additional-launch-requirements] | Test | Input | Steps | Expected output | Result | | ----------------------- | ------------------------------------------- | ------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------- | ------- | | L1 · Background updates | Shopper closes page after payment | 1. Complete payment then close browser. 2. Process authenticated notification or reconciliation. | Order eventually updates without an open page; duplicate notifications do not duplicate fulfillment. | Not run | | L2 · Lifecycle | Decline/review; refund; receipt/fulfillment | 1. Run configured failure and post-purchase flows. 2. Reconcile records. | Correct risk/payment states and exactly-once business effects; refunds separate from sales. | Not run | | L3 · Expanded checkout | Real totals; saved cards/login if offered | 1. Exercise each offered flow. 2. Confirm consent and pricing. | Enabled features pass their own cases; guest baseline does not claim account creation or saved cards. | Not run | ## Completion gates [#completion-gates] | Gate | Required evidence | | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Quickstart verified | All Q cases pass in the real sandbox, including merchant-owned integration work. | | Ready for launch review | All Q, F, E and applicable L cases pass; no required Blocked or Not run cases. Record exclusions with a reason and obtain technical/experience-owner review. | | Failed or blocked case | Record actual output, issue/owner, and retest evidence. A successful payment does not excuse a broken shopper or seller experience. | Use **Pass**, **Fail**, **Blocked**, **Not run**, or **Not applicable** with a reason. A build or mocked test result does not verify production processing, delivery, or settlement.