GMC Tours — documentation (Joomla)

GMC Tours · Joomla 5 / 6 · Documentation

GMC Tours — documentation

Everything from installing the package to running a departure day: setup, the booking engine, payments, operations screens, the reseller API and the compliance exports. If you are looking for the WordPress plugin instead, its own documentation covers the port.

Install & update

GMC Tours ships as one Joomla package (pkg_gmctours) containing the component, the site and API plugins and the scheduler task plugin. Install it the ordinary way: System → Install → Extensions, upload the zip, done. The installer creates its tables and then runs an additive migration on every update, so upgrading never asks you to touch the database.

• Requirements — Joomla 5.1 or newer (Joomla 6 included), PHP 8.1+, MySQL 8 / MariaDB 10.6+.
• Licence & updates — paste your Download Key into System → Update → Update Sites for GMC Tours. Joomla then offers updates in the normal Extensions → Update screen.
• Never use “Rebuild Update Sites” — it silently drops the Download Keys of every extension on the site, and every self-hosted updater stops working until you paste them back in. If updates stop being offered, re-check the key first.

Migrations are additive only: columns are added, never dropped or renamed. A downgrade is therefore safe from the database's point of view, though the older code will simply ignore the newer columns.

Configure

All settings live in Components → GMC Tours → Options. You do not need most of them to take a first booking — the defaults are deliberately conservative.

Interface mode — start in Simple

The Interface mode setting decides how much of the component you see. Simple (the default) shows the screens a single operator needs: excursions, departures, bookings, the calendar and the day sheet. Advanced reveals the rest — resources, add-ons, options, gift cards, API keys, webhooks, payouts and the marketplace screens. Switch to Advanced when you need one of those; nothing is deleted in Simple, it is only hidden, and the data stays exactly where it is.

The settings that actually matter on day one

Permissions are ordinary Joomla ACL. Give guides core.edit.state if they should check people in without being able to edit tours.

Your first tour, end to end

1. Create an excursion — the product itself: meeting point and pickup, duration, difficulty, languages, what is and is not included, a gallery and a cancellation policy.
2. Choose its product type — timeslot (fixed departures), opendate (valid for N days, no fixed date), private (one party books the whole thing) or multiday.
3. Add price tiers — Adult, Child, Senior… each with its own price, age band and quantity band. A tour with one tier is perfectly normal.
4. Create departures — one row per start time, each with its capacity, base price and guide. Use Generate to create a recurring pattern instead of typing them one by one.
5. Publish and place the menu item — add a Joomla menu item pointing at the tours catalogue, or link straight to a single excursion.

Set min_party, max_party and cutoff_minutes on the excursion when it matters: the cutoff is how close to departure you will still accept a booking, and it can be overridden per departure for the one 06:00 start that needs a longer lead time.

How the booking engine works

This is the part worth understanding, because it explains what your customers see when a tour is nearly full.

1. Quote — the customer picks a departure and party mix. The quote returns a full money breakdown: subtotal, per-tier volume discounts, add-ons, coupon, tax, deposit and balance.
2. Hold — seats are decremented inside a transaction and the booking is created with status hold and an expiry. This is what stops two people buying the last two seats at once.
3. Confirm — payment succeeds and a single guarded update flips the booking to confirmed only if the hold is still valid and the token matches. An expired hold cannot be confirmed, and neither can someone else's booking.
4. Expire — the scheduler returns the seats of holds nobody paid for, and promotes the waitlist if there is one.

Seat accounting has one source of truth: a booking's seats are either currently decremented or already returned, recorded on the booking itself. That is what stops a cancel-then-no-show sequence from returning the same seats twice and quietly overbooking the departure.

Pricing

• Price tiers — per-person ticket types with age and quantity bands.
• Volume breaks — a tier can get cheaper per person as the party grows.
• Add-ons and options — extras (equipment, transfer, lunch) priced per person or per booking.
• Coupons — percentage or fixed, with a usage cap and a minimum party size. The usage slot is claimed atomically when the seat is held, so a coupon capped at 10 uses cannot be redeemed 11 times by simultaneous buyers.
• Gift cards — sold on the site, redeemed as store credit at checkout. When the card covers the whole amount, checkout skips the card payment entirely.
• Deposits — take a percentage now and the balance later; the balance can be collected from the booking row or charged automatically on its due date.

Payments

Stripe is the supported provider. Set payment_provider = stripe, paste your publishable and secret keys, and register the webhook endpoint with its signing secret — the webhook is not optional: it is what turns a paid checkout into a confirmed booking if the customer closes the tab before returning to your site.

• Checkout runs embedded (on your page) or hosted (on Stripe's), your choice.
• Payments are an append-only ledger: charges, refunds and fees are separate rows, so a partly refunded booking still reconciles.
• Stripe Connect (Portal mode) splits each payment between you and the host, and the payout screen tracks what is owed and what has been sent.
• Refunds are issued from the booking row and cascade correctly: inventory returns, the coupon slot is released, and the waitlist is offered the seat.

Run your first live transaction in Stripe test mode and confirm a booking flips to confirmed from the webhook alone, with your browser closed. If it does not, the endpoint or the signing secret is wrong — and every later payment would be paid-but-unconfirmed.

Running the day

Calendar

A month view of departures with their load, so you can see at a glance which days are full, which are thin and which are about to fall below their viability threshold.

Dispatch board

Today's departures side by side with their guides, resources and passenger counts — the screen you keep open while the day is running.

Manifest (day sheet)

Pick a departure and get its passenger list with participant details and operator notes. It prints cleanly (no PDF library involved) and exports a CSV roll-call, one row per participant, with a UTF-8 marker so accented names survive Excel.

Check-in

Mark people present at the meeting point. No-show and undo are both available, and both respect seat accounting — undoing a no-show does not conjure a seat that was already returned.

Back-office booking

Take a booking yourself for someone who phoned or walked up. It goes through the same engine as a web booking — same availability rules, same money maths — and is recorded with its channel so your reports separate phone, web and API sales.

Waiver

Where an excursion requires one, the participant's acceptance is captured with the booking, so the day sheet shows who has signed and who has not.

Waitlist & cancellations

With waitlist_enabled on, a full departure offers a waiting list instead of a dead end. When a seat is freed — a cancellation, an expired hold, a capacity increase — the first party in the queue is offered it and has waitlist_claim_hours to take it before the offer moves on.

Cancelling a booking runs the whole cascade in the right order: refund per your tiered cancellation policy, inventory returned, coupon slot released, waitlist promoted, customer notified. Departure viability can also close a departure automatically: if it has not reached min_viable passengers by its cutoff, the component cancels it and refunds its bookings rather than sending a guide out for two people.

Compliance exports

Participants is a per-person registry — name, age, document type and number, nationality, date of birth — and it exports as CSV with the columns Spanish traveller reporting expects (SES.Hospedajes / parte de viajeros). The file carries a UTF-8 marker so accented names open correctly in Excel.

Bookings exports separately, over a departure-date range, for accounting.

The export gives you the data in the required shape. Filing it with the authority remains your responsibility, and which fields are mandatory depends on your activity and region — check with your gestor before your first submission.

Portal (marketplace) mode

Set operating_mode = marketplace and your site becomes a portal: approved hosts manage their own listings from the front end, and you take a commission.

• Hosts — vendor records; publishing a host approves it. Optional KYC and self-registration.
• Pending listings — new host excursions arrive unpublished and are counted on the dashboard. Publishing an excursion approves it; set listing_auto_approve to skip the queue.
• Commission and payouts — a default commission per host, Stripe Connect splitting each payment, and a payout ledger you can mark paid or retry.
• Messages — host↔customer threads, with a moderation list for you.

Automation (scheduler)

GMC Tours installs a Joomla Scheduled Task plugin. Enable the task in System → Scheduled Tasks and give Joomla a real cron trigger — the lazy web-request scheduler is fine for a busy site and unreliable for a quiet one.

• Expire abandoned holds and return their seats
• Promote the waitlist when seats free up
• Send departure reminders and abandoned-checkout recovery
• Charge scheduled balances on deposit bookings
• Close departures that never became viable, refunding as configured

Reseller API & webhooks

Turn api_enabled on to expose a scoped REST API for resellers and partners: availability, quote and book. Keys are generated per partner and can be revoked; the key list shows the endpoints. Bookings made this way are stamped with the api channel so your reports can separate them.

Webhook subscriptions push booking events to your own systems, with a signing secret and a delivery log you can inspect and retry — so a failed delivery is visible rather than lost.

FAQ

• Can two people book the last seat at the same time?

  No. Seats are decremented inside a transaction when the hold is created, not when payment completes, so the second buyer sees the departure as full while the first is still paying. If that first customer never pays, the scheduler returns the seats and the waitlist is offered them.

• Do I need Stripe to use it?

  No. With payment_provider = none the component runs as an availability and enquiry system: quotes, holds, bookings and the whole operations side work, you simply collect money another way.

• The customer paid but the booking is still on hold. Why?

  Almost always the Stripe webhook. The return-to-site path is a convenience; the webhook is what confirms the booking. Check the endpoint URL and the signing secret in Options, and look at the attempt in your Stripe dashboard — Stripe will show you the failed delivery.

• Where did half the menu go?

  Interface mode is on Simple. Switch it to Advanced in Options to reveal resources, add-ons, options, gift cards, API keys, webhooks, payouts and the marketplace screens. Nothing was removed — Simple only hides screens a single operator rarely needs.

• Updates stopped being offered. What happened?

  Check your Download Key first. “Rebuild Update Sites” silently clears the keys of every extension on the site — it is the single most common cause. Paste the key back into System → Update → Update Sites and updates return.

• Does the licence gate my public pages?

  No. Your catalogue, excursion pages and existing bookings keep working regardless of licence state. The licence governs updates and the licensed admin features, and if the licensing gateway is unreachable the last known good answer stands rather than failing closed.

• Can I run tours and accommodation on the same site?

  Yes. GMC Tours and GMC Booking are separate products with separate tables and can coexist on one Joomla site; they share the same conventions and the same licensing gateway.