Clover POS remains in development preview. An authorization connection is not
proof that catalog, order routing, Ecommerce payment, or refunds are ready for
production.
Current connection flow
1
Authorize Clover
An organization administrator completes Clover OAuth v2. Crave stores access
and refresh credentials encrypted on the server and never returns them to
Business Manager.
2
Confirm the merchant
The authorized Clover merchant must be explicitly mapped to one Crave
location. Connecting does not automatically select Clover as the active
payment processor.
3
Stage the provider catalog
A manual provider sync retrieves minimized items, categories, modifiers,
taxes, discounts, service charges, order types, stock, and opening hours.
Crave stores immutable provider snapshots, maps them to canonical catalog
identities, and reports conflicts or missing evidence without publishing a
menu.
4
Review and activate Menu Sync
An administrator may atomically publish a valid, current staged catalog.
Order routing, provider checkout, refunds, stored cards, and gift cards
remain separate capability gates. Existing carts and orders retain the
authority captured when they were created.
Safety boundaries
- Crave never silently moves a Clover-owned checkout or refund to Stripe during an outage.
- Browser card data must be tokenized by Clover; raw card numbers and security codes must not reach Crave servers.
- Tips, stored cards, native gift cards, split tender, discounts, and partial returns require their own sandbox and entitlement evidence.
- Verified Clover webhooks are durable reconciliation signals. Financial state is re-read from Clover before Crave treats it as authoritative.