POS & Check-In Events
Overview
This page covers integrating a point-of-sale (POS) or back-office system with Belong CheckIn: collecting staff-confirmed payments via QR, and attributing each check-in to where it came from.
Payment-request QR (POS pattern)
The primary POS integration is the payment-request QR: the customer scans, staff enter the amount from your POS, and the customer pays from their wallet. This reuses the venue owner-quote payment flow — no separate access mode is needed. See the Payments guide for the operator and customer flows.
A payment-request QR encodes a small payload (distinct from the standard check-in QR) and the app re-validates the venue's settings on every scan, so a stale QR can't be used to force a payment:
type VenuePaymentRequestQRData = {
type: 'venue_payment_request'
hubId: string
hubName: string
venueWallet?: string
locationLabel?: string
source: 'venue_static_qr' | 'checkin_qr' | 'pos_receipt_qr'
timestamp: number
version: number
}
Check-in attribution
Each check-in records where the request originated, so you can reconcile against your POS:
| Field | Values | Meaning |
|---|---|---|
payment_request_source | checkin_qr, venue_static_qr, pos_receipt_qr | Whether the request came from the standard check-in QR, a static venue QR, or a POS receipt QR |
payment_request_label | free text | Optional staff-facing label such as a table, bar, patio, or register |
These are runtime attribution fields — they don't change a venue's check-in configuration, which stays in the venue's settings.
Reading check-in activity
- Pending requests — staff surfaces read pending owner-quote requests (with source and label) so they can send the amount
- History — venue operators can review recent check-ins and reward activity from their venue's CheckIn area
x-api-key. Outbound event webhooks (push notifications to your own endpoint on each check-in) are on the roadmap; today, integrate by reading check-in and venue data through the API.