Description

Finally. A booking platform built for tour operators.

Not restaurants. Not appointments. Not generic events.

Tours. Activities. Excursions.

UltimaTour Operator helps you run your operation directly inside WordPress, from the first booking to the final guest follow-up. It is built for businesses that sell and operate tours, activities, excursions, charters, rentals, and experiences.

Your website. Your bookings. Your customers. No UltimaTour commission on direct bookings.

Operator connects public booking calendars, direct online bookings, tours, departures, capacity, availability requests, customer records, digital pre-check-in, document review, QR tickets, mobile staff check-in, attendance, payments, communications, reviews, temporary holds, coupons, incidents, Google Calendar export, and revenue planning.

A booking is only the beginning. Your team still needs to know who is coming, who has paid, who completed required information, who is ready, who checked in, and what happens next. Operator keeps that operational journey connected.

Customers can prepare before arrival. Staff can work from phones and tablets. Operators can manage departures, participants, evidence, communications, and post-tour actions from one place.

Use Operator for dive and snorkeling businesses, boat and sailing tours, fishing charters, ATV and buggy tours, zipline parks, kayak and paddleboard rentals, walking and food tours, eco and wildlife tours, museums, sightseeing businesses, adventure parks, and other scheduled experiences.

Your operational data stays in your WordPress database. Optional external services are disclosed below and remain governed by their respective settings. Operator remains usable as a local WordPress operations platform.

The guided setup creates your business profile, opening hours, physical location, and first Tour. Every choice can be refined later.

Install UltimaTour Operator, publish your first departure, and start taking direct bookings.

External Services

Operator displays a required-registration explanation after activation but sends no UltimaTour Ecosystem registration request until an administrator intentionally selects Create / Verify Ecosystem Records. Reviews and TrustEmporium are free but remain disabled until an administrator enables them in Integrations. Other optional services connect only after configuration or when a visitor chooses the configured payment or anti-spam flow.

UltimaTour Reviews

Purpose: Create or verify the operator’s free UltimaTour Reviews listing for public discovery and review collection.

Data sent: Operator/business profile data such as business name, site URL/domain, public website URL, public contact email/phone when configured, logo URL, location/geography fields, public description/story, public tour profile summaries, opening hours, social links, and review/discovery settings. Booking, customer, participant, payment, and operational records are not sent by this setup step.

When data is sent: During free ecosystem record creation/verification, a manual re-check, and later profile or review sync while UltimaTour Reviews remains enabled. Before each outgoing exchange, Operator verifies its signed core-integrity manifest and protected file hashes; exchange is paused if integrity is not clean. The administrator can turn Reviews off independently in Integrations.

Service URL: https://ultimatour.com/wp-json/ultimatour-review/v1/.

UltimaTour Ecosystem / Partner Registry

Purpose: Administrator-authorized, free integrity registration of this Operator installation; signed Operator-core integrity protection; connection-health monitoring; and authentication context for administrator-enabled Reviews and TrustEmporium exchanges. This is an integrity and trust-service connection, not a commercial licensing or payment service.

Data sent during initial registration or a manual registration refresh: Operator/site name, WordPress administrator email, site URL and canonical domain, Operator REST API base URL, generated installation identifier, plugin slug/type/version, WordPress version, PHP version, registry URL, registration mode, and connection-health status. The registry returns a signed registration credential. Some internal compatibility fields retain “license” names, but that credential authenticates integrity and trust-service requests only; it does not represent a purchase or commercial entitlement.

Data sent in the six-hour integrity heartbeat: plugin slug/type/version, installation identifier, site URL and canonical domain, registry URL, report time, WordPress version, PHP version, connection health, and Operator-core integrity results. Core integrity results contain the signed-manifest payload hash and signature status, scan time, clean/tampered state, counts of official/scanned/mismatched/missing/unexpected protected files, and the relative paths of affected files. The heartbeat does not send WordPress administrator URLs, server fingerprints, file contents, booking or tour records, customer or participant data, payment data, or unrelated plugin inventory.

When data is sent: Only after an administrator selects the disclosed Create / Verify Ecosystem Records action. Registration may then be retried manually and the integrity heartbeat runs every six hours. An administrator can also select “Run Integrity Heartbeat Now” to send the same disclosed payload on demand. Operator stores the last heartbeat attempt, last successful heartbeat, result, HTTP code, error, next scheduled run, and current local integrity summary so they remain visible on the Ecosystem Participation screen. Operator also performs the same local core-integrity scan before outgoing UltimaTour Reviews or TrustEmporium exchange, but those exchanges remain off unless an administrator enables them in Integrations. A failed scan pauses only those optional trust-service exchanges and reports the failure on the next heartbeat; it does not disable local Operator pages, administration, bookings, tours, customers, calendars, check-in, closures, or stored records. A registry outage likewise never blocks local functionality. Registration and heartbeat never check payment, a subscription, a purchase, or a commercial entitlement and never unlock a paid Operator-core feature.

Service URL: https://partner.ultimatour.com/.

Google Calendar API

Purpose: Optional one-way export of future departures to an administrator-selected Google Calendar.

Data sent: OAuth client credentials supplied by the administrator, OAuth authorization data, departure title, date/time, capacity, booked count, status, location, public booking link when configured, and Operator admin deep links.

When data is sent: During OAuth authorization, when the administrator lists calendars, when the administrator manually syncs future departures, and when enabled departure changes are mirrored.

Service URLs: https://accounts.google.com/, https://oauth2.googleapis.com/, and https://www.googleapis.com/calendar/v3/.

Terms: https://policies.google.com/terms

Stripe

Purpose: Optional Stripe Checkout payment processing.

Data sent: Booking reference, amount, currency, selected tour/departure description, customer contact details needed for checkout, and booking metadata.

When data is sent: Only when Stripe is enabled and a guest selects Stripe Checkout, or when Stripe webhooks notify this site about payment status changes.

Service URLs: https://api.stripe.com/ and https://checkout.stripe.com/.

Terms: https://stripe.com/legal

PayPal

Purpose: Optional PayPal Checkout payment processing.

Data sent: Booking reference, amount, currency, selected tour/departure description, customer contact details needed for checkout, and booking metadata.

When data is sent: Only when PayPal is enabled and a guest selects PayPal Checkout, or when PayPal return/webhook flows notify this site about payment status changes.

Service URLs: https://api-m.paypal.com/, https://api-m.sandbox.paypal.com/, and https://www.paypal.com/.

Terms: https://www.paypal.com/legalhub/useragreement-full

OpenStreetMap Nominatim

Purpose: Optional reverse geocoding for derived geography from operator coordinates.

Data sent: Coordinates entered or saved by the administrator.

When data is sent: Only when the administrator uses geography derivation features.

Service URL: https://nominatim.openstreetmap.org/.

Usage policy: https://operations.osmfoundation.org/policies/nominatim/

OpenStreetMap Map Tiles

Purpose: Optional administrator-facing location picker map display for Operator Profile coordinates.

Data sent: Browser requests for map tiles around the viewed coordinates or map viewport, plus ordinary request metadata handled by the tile provider such as IP address and browser headers.

When data is sent: Only when an administrator opens the location picker map in Operator Profile/settings and the browser loads the map tiles.

Service URL: https://tile.openstreetmap.org/.

Tile usage policy: https://operations.osmfoundation.org/policies/tiles/

Cloudflare Turnstile

Purpose: Optional anti-spam protection for public booking, availability request, notify-me, request-departure, and local customer submission forms.

Data sent: Visitor browser verification data handled by Cloudflare and the site key configured by the administrator.

When data is sent: Only when Turnstile is enabled, configured, and displayed on a protected public form before that form is submitted.

Service URL: https://challenges.cloudflare.com/.

Terms: https://www.cloudflare.com/website-terms/

Google reCAPTCHA

Purpose: Optional anti-spam protection for public booking, availability request, notify-me, request-departure, and local customer submission forms. Operator supports Google reCAPTCHA v3 score checks and Google reCAPTCHA v2 checkbox challenges.

Data sent: Visitor browser verification data handled by Google and the site key configured by the administrator.

When data is sent: Only when reCAPTCHA is enabled and configured for a protected public form. reCAPTCHA v3 executes before submission to obtain a verification score; reCAPTCHA v2 sends data when the visitor completes the checkbox challenge.

Service URL: https://www.google.com/recaptcha/.

Terms: https://policies.google.com/terms

UltimaTour Partner Information

Purpose: Provide the mandatory free UltimaTour Ecosystem registration, installation-integrity, and ecosystem connection services described above.

Data sent: The site, installation, version, connection-health, and Operator-core integrity information listed in the UltimaTour Ecosystem disclosure above. Operator does not inventory, authorize, download, install, update, repair, or activate add-on plugins.

When data is sent: After the administrator authorizes the required free registration, during manual registration retries, and during the six-hour operational heartbeat. Reviews and TrustEmporium exchanges require their own administrator-enabled settings.

Service URL: https://partner.ultimatour.com/.

TrustEmporium

Purpose: Create or verify the operator’s free TrustEmporium business record for verified business, incident, and post-tour event infrastructure. Background customer lookups, operational TrustEmporium lookups, and intentional post-tour customer record submissions remain controlled by their own settings or administrator actions.

Data sent: Operator/business identity such as business name, site URL/domain, public contact email/phone where available, and registration identifiers needed to match, link, or create the business record. When TrustEmporium is configured, customer submissions such as bookings, availability requests, notify-me requests, and request-departure requests may queue a background lookup using the customer name, email, phone, request context, booking reference, tour/departure, date/time, and guest count where available. Intentional post-tour customer record submissions may send customer name, email, phone, tour name, departure date/time, booking reference, record type, and the operator-entered note. Payment card or funding-source data is never sent.

When data is sent: TrustEmporium remains disabled until an administrator enables it in Integrations. Data is then sent during free ecosystem record creation/verification, a manual re-check, configured background enrichment after a customer submission, an operator-requested lookup retry, or an intentional post-tour customer-record submission. Before each exchange, Operator verifies its signed core-integrity manifest and protected file hashes; exchange is paused if integrity is not clean. Background results are operator-only and never block booking, payment, availability-request, or notify-me submission.

Service URL: https://trustemporium.com/.

Data and responsibility: https://trustemporium.com/data-responsibility/

Screenshots

Operator dashboard with daily operations overview.

Public booking calendar. — Operator dashboard with daily operations overview.

Installation

Upload the plugin folder to /wp-content/plugins/ or install the plugin zip through WordPress.
Activate “UltimaTour Operator” from the Plugins screen.
Open Operator in the WordPress admin menu.
Configure Operator Profile, tours, departures, payment settings, and public booking pages.

FAQ

Does UltimaTour Operator use UltimaTour’s hosted ecosystem?: Operator asks an administrator to register free of charge with the UltimaTour Ecosystem for installation identity, integrity, and connection health. Registration starts only after the administrator uses the disclosed Create / Verify Ecosystem Records action. Until then, Operator remains fully usable for local tours, bookings, customers, calendars, closures, check-in, and administration. UltimaTour Reviews and TrustEmporium exchanges remain off until an administrator enables them in Integrations. None of these services sells, unlocks, meters, blocks, or disables the Operator core.
How does Operator protect Reviews and TrustEmporium from altered Operator code?: The official package contains a signed integrity manifest with SHA-256 checksums for Operator’s protected core files. Operator verifies the manifest signature and re-hashes those files locally before trust-service data exchange and during its heartbeat. Modified, missing, or unexpected protected files cause a visible integrity warning, are reported to the UltimaTour Ecosystem, and pause outgoing UltimaTour Reviews and TrustEmporium exchanges. Bookings and other local operational data remain available and are never deleted by an integrity failure. Reinstalling the official package restores the protected files; the next successful scan and heartbeat restores trusted exchange.
Does the plugin store credit card data?: No. Stripe and PayPal payments use provider-hosted checkout flows. Operator stores payment status, amount, gateway, and provider reference data only.
Can I use manual or offline payments only?: Yes. Manual/offline payments can be used without Stripe or PayPal.
Does Google Calendar update Operator records?: No. Base provides one-way export from Operator to Google Calendar. Operator remains the editable source of operational records.
Does this plugin acquire other plugins?: No. Operator does not download, purchase, install, update, repair, or activate other plugins. Separately installed modules can attach to Operator later through its integration interfaces.

Reviews

snubasxm August 14, 2026

I do not really like writing reviews, but this plugin really deserves one. We tried it for our tour business and honestly did not expect this much from a free plugin. It feels like it was made by people who actually understand tour operators. It took a little time to set everything up, but once it was running, everything just made more sense. Bookings, guest information, tickets and check-in are all in one place. We are definitely keeping it.

Read all 1 review

Contributors & Developers

“UltimaTour Operator” is open source software. The following people have contributed to this plugin.

tesystems

Translate “UltimaTour Operator” into your language.

Interested in development?

Browse the code, check out the SVN repository, or subscribe to the development log by RSS.

Changelog

1.3.19

Harden WordPress.org compliance for referral eligibility checks and onboarding presentation.

1.3.18

Keep referral eligibility checks current while using WordPress-safe prepared database identifiers.

1.3.17

Enable availability-request payment reminders by default for new installations while preserving each operator’s explicit choice to turn them off.

1.3.16

Add optional daily payment reminders for accepted availability requests while their temporary hold remains active and unpaid.
Stop reminders automatically at payment, cancellation, hold expiry, or the exact online-booking cutoff configured for that departure and Tour.

1.3.15

Let an accepted integrity heartbeat confirm the current Operator, WordPress, and PHP versions locally so a normal heartbeat clears obsolete registration-refresh warnings.
Preserve the last confirmed registered runtime versions when a heartbeat fails, is skipped, is rejected, or returns a non-success HTTP response.

1.3.14

Report the actual recurring integrity-heartbeat schedule and keep one-shot refresh events out of the displayed cadence.
Prevent legacy registration scheduling from downgrading Operator’s six-hour heartbeat to a twice-daily recurrence.

1.3.12

Replace the easy-to-miss inline booking-form loading message with an accessible progress dialog, honest timing guidance, and automatic focus on the loaded form.

1.3.10

Scope post-tour portal body styling to the standalone portal so Operator public assets do not override the active WordPress theme typography or page background.

1.3.9

Corrected the shared public booking-calendar dialog close label so Calendar help and availability-request dialogs announce an accurate accessible control name.

1.3.8

Fixed first-run onboarding progression across business, location, Tour, and availability steps.

1.3.6

Made onboarding map coordinates optional while preserving location and timezone requirements.

1.3.5

Fixed first-run opening-hours persistence and onboarding progression.
Cleared onboarding navigation input warnings reported by Plugin Check.

1.3.4

Preserve and validate nested opening-hours fields so the setup wizard saves Step 2 and advances reliably.
Use the shared sanitized request wrapper when selecting a setup step.

1.3.2

Make the first-run setup handoff durable across normal WordPress activation flows.
Add a Start setup fallback action on the Plugins screen until onboarding is complete.

1.3.1

Open the guided setup automatically after a fresh activation while keeping normal Operator menus locked until setup is complete.
Add quick weekday-copy controls to the opening-hours setup step.
Prevent the pre-setup integrity notice from calling an invalid onboarding-state method.

1.3.0

Add a persistent five-step first-run setup for business details, opening hours, location, timezone, a first Tour, and real future availability.
Keep local setup independent from optional UltimaTour Ecosystem participation.
Protect existing operational installations from first-run setup locking and add audited, time-limited administrator recovery access.

1.2.1

Add a vendor-neutral forecast financials hook so OTA connectors can contribute expected compensation while preserving truthful settlement details.
Distinguish forecast revenue, settlement payer, received revenue, and outstanding revenue in booking forecast details.

1.2.0

Add staff-confirmed departure closeout so unresolved attendance is not marked no-show until the operator records the actual departure.
Add participant document bulk approval and replacement requests while keeping customer notification optional.
Add projected booking revenue to the dashboard and calendar with browsable year, month, and ISO week views.
Keep large booking rows compact by default with an explicit full-detail control.
Preserve the governed Smart Commerce communication insertion point for eligible external commerce integrations.

1.1.4

Fix AJAX-loaded public booking form initialization so calendar-launched bookings preserve the complete validation, pricing, participant, document, and Stripe checkout path.
Add a governed Smart Commerce communication insertion point that renders empty unless a commerce module supplies eligible content.