Courtely connects the two halves of a padel venue that usually drift apart: the online booking website and the in-venue point of sale. With a single CRTLY pairing code, your web bookings and your counter become one synchronized operation. A court reserved on your site appears instantly on the POS, and a sale completed at the till reconciles against that same reservation. The headline benefit is simple: one schedule and one ledger across web and counter, with no double entry and no conflicting calendars.
This sync is built for how padel venues across the GCC actually run — bookings arriving online around the clock while staff serve players at the counter and on court. Courtely keeps both worlds in step so nobody double-books a court, no walk-in is turned away from a slot that's already sold, and the day's revenue ties out cleanly. Everything is bilingual Arabic and English, RTL-aware, and priced in SAR for the GCC market.
Crucially, Courtely is honest about how money moves. Online payments are processed by Moyasar across Visa, Mastercard and Mada; in-venue payments run on NearPay for card-present tap-to-pay, alongside cash and refunds. These are two distinct payment rails — Courtely does not route both through a single processor. What it does is reconcile their records into one booking ledger, so the financial picture is unified even though the payment hardware is not.
Pairing a venue is deliberately simple. A venue admin pastes a CRTLY-XXXX-XXXX-XXXX code into Courtely's settings — the code is single-use and expires after fifteen minutes for security. Courtely's pairing function then mints a live API key and a webhook secret, completes the handshake with the LazyWait POS, and automatically maps your courts to the matching POS resources. There is no manual cross-referencing of court names and no spreadsheet to maintain. From the very first booking, both systems share one accurate, consistent map of your venue's courts and locations.
Bookings move in both directions. When a reservation is created or changed in Courtely, the change is pushed to the POS through a webhook so the counter is updated right away. When a change originates on the POS side, a scheduled pull brings it back into Courtely. To prevent the same edit from echoing endlessly between the two systems, Courtely uses a loop guard built on a source marker and a content hash — it recognizes a change it has already applied and stops there.
This matters because a naive two-way sync can spiral: System A tells System B, which tells System A, which tells System B again. Courtely's design treats each booking change as a single fact with one source of truth, applied exactly once on the other side. The practical outcome for your venue is a live shared schedule you can trust — confident that a slot blocked online is blocked at the counter, and a counter cancellation frees the slot online.
A reservation passes through a lifecycle, and Courtely keeps that lifecycle aligned on both sides. The states a player moves through online — confirmed, checked-in, completed and cancelled — map cleanly to the POS states of reserved, paid and cancelled. So when staff check a player in at the counter, or a customer cancels from your website, both systems reflect the same reality. Your floor team and your public booking page are never working from contradictory information about who has paid, who has arrived, and which courts are free.
Sync isn't useful unless your staff can see it. Inside the POS, a dedicated Bookings screen reads the synced reservations and shows them where the team already works: court name, status, date and time, customer and price. When a player who booked on the web arrives, the counter already has the details — no phone confirmation, no separate calendar app, no scramble at the door. The till becomes a single window onto who is coming, when, for which court, and whether they've paid.
Online and in-venue payments use different hardware, and Courtely is precise about this. Online checkout is handled by the Moyasar hosted form across Visa, Mastercard and Mada, with optimistic verification plus server-authoritative webhook confirmation. At the venue, NearPay terminals handle card-present tap-to-pay and contactless, alongside cash handling, refunds, split bills and printed receipts. The sync does not merge these processors into one; it reconciles the booking and sales records so both rails settle against a single, unified booking ledger.
This honest framing is the whole point. You don't have to pretend one processor covers everything, and you don't have to reconcile two systems by hand at the end of the night. Courtely lets each rail do what it does best — Moyasar online, NearPay on the counter — while presenting management with a single source of truth for bookings and the revenue tied to them. One schedule, one ledger, two payment methods, no double entry.