Skip to main content
Managed Cloud installations use their own pinned runtime contract. Managed Cloud installations can run a different, pinned checkout contract; an npm tag alone does not establish compatibility. Confirm the SDK/API pair for your installation before using payment-session or customer-auth methods. The hosted storefront and checkout use their bundled client. See release compatibility.
Select Sandbox in your Console project and copy that installation’s API origin. Launch keeps Sandbox available for testing; you do not need a second hosting subscription. Its menu, orders and customers remain separate from Production. Use test payment configuration for local and CI runs:

​
Unit tests

Test the caller-owned session adapter independently:
  • versioned sessionStorage keys include the canonical API environment, merchant, and location;
  • the cart capability and customer JWT never enter URLs, analytics, or localStorage;
  • ETag revisions are retained;
  • claim, delete, expiry, and terminal checkout handling clear persisted capability state;
  • malformed or old-version records fail closed.
Mock fetch when testing the SDK:
Assert cart calls send the capability, current If-Match, and an idempotency key. For CART_CONFLICT, assert the mutation is not replayed automatically and the current cart revision is refreshed.

​
Checkout tests

Cover every authoritative result:
  • PROCESSING continues bounded polling;
  • CUSTOMER_ACTION_REQUIRED renders only the returned Stripe action;
  • PAID renders the stable order identity and clears persisted cart state after terminal handling;
  • ACCEPTED renders the audited pay-at-store order without claiming online settlement;
  • ACTION_REQUIRED renders the exact recovery action and never falls back to success;
  • authorization, timeout, and stale-revision errors remain visible.

​
Receipt tests

Start with a URL containing #receiptToken=.... Assert the app calls history.replaceState immediately, stores the token only for that API environment, merchant, and receipt ID in sessionStorage, and sends it in the receipt header—not in the request URL.

​
End-to-end sandbox flow

  1. Fetch published merchant, location, menu, product, distance, order-time, and gratuity data anonymously and verify no customer JWT is attached.
  2. Create a cart and verify the capability is returned only once for a new cart.
  3. Mutate the cart and verify revision changes.
  4. Submit the canonical order and handle its Stripe customer action or activation-lock error.
  5. Observe nonterminal polling followed by exactly one terminal result.
  6. Verify rating and receipt access.
  7. Confirm no secret or capability appears in browser URLs, logs, analytics, or static assets.
Run the same build artifact you intend to promote.

​
Outbound webhook tests

Create an endpoint in the sandbox Business Manager and use Send test. Test events have "test": true in the exact body and Crave-Webhook-Test: true; they are never real orders. Your receiver test suite should prove that it:
  • verifies the timestamped Crave-Webhook-Signature against raw bytes before parsing JSON;
  • rejects tampered bodies and timestamps outside the 300-second replay window;
  • accepts either valid signature during bounded secret rotation;
  • commits each Crave-Webhook-Id only once and returns 2xx for duplicates;
  • returns quickly, then processes asynchronously;
  • looks up current Crave state after an ambiguous timeout instead of blindly resubmitting;
  • keeps secrets, signatures, customer data, and full response bodies out of logs.
Use Business Manager’s delivery timeline to inspect attempts. A manual redelivery must retain the same event ID and exact body; it tests idempotency, not a new business transition.