Trentham Padel: Booking, Payments and Software Stack
Prepared for: Ade Whetton
Author: Manus AI
Date: 7 August 2026
Status: Procurement recommendation; commercial prices and commissions require written UK quotations
Currency: GBP, excluding VAT unless stated
Decision: Launch with Playtomic Manager Champion as the court-booking, player-discovery and membership platform, subject to a satisfactory UK commercial contract. Use a supported hardware-provider integration for access and lighting, Square for Restaurants Plus for the staffed café/bar/club shop, separate certified unattended-payment systems for vending and lockers, and a venue-controlled reporting layer for reconciliation and customer analytics.
This is deliberately a federated stack, not an attempt to force one product to do every job. Playtomic is well suited to bookings and player community, but its own documentation shows that its Club API is read-only, its POS is an attended reception function and its booking Extras do not physically release equipment.[1] [2] [3] The venue therefore needs tightly controlled interfaces between several systems rather than a fictional “one app controls everything” design.
1. Recommended system of record
| Business object | Authoritative system | Downstream use | Control requirement |
|---|---|---|---|
| Court inventory, price and booking | Playtomic Manager | Access credential, lighting schedule, occupancy and revenue reporting | Do not maintain a second editable court diary |
| Player-facing match/community profile | Playtomic | Matchmaking and discovery | Treat platform identity separately from venue CRM consent |
| Booking payment and payout | Playtomic/Stripe Connected account | Bank reconciliation and booking revenue | Reconcile gross sale, B2B fee, refund and payout—not just bank net receipt |
| Main-door/court credential | Supported access provider | Local controller and access audit | Booking authorises access; door controller remains locally resilient |
| Racket-rental transaction and bay state | Locker platform | Rental ledger, deposit/damage workflow and stock status | Link to booking reference where supported; preserve an independent audit trail |
| Vending payment and vend result | Machine payment/telemetry platform | Stock, refund and fault management | Successful payment is not proof of a successful vend |
| Café/bar/club-shop sale | Square | Product stock, close-of-day, staff attribution and card settlement | Separate alcohol permissions and attended-service controls |
| Accounting and VAT ledger | Selected UK accounting system | Statutory accounts, VAT, supplier bills and management accounts | Import or reconcile every settlement source separately |
| Incident/support case | Venue ticket/incident register | SLA, refund, maintenance and trend analysis | Link booking, device, time, action and resolution without excessive personal data |
| Management analytics | Venue-controlled reporting store | Occupancy, yield, lifetime value, faults and operating dashboard | Retain exports because the Playtomic API exposes only limited history |
2. Why Playtomic Champion is the day-one recommendation
Playtomic’s public plan page lists Standard, Professional, Champion and Master. Professional adds POS and wallet features; Champion adds memberships, coaches, courses, invoicing, leagues, campaigns, multiple legal entities and API integrations. The Club API is only available to Champion or Master venues.[4] [5] For a six-court commercial venue, Champion is therefore the minimum strategically sensible tier.
The recommendation is not based on a claim that “every club uses Playtomic”. The verified local market includes multiple major platforms. It is based on the combination of established UK operator use, player discovery, open-match behaviour, split-payment capability, court management and a documented hardware-integration route. Playtomic publicly claims more than 6,700 clubs and cites UK multi-site operator Rocks Lane as a customer.[4]
Master should be purchased only if the written quote shows that its support commitment, commercial rate or multi-site terms create more value than its incremental price. The public pricing page does not disclose UK plan prices or commissions, so the project must not approve Playtomic from a slide deck alone.[4]
2.1 Important constraints
| Constraint | Operational consequence |
|---|---|
| Club API is read-only | It can feed CRM, reporting and automation, but cannot create, amend or cancel bookings |
| API history is limited to the previous 90 days | Export/store data continuously; obtain a complete migration and launch snapshot |
| Typical rate limit is around one request per minute | Use a scheduled integration and local cache, not high-frequency polling |
| No separate API test environment is published | Require controlled pre-opening tests with non-public courts/times and rollback |
| API is Champion/Master only | Budget the appropriate plan at every legal entity/site |
| Supported access hardware uses a separate provider integration | Do not custom-code a door release directly against the read-only Club API |
| Failed subscription renewal can make the club inactive after five days | Use a controlled payment method, billing alerts and named backup administrator |
These constraints are taken from Playtomic’s official API and subscription guidance.[5] [6]
3. Booking and customer-payment flow
Under Playtomic’s New Billing Model, online funds are reflected in the club’s Stripe Connected account with Playtomic’s B2B fee already deducted, and payouts are made weekly. Playtomic provides a monthly invoice for its B2B fees. Depending on configuration, split-payment bookings use either pre-authorisation or card-on-file recovery; a failed card-on-file recovery can still leave debt for the club to chase. The club is responsible for issuing an invoice for the full gross booking amount when a customer requests one.[7]
| Stage | System action | Control and reconciliation |
|---|---|---|
| Player books | Court price, cancellation terms and available Extras displayed | Terms version and tax treatment retained |
| Payment authorised | Stripe/Playtomic records each player share | Booking owner liability and failed-share process documented |
| Booking confirmed | Unique booking ID becomes the common reference | Pass booking ID—not unnecessary card/customer data—to operational systems |
| Credential issued | Supported access provider creates a time-limited code/mobile credential | Credential window narrower than building opening hours; local fallback tested |
| Service delivered | Court, equipment and ancillary products fulfilled | Exceptions recorded by booking and asset/channel |
| Refund/credit | Booking platform, POS or vending provider handles its own original payment | One system must not falsely mark another system’s payment as refunded |
| Payout | Stripe, Square and vending acquirer settle separately | Daily/weekly reconciliation bridges gross sales, fees, refunds, chargebacks and bank net |
The finance team should reconcile three different dates: payment date, service date and payout date. Playtomic’s payment tools distinguish payment and service dates and allow CSV export; the selected accounting process must preserve this distinction.[8]
4. Equipment Extras are an order channel—not fulfilment
Playtomic permits only four published Extras: racket rental, balls, overgrips and water. A customer can add them during court pre-payment, and the club sets the price and VAT. Extras cannot be cancelled separately from the reservation.[3]
That functionality is valuable, but it does not tell a locker which bay to open or prove that a vending machine dispensed an item. Day one should therefore use this division:
| Product | Customer purchase route | Physical fulfilment | Exception route |
|---|---|---|---|
| Racket rental | Playtomic Extra or dedicated locker checkout | Assigned smart-locker bay | Alternate bay/backup racket/refund |
| Balls, grips and water | Vending machine; optionally Playtomic Extra when staffed handover is available | Machine vend or staff handover | Telemetry-confirmed refund or alternate channel |
| Clothing and larger rackets | Square club shop/online shop | Staffed collection or controlled click-and-collect | Square return/refund process |
| Alcohol | Staffed licensed Square transaction only | Staff handover after age/condition check | Refusal log and refund under licensing policy |
A Playtomic Extra should not be offered during fully unstaffed periods unless the venue has an automated fulfilment link or an unambiguous collection method. Otherwise the software will create paid orders that no one is present to hand over.
5. Hospitality and club-shop payments
Playtomic’s POS documentation says products are purchased at reception and cannot be bought through the Playtomic app. Although it records sales, costs and stock, it is not the right primary system for a meaningful café/bar operation or unattended retail.[2]
Square for Restaurants Plus is the launch recommendation because it publishes UK terms, supports unlimited devices, live sales and close-of-day reports, remote device management, Square KDS, 24/7 support and no long-term contract. The current public price is £69 per month per location. UK card-present processing is 1.75%; UK online-card processing is 1.4% plus 25p; manually entered/card-on-file payments are 2.5%.[9]
| Launch component | Planning price | Purpose |
|---|---|---|
| Square for Restaurants Plus | £828/year | Bar/café/club-shop service, close-of-day and 24/7 support |
| Square Register | £699 + VAT | Principal fixed till |
| Square Terminal | £149 + VAT each | Mobile/backup payment and events |
| Square Stand | £99 + VAT, iPad excluded | Optional second service/retail point |
| Kitchen display screen | £549 + VAT | Required only when prepared-food throughput justifies it |
| Square Kiosk software | £35/device/month | Defer until an unattended food/drink kiosk has a valid operating case |
The day-one hardware allowance should be £1,400–£2,500, depending on printers, drawer, iPad, scanner and network accessories. Square’s offline-payment feature has time and reconnection limits and leaves the merchant liable for expired, declined or disputed offline payments, so it is a continuity tool rather than guaranteed settlement.[9]
Square for Retail Plus should not be purchased simultaneously at launch unless the club shop has enough SKU depth to need purchase orders, advanced stock counts, barcode labels and COGS reports. If that threshold is reached, it is publicly priced at £49/month/location with 1.6% in-person processing.[10]
6. Platform comparison
The scores below are analyst judgements on a 1–5 scale based on public evidence reviewed on 7 August 2026. A low score can reflect unavailable evidence rather than a weak product; every shortlisted supplier must demonstrate the disputed capability.
| Platform | UK/player discovery | Booking/community | Unattended access/lighting | Venue data/API | Hospitality/retail | Commercial transparency | Weighted view |
|---|---|---|---|---|---|---|---|
| Playtomic | 5 | 5 | 4 | 3 | 2 | 1 | 4.15/5 |
| Padel Mates | 3 | 4 | 2 | 2 | 2 | 1 | 2.75/5 |
| MATCHi | 2 | 4 | 5 | 2 | 2 | 1 | 3.05/5 |
| Bookaball | 2 | 4 | 3 | 4 | 2 | 1 | 3.00/5 |
| Doinsport | 1 | 4 | 5 | 4 | 4 | 2 | 3.25/5 |
MATCHi publicly offers booking-linked light/passage automation and rental kiosks, which makes it the most important automation comparator.[11] Bookaball offers a white-label booking/community product and explicitly emphasises club control of player relationships, but its public customer base is materially smaller and its UK access/payment evidence is limited.[12] Doinsport publicly combines booking, CRM, POS, shop, virtual access and lighting automation, but its strongest published market proof is continental Europe rather than the UK.[13] Padel Mates is used by UK operators including Rocket Padel, but public operator pricing, API and access details are not disclosed.[14]
The procurement should therefore invite Playtomic, Padel Mates and MATCHi to the same scripted demonstration. Bookaball and Doinsport remain reserve challengers if data ownership/white-label control becomes more important than player-network reach.
7. Software and payment cost envelope
Because the largest commercial variable—booking-platform commission—is not publicly quoted for UK clubs, the model should express it as a sensitivity rather than invent a price.
| Cost item | Year-one planning allowance | Recurring annual allowance | Confidence |
|---|---|---|---|
| Booking platform subscription | £3,000–£12,000 | £3,000–£12,000 | Provisional until written quote |
| Booking/acquiring/B2B transaction fees | Model at 1%, 2%, 3.5% and 5% of online booking GMV | Variable | Tender sensitivity, not a claimed Playtomic rate |
| Supported access/lighting software licences | £1,000–£4,000 | £1,000–£4,000 | Included within wider technology allowance—do not double count |
| Square software | £828 | £828 | Public price |
| Square payment processing | 1.75% of card-present sales; online/manual as published | Variable | Public standard price |
| Square hardware and setup | £1,400–£2,500 | £250–£750 replacement/maintenance reserve | Planning allowance |
| Venue reporting/reconciliation integration | £5,000–£15,000 | £2,000–£6,000 | Quote required |
| Accounting, receipt capture and bank feeds | £600–£2,000 | £600–£2,000 | Planning allowance |
| Incident/helpdesk system | £500–£2,500 | £500–£2,500 | Planning allowance |
| Fixed first-year software/integration envelope | £11,328–£38,828 | Excludes percentage transaction fees and access hardware | |
| Fixed recurring envelope | £7,928–£27,328 | Before transaction fees and labour |
At £1 million annual online court-booking GMV, every one percentage point of platform/payment cost is £10,000 per year. The difference between a 2% and 3.5% commercial rate would therefore be £15,000 per year, making negotiated transaction economics more important than a few hundred pounds of subscription price.
8. Integration design
The venue-controlled reporting layer should pull allowed Playtomic data on a scheduled basis, convert UTC timestamps to Europe/London with daylight-saving tests, preserve source IDs and maintain a durable history beyond Playtomic’s 90-day API window. It should ingest Square sales exports/API data, vending/locker telemetry and device/incident events into separate raw tables before producing management metrics.
No integration should store card data. OAuth client secrets, hardware API tokens and vendor credentials are held in a managed secrets store and rotated after staff/supplier change. A read failure creates an alert; it does not trigger speculative door or payment changes. Booking access is driven by the supported access connector and cached local schedule described in the remote-operations architecture.
| Integration | Direction | Frequency | Failure behaviour |
|---|---|---|---|
| Playtomic → access provider | Supported vendor route | Near real time plus local cache | Existing confirmed credentials survive; new access handled by support/closure policy |
| Playtomic → reporting store | Read-only API/approved export | Every 5–15 minutes subject to rate limits | Queue retry; dashboard marks stale; no customer-facing action |
| Square → accounting/reporting | API/export and bank feed | Daily plus close-of-day | Flag unreconciled batch; do not duplicate revenue |
| Locker/vending → incident/reporting | Vendor webhook/API/export where available | Event-led plus daily reconciliation | Machine remains independently operable or channel is isolated |
| Incident register → management dashboard | API/export | Near real time | Manual incident log remains available |
| ## 9. Contract non-negotiabl | |||
| (Content truncated due to size limit. Use line ranges to read remaining content) |