Test your Embedded API integration
Verify the quickstart, failure recovery, and the experience your app or store controls.
Run these cases against the Embedded API quickstart. Copy the tables into your test report and attach redacted evidence. Every case starts Not run.
| 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.
| 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 |
| 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 |
| 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 |
| 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 |
| 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.
