Run ticketing and check-in as
one live ferry operation.
Ferry On shows how sales, subscriptions, check-ins, identity, payment and staff actions can share one governed event stream instead of becoming separate applications and integrations.
Reference pattern. Customer outcomes and production performance require project-specific verification before publication.
The business operation
The passenger journey and the operational record stay current together.
Each interaction changes the state used by the next one. Staff should not have to reconcile yesterday's export before deciding what may happen now.
Sell
Create a ticket or subscription under the active fare, identity and payment conditions.
Check in
Validate the travel right against the current service, time, vessel and passenger context.
Operate
Give authorised staff the live state and permitted actions required at the point of service.
Prove
Retain the relevant event, rule version, decision and outcome for support, reconciliation and audit.
One stream configuration
The whole operation can be described in one inspectable contract.
The configuration expresses what must remain stable even when a payment provider, scanner, database, interface or identity service changes.
Ticket sale, check-in scan, subscription change or staff action
Passenger, product, journey, vessel and payment fields
Schedule, capacity, identity, entitlement and prior events
Fare, validity, access, exception and permitted staff action
Accept, reject, notify, charge, correct or escalate
Input, context, rule version, actor and operational result
Hot-swappable services
Change a provider behind the contract.
Payment, identity, scanning and delivery services can be replaced where their contracts and applicable rules permit. The switch is validated and versioned; it is not an invisible runtime shortcut.
Responsibility remains explicit
- The operator controls fares, service policy and staff authority.
- Regulated providers keep responsibility for their payment, identity or trust service.
- Datastreams executes and services the agreed runtime boundary.
- Every implementation validates throughput, availability and recovery requirements.
Use the pattern for any operation where entitlement meets a live service.
Map one journey, transaction or access event with its context, rules, actors and evidence before choosing the surrounding products.
Map the operation