Payments & commerce
Payment providers, terminals and point-of-sale systems connect to transaction and visit state.
THE PROVIDER ECOSYSTEM
Your operating model.
Your choice of providers.
Keep specialist systems doing what they do best. COPA connects them to the guest, the visit and the venue around them.
copa /
The guest. The visit. The venue.
The operating model stays connected.
Activities & gameplay
Activity systems connect sessions, equipment and gameplay to the experience around them.
Identity & communication
Digital credentials, wallets, messaging and push connect recognition with relevant communication.
Physical systems
Devices, displays, printers and environment systems become part of venue operations.
Accounting & reconciliation
Financial records and provider reconciliation support the operational picture.
Voice & intelligence
Speech and reasoning providers work through COPA’s context, permissions and capabilities.
WHAT EXISTS. WHAT NEEDS SETUP.
Know what you’re buying into.
This is a scope guide based on the current implementation. It is not a promise that every connection is active, certified or ready for every venue. Your proposal should name the exact workflows being delivered.
| System | Current scope | For your rollout |
|---|---|---|
| COPA coreBring the work together | Booking, guest and membership records, tabs, staff workflows and venue oversight exist in the product. | Agree which modules replace your current tools. Validate your pricing, permissions, service rules and exceptions before switching. |
| Stripe & terminalsConnection implemented | Payment, webhook and terminal workflows are implemented around bookings and commerce. | Configure the venue’s account and terminal location, confirm reader compatibility, and test charges, refunds and reconciliation. Existing payment credentials are not assumed transferable. |
| Toast & SquareWorkflow-specific adapters | Toast menu sync and order webhooks, plus a Square order webhook, are present. That is specific workflow support—not universal POS parity. | Confirm provider access, order direction, menu mapping, modifiers, refunds and which system owns each record. Unsupported functions need separate scope. |
| GSPro, FSX Play & DartseeActivity-specific connections | Bay OS includes simulator integrations and Dartsee connection code. Activity support is specific to the software and hardware involved. | Inventory installed versions and devices. Validate launch, session identity, results and recovery on site. GSPro player seeding is not supported by the current integration contract. |
| Accounting & payrollExports plus staged integration | Payroll CSV export and QuickBooks summary/posting code exist. Full accounting automation requires deployment-specific validation. | Agree account mapping, approval and reconciliation with your finance team. Live sync, payroll push and migration of historical balances require explicit validation and scope. |
| RockbotAdapter; activation required | The music adapter defaults to a test mode until live credentials and provider approval are available. | Confirm approved access, music zones and physical players, then validate commands and observed state before enabling the connection. |
Don’t see a provider? Bring its name, version and the jobs you need it to perform. We’ll identify an existing connection, a replacement workflow or additional integration work.
THE IMPLEMENTATION CONVERSATION
A rollout your team can actually operate.
A new venue system changes how the business works. These are the decisions and deliverables to agree before launch—not an automatic migration or a fixed-time promise.
Map the operation
You bring the tools, contracts and real exceptions. Together we decide what moves into COPA, what stays connected and what is outside the first release.
Output: a workflow and integration scope with clear ownership.Plan the data move
Inventory guests, active memberships, credits, future bookings, menus and open financial obligations. Confirm export access, field mapping, consent requirements and reconciliation before importing anything.
Output: a migration plan, sample import and agreed totals to verify. Historical records and stored payment methods are assessed separately.Configure your brand & venue
Define your domains, guest identity, email, wallet and app requirements alongside activities, hours, prices and permissions. A different brand or legal entity needs its own deployment design.
Output: an agreed brand and configuration plan; no assumption of instant self-service rebranding.Validate the physical setup
Inventory activity PCs, kiosks, displays, terminals, printers and the venue network. Pair devices to the correct spaces and test the supported equipment together.
Output: a hardware compatibility list and on-site acceptance checks. Existing hardware is retained only where validated.Rehearse the shift
Train managers and frontline staff on the workflows in scope: arrival, orders, extensions, refunds, device interruptions and end-of-day checks. Practice exceptions as well as the happy path.
Output: role-based training, named escalation contacts and a go-live checklist.Launch with a support plan
Agree a cutover window, fallback plan and acceptance criteria. Define who owns software, payment-provider and hardware incidents, plus support hours and escalation expectations.
Output: a signed-off launch plan. Timeline, implementation fees and ongoing support terms are set in the proposal.How long does implementation take?
There is no standard timeline published yet. The number of integrations, data quality, hardware readiness, brand requirements and training scope determine the schedule. Agree milestones and dependencies before setting a launch date.
Can we move everything from our old system?
That depends on export access, data structure and the records involved. Future bookings, unused credits and open balances need explicit reconciliation. Payment tokens, membership billing and historical transactions are separate migration questions, not guaranteed imports.
What support is included?
Support coverage, response expectations, training and the division of responsibility between COPA and third-party providers are agreed in the commercial scope. This site does not promise a 24/7 service or a standard SLA.
Can we launch under a completely different brand?
That is the goal of a scoped brand deployment. Current location onboarding was built for venues within the original brand. Separate customer brands and legal entities need additional identity, tenancy and deployment work agreed before rollout.
CONSOLIDATE THE WORK. CONNECT THE SPECIALISTS.
One system doesn’t mean one supplier.
The goal is a joined-up operation. Decide which tools no longer need to be separate and which providers bring something valuable to your venue.
BRING INTO COPA
The work that belongs together.
Bookings, membership, guest records, tabs, staff workflows, community and venue oversight can share the same operating model instead of being managed as separate islands.
CONNECT AROUND IT
The specialists you choose.
Payment processors, activity engines, messaging services and physical equipment remain specialist systems. COPA connects supported capabilities to the visit and the operation.
START WITH YOUR OPERATION
Bring your stack. We’ll map the fit.
Integration support is specific: the provider, the workflow and the hardware all matter. We’ll confirm supported functions and deployment requirements with you.
Changing a provider can still require migration and validation. The goal is a consistent operating model through those changes.
Discuss your venueTHE SYSTEM BEHIND THE EXPERIENCE