POS Webhooks: CRM Sale Notifications & Scheduling Collect-Payment

The register should not be an island. Outbound to CRM on sale completed. Inbound from scheduling on collect-payment. Same customer story, separate databases.

POS and CRM link through webhooks and Suite Platform service links — not joined schemas.

Guide: POS buyer's guide

---

Outbound: sale completed → CRM

When a cashier completes a sale:

1. POS persists sale, tenders, and invoice in

   pos_*

   tables
2. If configured, POS fires sale-completed webhook to CRM
3. CRM creates or updates contact activity and revenue attribution

No shared session. CRM validates webhook signature and writes to

crm_*

tables.

---

Inbound: scheduling collect-payment → POS

When a client pays a deposit at booking or check-in:

1. Scheduling product fires collect-payment webhook
2. POS accepts payload and records payment against appointment context
3. Front desk does not re-key card or amount at register

Honest scope: POS does not replace Receptionist billing or Stripe Connect — each product owns its payment rails where applicable.

---

Why webhooks instead of shared DB

| Approach | Problem | | --- | --- | | Shared tables | Couples deploy cadence; one migration breaks siblings | | Nightly sync | Customer timeline is always stale | | Manual re-key | Errors, delays, angry managers | | Webhooks + contracts | Independent products, near-real-time events |

---

Configuration checklist

• [ ] CRM service link registered on Platform
• [ ] Sale-completed webhook URL and secret in POS
• [ ] Scheduling collect-payment endpoint exposed on POS
• [ ] Tenant IDs mapped across products
• [ ] Test sale in staging before go-live

---

Anti-patterns

• Expecting POS to host voice AI billing
• Assuming inventory reservation without Inventory SKU entitled
• Skipping idempotency on webhook handlers (retries will duplicate)

---

Related reading

• POS checkout use cases
• CRM pipeline use cases
• Suite gateway

Contact Tekvers · CRM integrations