Connecting FPS or another e-payment method to a booking system is less about the payment button and more about agreeing how money, bookings and records stay consistent. The decisions below are practical and general. Exact requirements depend on your payment provider, bank or acquirer, so confirm them with the provider you choose.
Who owns the payment flow
A booking that involves payment passes through four steps: order, charge, refund and receipt. For each step, name an owner and a source of truth.
- Order: the booking system decides what is being sold, for which slot, and at what price.
- Charge: the payment provider confirms whether money was actually received. The booking should not be marked as paid just because a customer returned to your site.
- Refund: decide who may start a refund, who approves it, and whether it is made through the provider or handled outside the system.
- Receipt: decide which system issues the receipt, what it shows, and how it is re-sent.
Also decide what happens to a held slot while payment is pending, and how long it is held before it is released.
Reconciliation and exceptions
Normal payments are easy. The design effort goes into exceptions, so agree on how each of these is detected and resolved:
- Duplicate charge: a customer pays twice, or a payment confirmation arrives more than once. Use a unique reference per order and make the confirmation handling safe to repeat.
- Timeout or unknown result: the customer paid but your system never received confirmation, or the reverse. Define a status such as “pending” and a check that queries the provider before the booking is released or cancelled.
- Partial refund: a customer cancels one of several bookings in the same order. Make sure the refund amount, booking status and receipt all stay in step.
Plan a regular reconciliation that compares bookings against provider reports and settlement records, with a clear owner for unmatched items. Webhooks can report payment events quickly, but delivery is not guaranteed, so a scheduled check is still useful.
Permissions and audit of transaction data
Payment data should be visible only to people who need it. Define roles for front-desk staff, finance and administrators, and decide who can view, export or refund. Keep an audit trail of who changed a booking, refund or price and when. Avoid storing more payment data than your provider’s integration requires, and keep secrets such as API keys out of code and shared documents.
Integrating with membership, ERP and access control without rewriting
Most venues already have a membership list, accounting software or an access control system. A rewrite is rarely needed. Treat the booking system as one part of a chain, and connect the others through APIs or scheduled exports where available:
- Membership: decide whether member status and discounts are read from the existing list or copied into the booking system.
- ERP or accounting: agree on which fields, such as order reference, amount and payment date, are sent and how often.
- Access control: grant entry only after a booking is confirmed as paid, and revoke it when a booking is cancelled or refunded.
See what system integration is and technine.io’s system integration and automation service for more background.
Go-live checklist
- Test merchant account and staging environment set up and separate from production
- Test cases for successful payment, failure, cancellation, timeout, duplicate and partial refund
- Receipts, notifications and reports checked with real-looking data
- Roles, permissions and audit logs reviewed
- Reconciliation process and exception owner agreed
- Cutover plan: timing, who is on standby, how in-flight bookings are handled and how to roll back
- Support contacts at the provider and an internal escalation route
Frequently asked questions
Do we have to rebuild our booking system to accept FPS or e-payment?
Not necessarily. Many existing systems can be extended by adding a payment step and connecting it to current records. The effort depends on how the current system stores bookings and how clearly its workflow is defined.
Who should confirm the technical and compliance requirements?
Your payment provider, bank or acquirer, and your own finance or legal advisers. This article does not replace their guidance.
Should a booking be confirmed before or after payment?
It depends on the business. Many venues hold the slot for a short time and confirm it once payment is received. Whatever you choose, define the hold period and the release rule in advance.