Launch on Crave Commerce
Use the platform's native checkout and payment path, powered by Stripe, when the restaurant does not need an external commerce rail.
Availability and payment capabilities vary by country and account.
Bring the systems the restaurant already runs.
Crave gives every guest application one restaurant-commerce contract. Use the Stripe-native path when you can, or preserve the restaurant's existing POS and payment rail when you must. The application code does not fork around each provider.
Choose the production path by location.
A restaurant can start without a POS integration, then add one only where its operating model requires it. No provider is implied until its capabilities and merchant approval are known.
Keep the existing POS and payments
Connect through an approved provider path when a restaurant needs orders and payments to remain on the system it already operates.
Production integrations are capability-scoped and priced by live location.
Add independent modules
Connect loyalty, analytics, voice, or guest messaging separately when those systems have their own contract and authority boundary.
One active POS owns each location; other modules remain explicit.
Capabilities before logos.
An integration is ready only when its data, payment, geography, approval, and recovery boundaries are explicit.
01
What can this provider read and write?
02
Who owns payment collection and refunds?
03
Which countries and account types are supported?
04
How are orders, failures, and retries reconciled?
05
Which locations did the restaurant approve?
06
Read the platform introductionHow can the installation be revoked?