Skip to main content

Kaptio Experiences overview

Kaptio Experiences is trip-scoped selling of optional experiences and gratuities for escorted touring. Guests browse and buy optional excursions for the trip they have already booked; Tour Directors sell on tour, record cash, and manage availability from their phone; operations and finance teams run vouchers, refunds, settlement with an administration fee, finance export, and reporting from a desktop console.

Like every Edge product, it is driven by configuration, not code: one YAML file (optionals.yaml) and a tenant-owned UI source folder define the whole implementation. All examples in this section come from the Meridian Travel Co. reference implementation — the baseline your tenant is forked from. See How tenants work for the tenant model.

The three surfaces​

One deployment serves three role-scoped applications from the same tenant URL space:

SurfacePathWhoWhat they do
Guest/{tenantId}/guestBooked travelersOpen their emailed magic link or sign in with booking reference + surname (no registration either way), browse the trip's optional experiences with live availability, buy with card or voucher, pay gratuities, split payments across the party, see their itinerary and order history
Tour Director/{tenantId}/tdOn-tour staffReal-time sales dashboard per trip, assisted booking on behalf of guests, cash and card recording, refunds, availability management, goodwill vouchers, own settlement transparency, plus trip operations: schedule, guest manifest, suppliers, documents, expenses
Operations & Finance/{tenantId}/adminBack officeTrip oversight and Tour Director substitution, availability overrides, the on-request queue, voucher management, refunds, settlement runs with the administration fee, batch export to the finance system, hold/release control, reporting, and the full audit trail

Every surface consumes the same versioned REST API — /api/optionals/v1 — documented in the API reference. There is no capability in the UI that is not available as an API.

What a sale looks like​

  1. A guest opens their magic link or signs in with their booking. Either way, identity resolves against the booking records synced from your Salesforce org — guests known to the platform never re-register.
  2. They browse the trip's catalog. Products come from your product content platform (or the seed catalog during evaluation). Each item carries live availability: remaining allotment, sales cut-off derived from the supplier's cut-off hours, and the configured sold-out policy.
  3. They order and pay. Orders can mix optional experiences and gratuities (Tour Director or driver). Payment is card, voucher, or — recorded by the Tour Director — cash. Split payments let different party members pay their share.
  4. The Tour Director sees it immediately. The trip dashboard shows per-guest purchases, per-product sold counts for supplier reservations, and running totals by payment method.
  5. Finance settles. A settlement run groups completed transactions per Tour Director per currency, deducts the configured administration fee, and produces a batch export for your accounts-payable system with invoices loaded on hold. Finance releases them for payment from the console.

Every action along the way — logins, orders, payments, refunds, availability changes, settlement actions — lands in the audit trail with actor and timestamp.

Multi-brand by design​

A tenant configures one or more brands, each with its own logo, color theme, and typography. The brand is resolved from the trip, so a guest on one brand's departure sees that brand's identity end to end while operations and finance work across all brands in one console. See Configuration.

How it runs on the Edge Platform​

Kaptio Experiences follows the same architecture pattern as Edge Journeys:

  • Tenant configuration lives in your config repository as optionals/optionals.yaml, validated against a published schema. Changes go live on merge — no deployment.
  • The tenant UI is source you own. React components in optionals/src/ are bundled server-side at runtime and served to your users. Rebranding or restructuring a screen is a config-repo merge request.
  • Providers separate reference data from transactions. A mock provider ships a complete seeded world for evaluation and training; the live provider connects trips and guests to your Salesforce org and products to your content platform. Orders, payments, vouchers, settlements, and audit events are transactional data in the platform's PostgreSQL store in both modes.
  • Payments route through Edge Pay in live mode — the same PCI-certified gateway path documented in Edge Pay. Evaluation tenants use a clearly-labelled simulated gateway with deterministic test cards, switchable to the live path with one configuration value.

See Integration architecture for the full system landscape.

Where to go next​