Integrations and source ownership

• Card terminal and payment provider. Match card and online payment confirmations to pending charges by a stable payment reference, then mark them Confirmed. Refunds follow the provider’s own process.
• Online booking page. Send member booking requests into the booking queue as Requested, so the front desk confirms them against plan and capacity.
• Email and SMS messaging. Send booking confirmations, class cancellations and plan renewal reminders from the studio’s messaging service.
• Accounting software. Export confirmed receipts and refunds by day for reconciliation and bookkeeping.
• Identity provider. Map staff sign-in to their user and People record; removing a leaver’s access must also remove their app access.

Each connection needs an agreed source of truth, a field mapping, a stable event identifier and a retry policy. A repeated payment notification must not confirm the same charge twice, and a repeated booking request must not reserve a second place. Keep credentials in the approved secret store and grant the smallest scope the connection needs. Queue rejected records with their source identifier and a visible reason.

Test a provider timeout, a duplicate notification and a revoked credential before turning on schedules. Availability depends on each provider’s API, commercial access and configuration.

Use the implementation plan to agree acceptance criteria for each connection.