Geo-fencing or Geo-location

Overview

PodPlay cannot read a Customer's physical location, so no feature can depend on where a Customer is standing. That rules out:

1. Geo-fencing Reservations to a radius around the Club
2. Verifying physical presence at Check-in
3. Checking a Customer in automatically when they arrive

This feature has been evaluated several times since 2024. The two constraints behind the decision are platform-level, not PodPlay-level, and neither has changed.

What Clubs ask for

Three requests come up most often:

• Restrict who can book — only allow Reservation booking or Membership purchase from Customers within a set distance of the Club
• Verify presence at Check-in — confirm the Customer is physically at the Club before check-in succeeds, so a Customer cannot check-in remotely

Geo-fencing isn't necessary with a QR code as the Customer must physically be in the Club to scan their QR code.

• Auto Check-in on arrival — detect that the Customer reached the Club and allow check-in without a button tap

All three need the same underlying capability: a reliable, continuous read of the Customer's location.

Impossible on Web App

Browsers do not give a web application usable location data, nor can it be forced upon the Customer. And a large share of Customers (all new Customers who do not download the iOS or Android App before booking) book through the Web App (the basis of your Club's environment and Dashboard) rather than the iOS or Android App.

Any location rule would therefore apply to some Customers and not others, which makes it unusable as a booking restriction or a check-in gate.

A rule that a Customer can bypass by opening the Web App is not a rule.

Always Optional on App

The iOS and Android App can request location access. Apple and Google both require the Customer to grant that permission on their own device, and the Customer can refuse it or revoke it later.

That permission prompt sits directly in the purchase path. A Customer who declines it, or who is asked for it before they have booked anything, is blocked by extra friction from completing a Reservation. Adding a mandatory location prompt to the booking flow costs Clubs completed Reservations. This friction is a larger problem than the problem geo-fencing intends to solve.

Location permission cannot be forced. Even on the App, the Customer can always decide to not share location data. There is no setting a Club or PodPlay can apply that grants location access on a Customer's behalf.

What to use instead

Access control in PodPlay works on Customer identity (email + phone number), not Customer location. These options cover most of what Clubs want geo-fencing for.

Restrict who can book

• Hidden Membership — the Membership does not appear publicly; only Customers you send the link to can purchase it
• Corporate Membership / Local Business Partner — assign a hidden Group Membership to a defined set of Customers, such as a partner business's employees
• Promo Code — gate a price behind a code you distribute to the group you want to reach
• Booking Horizon — limit how far in advance any Customer can book

Verify presence at Check-in

• QR Code check-in on site — the Customer taps the Check-in Button in the App to generate a QR Code, then presents it at the Club

  • The scan happens in the Club, at the front desk, so presence is confirmed by the scan rather than by location data
• Staff Check-in from the Dashboard — Club staff Check in a Customer they can see in front of them

FAQs

Could you add geo-fencing to the App only, and leave the Web App alone?

No. A restriction that applies only in the App is not a restriction, because the Customer can complete the same Reservation in the Web App. The gap would also be invisible to Club staff, who would assume the rule was being enforced.

Can you use the Customer's IP address instead of their device location?

IP address is not a usable substitute. It locates the network, not the Customer, and it is wrong or missing often enough that it cannot support a booking restriction or a Check-in gate.

We only want to stop Customers Checking in remotely. Is that different?

The requirement is the same, and the answer is on-site QR Code Check-in. The Customer presents a QR Code that Club staff or a scanner at the Club reads. Presence is confirmed at the point of scan, with no location data involved.

For Autonomous locations, where the Customer Unlocks Door and Checks-in, the same requirements persist: the Customer can use the Web App without the requirement of geo-location identification.

Will this change if Apple or Google change their rules?

While this would be interesting, Apple and Google will likely never publish an App that requires location-based identification based on federal and local regulations. Access to a Customer's location is always optional.

The Web App limitation is independent of Apple and Google, so a change on the App side would not entirely solve it. The permission model would also have to change so that location access no longer needs the Customer's consent, which is not a direction either platform is moving.