Skip to main content
Toast production activation remains fail-closed until the exact restaurant, scopes, dining options, alternate payment type, POS/KDS behavior, webhooks, refunds, and native tender evidence pass provider-backed certification.
Stripe is the only online payment rail. Toast receives fulfillment orders and supplies native in-person tender and refund evidence; it never processes a storefront browser payment.

​
Activation flow

1

Add Crave in Toast Web

Open Toast Partner Integrations and add Crave. Business Manager shows the exact organization Group ID and location Location ID to enter. Crave does not ask a merchant to paste Toast secrets into the browser.
2

Sync the restaurant connection

Return to Business Manager and sync. Crave accepts only the Toast restaurant whose external group and restaurant references exactly match the selected organization and location.
3

Map Toast order behavior

Select only Toast-returned identifiers: one alternate payment type, a pickup dining option, and an optional delivery dining option. Crave stores an immutable configuration revision; it never guesses GUIDs.
4

Stage the provider catalog

Retrieve the current Toast menus, categories, products, and modifiers into an immutable provider snapshot for canonical mapping review. Staging never publishes automatically.
5

Activate order routing, then certify pay at store

Activate the reviewed POS-routed policy first; this does not expose pay at store. Then prove the open check appears on the intended POS/KDS, staff can collect supported tenders, signed webhooks arrive, provider readback reconciles exact payment/refund evidence, and the certified timing schedule holds. Certify only the same active policy revision.

​
Pay at store flow

  1. Crave persists one unpaid canonical order and creates one deterministic open Toast check using the configured dining option and no payment. The alternate payment type is used only to represent an already-collected Stripe payment on online orders.
  2. Staff collect the actual card, cash, gift-card, or split tender in Toast POS. Crave does not route or charge money through a Toast browser flow.
  3. Toast webhooks trigger hydration of the current order and payments. Crave accepts native tender evidence only when tenant, restaurant, order, amount, currency, and provider identities match.
  4. The canonical settlement becomes PAID only after exact verified evidence; fulfillment may progress while payment remains DUE.
  5. Refunds follow the original Toast tender authority. Canceling or voiding the fulfillment order alone never proves a refund.
While evidence is unresolved, show Verifying payment — do not charge again and keep the same collection identity. Business Manager exposes the certified canonical-refresh, fallback-read, warning, and action-required thresholds.

​
Safety and commercial boundaries

  • Browser checkout always uses Stripe. Toast credentials, webhook secrets, tender identifiers, and provider payloads stay on Crave-managed services.
  • Crave subscription is the launch revenue base. Pay at store does not create a Crave transaction split from the Toast tender.
  • Prepared-but-uncollected and no-show loss remains merchant risk under the configured identity and order-exposure limits.
  • Production stays disabled until real partner credentials, scopes, device behavior, webhooks, payment evidence, and refund evidence are certified for the exact restaurant.
Contact hello@craveup.com for sandbox pilot and provider-certification access.