Integration architecture

Kaptio Experiences is a product on the Kaptio Edge Platform — the same production platform that operates Edge Docs, Edge Pay, and Edge Journeys today. Every integration below follows a pattern already running in production for other Edge products, and each one is expressed as tenant configuration, not custom code.

Two kinds of data meet in the product:

• Reference data — trips, guests, brands, and the experiences catalog — comes from a provider. The mock provider serves a complete seeded world for evaluation; the live provider connects your real systems. The shape of this data is specified in Data contracts.
• Transactional data — orders, payments, vouchers, settlements, and audit events — lives in the platform's PostgreSQL store in both modes. Switching a tenant from evaluation to live changes where reference data comes from; it never migrates transactions.

Two integration models

Both models are first-class; the individual contracts on this page apply in either — the model only changes who calls whom.

Model	How it works	When to choose it
Integration-platform counterparty	Your integration platform (iPaaS, for example Informatica IICS) is the single counterparty: it pushes product content, pricing, trips, guests, and Tour Director assignments to an inbound Experiences endpoint as changes occur, and receives sales, payment, and settlement data from an outbound feed, routing it into Salesforce and your finance system. You own orchestration, transformation, and routing; Experiences exposes one versioned, typed contract.	You run a central integration platform and want one well-defined counterparty instead of several vendor-side connections.
Direct integrations	Experiences connects to each source directly: the product content feed, Salesforce through the Edge Admin Backend's centralized OAuth, and batch or API delivery to your finance system — each detailed in the sections below.	You want the platform to carry the integration load, or as the supported fallback while integration-platform endpoints are being built.

The formal interface contract for either model — payload schemas, event triggers, environments, token issuance, rate limits — is agreed and signed off in implementation workshops before build. Teams commonly start milestone work against mocks and swap in the real endpoints as they land.

Product content and pricing

Aspect	Design
Direction	Content platform → Experiences (read-only)
Data	Titles, descriptions, imagery, pricing, booking notes, supplier cut-offs, and trip applicability
Transport	HTTPS feed; the API key is held in the platform vault and referenced as vault:: from configuration
Frequency	live (short-TTL cache, near-real-time price changes) or daily_overnight batch
Pricing rule	The platform holds no independent pricing layer — you control pricing at the source, and changes flow through automatically

Whatever system is your source of truth for experience content keeps that role. The feed contract is agreed during implementation workshops and mirrors your platform's export capability.

Salesforce — trips, guests, writeback

Aspect	Design
Direction	Bidirectional
Transport	The Edge Admin Backend's centralized OAuth to your Salesforce org — encrypted token vault, org-id-based tenant resolution, no credentials in this service. This is the exact mechanism Edge Docs and Edge Pay use in production.
Guest recognition	Booking reference + surname are matched against your booking records — guests known via Salesforce never re-register
Writeback	Confirmed purchases, refunds, and gratuities post back to the trip/booking record, so downstream reporting sees optional sales alongside the core booking
Substitution	Admin-driven Tour Director reassignment updates the trip record; historical sales remain attributed to the outgoing Tour Director for settlement

Payments — Edge Pay

Aspect	Design
Card processing	The Edge Pay path: payment session → Kaptio Pay → the PCI-certified gateway. PCI DSS compliance sits with the certified gateway; card data never touches Experiences servers.
Evaluation mode	A clearly-labelled simulated gateway with an identical interface and deterministic test cards. Going live is one configuration value: payment.gateway: edge_pay.
Currencies	Trip-currency display and collection. Additional currencies are additional gateway merchant accounts, not code changes. Currency conversion on foreign cards is the card issuer's concern.
Transaction types	Purchase, refund (linked to the original transaction), and chargeback/dispute ingestion via gateway webhooks
Cash	Recorded by the Tour Director against guest, booking, trip, and product — a first-class transaction feeding settlement and reconciliation, not a side note

Finance system — settlement export

Aspect	Design
Direction	Experiences → your accounts-payable system
Invoice model	One AP invoice per Tour Director per period: gross settled as item lines, the administration fee as a credit line, net payable per Tour Director
Hold and release	Every exported invoice is flagged to load on hold. Release is a separate, explicit finance action in the console — export requests the hold, release lifts it, and both are audited.
Transport	Overnight batch (scheduled file delivery) or API, co-designed with your finance team during implementation
System of record	Your finance system keeps payment run generation and disbursement; GL coding and cost-centre mapping are unchanged
Reconciliation	Transaction-level detail is retained and queryable per settlement — see the reconciliation report

The in-app lifecycle only claims what the platform actually observes: draft → exported (hold requested) → released. Payment status inside your AP system stays downstream.

Identity

Persona	Evaluation	Live
Guest	Booking reference + surname, short-lived signed session token	Same, plus an emailed magic link that opens the trip-scoped session directly — guests never register
Tour Director	Code + PIN	Keycloak OIDC with MFA, federated to your corporate identity provider (e.g. Microsoft Entra ID)
Operations & Finance	Email + password	Keycloak OIDC with MFA, federated to your corporate identity provider (e.g. Microsoft Entra ID)
Programmatic consumers	—	OAuth 2.0 client credentials, TLS 1.2+, REST/JSON

See the platform security model for tenant isolation, encryption, and token handling shared by every Edge product.

Connectivity

All three surfaces are responsive web applications: sales, payments, and availability are processed server-side in real time, so the apps require network connectivity at the point of sale. Offline capture — for example a native Tour Director app that records sales locally and syncs when connectivity returns — is not part of the current product and is scoped per implementation when touring conditions call for it.