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

# Clover POS

> Understand Clover connection, merchant mapping, catalog discovery, and activation gates.

> [!NOTE]
>
> Clover is available only for locations whose exact merchant, device, tender
> matrix, scopes, webhooks, and counter-verification schedule have been
> certified. An OAuth connection alone never enables pay at store.

Stripe remains the only online payment rail. Clover receives fulfillment orders
and supplies native in-person tender and refund evidence; Crave never renders a
Clover browser tokenizer, hosted checkout, or saved-card flow.

## Activation 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. Map the exact merchant**

Bind one Clover merchant to one Crave location after currency, timezone,
scope, and ownership checks. Connecting does not activate collection.

**3. Stage and publish the catalog**

Sync minimized provider resources into immutable snapshots, resolve mapping
conflicts, and explicitly publish a canonical revision. Import never
publishes automatically.

**4. Activate order routing**

Activate the reviewed POS-routed policy after catalog, generic routing,
commercial, and compliance readiness pass. This still does not expose pay at
store.

**5. Certify native collection**

On a real Clover device/Register, prove open-order visibility, card and cash
tender evidence, split tender, reversal/refund behavior, signed webhook
delivery, provider readback, and day-end reconciliation. Persist the proven
device, environment, region, active tender-matrix revision, expiry, and
timing thresholds. Any mapping, tender, device, or policy change requires
recertification and hides pay at store until it passes again.

## Pay at store flow

1. Crave persists one unpaid canonical order and submits an open Clover order
   with a deterministic external identity.
2. Clover staff collect the real in-person payment in Clover POS.
3. Signed webhooks are durable signals, but Crave hydrates the current Clover
   order and payments before accepting native tender evidence.
4. Exact card, cash, gift-card, or split-tender legs append to one settlement;
   tips remain separate. Payment becomes `PAID` only when exact collected base
   amount equals the order total.
5. Refunds are admitted once against the original tender and dispatched only by
   the Clover refund authority that captured it. Canceling a Clover order is
   not refund evidence.

While evidence is unresolved, Business Manager shows the certified
canonical-refresh, fallback-read, warning, and action-required thresholds and
**Verifying payment — do not charge again**. Reconciliation reuses the same
collection identity and never silently falls back to Stripe.

## Safety and commercial boundaries

* Browser checkout is always Stripe. Pay at store never accepts a Stripe saved
  payment method or card data in the storefront.
* Provider-recorded cash is preferred. A manual cash fallback is available only
  under an explicitly certified policy, exact amount, narrow permission,
  staff identity, reason, and immutable audit.
* Crave subscription is the launch revenue base. Pay at store does not take a
  transaction split from the Clover tender.
* Prepared-but-uncollected and no-show loss remains merchant risk under the
  configured identity, per-order, active-count, active-value, and aging limits.

## Availability

Production activation remains closed until real-device and provider-backed
certification evidence is recorded for the exact location. Contact
[hello@craveup.com](mailto:hello@craveup.com) for sandbox pilot requirements.


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