> ## Documentation Index
> Fetch the complete documentation index at: /docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Toast POS

> Connect Toast for catalog staging, fulfillment, and certified POS-native pay at store.

> [!NOTE]
>
> 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](mailto:hello@craveup.com) for sandbox pilot and
provider-certification access.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.