Connect enquiries, bookings and payments without losing the details

A website enquiry, a booking calendar and a payment gateway can all work individually while the business still struggles to connect the details. A customer pays, but the booking stays pending. A revised request reaches one person, but the team preparing the work sees an older version.

Reliable integration is about the handovers between those systems. Before connecting apps, decide which record is authoritative, what each event means and how an exception reaches a person who can resolve it.

Follow one request from start to finish

Write the ordinary journey in plain language. A hypothetical service booking might begin as an enquiry, become an agreed quote, reserve an appointment, receive a deposit and finally be marked complete.

Those are different events. Receiving a request does not necessarily mean accepting the work. Accepting a quote does not necessarily mean payment has cleared. A payment does not prove the service was delivered.

Give each stage an explicit meaning. The customer-facing messages and the staff view should agree on that meaning, so “confirmed” is not being used for three different things.

Start with a diagram on paper if that helps. The important result is a shared understanding of the journey, not a complicated diagramming tool.

Decide where the truth lives

Each important item needs a clear home: customer details, the current quote, appointment availability, payment references and the record of completed work. You can display the information in multiple places without letting every copy become an independent source of truth.

Assign a stable reference to the request or order and keep it through the connected workflow. An email address alone is not a reliable order reference: the same customer may have several bookings, and contact details can change.

When a specification changes, make it clear which version was approved. Keep enough history to explain a correction without leaving staff to piece it together from message timestamps.

Confirm payment on the server

A browser returning to a “thank you” page is useful for the customer's experience, but it is not sufficient evidence that money was received. The backend needs to verify the relevant transaction with the chosen gateway and match it to the correct order, amount and currency.

Gateway implementations differ. Stripe's webhook documentation, for example, describes signature verification and warns that notifications can arrive more than once or out of order. The practical lesson is to validate events and make repeated processing safe; a PayFast or Paystack integration must use that provider's own verification requirements rather than copy another provider's code.

Design the record so one successful transaction cannot accidentally confirm two unrelated bookings. Keep the gateway reference alongside the business reference, with a clear audit trail of the change.

Expect retries and duplicates

Customers double-click. Mobile connections drop. External services retry notifications when they do not receive a response. The system should handle those normal conditions without creating duplicate orders or sending the same instruction to the team several times.

Use a consistent way to recognise a previously processed action. A retry should produce the same intended result, not a second payment-linked booking. Do not solve this only by disabling a button; the backend must cope with repeated requests too.

If an external service is temporarily unavailable, preserve the work that has already been received. Queue or flag the next action, explain the state accurately and make the failure visible. Silently losing a handover is worse than showing a clearly labelled pending step.

Plan the exceptions before launch

Work through a few uncomfortable situations: a customer pays after an appointment slot expires, a deposit arrives for an amended quote, a cancellation happens while a notification is in transit, or a staff member corrects the wrong record.

Agree how each case is handled and who has authority to make the decision. The software can route the case and retain the evidence without pretending every business decision can be made automatically.

Refunds and changes should follow the business's agreed terms and the gateway's supported process. Avoid showing a completed refund simply because someone clicked a button; the system should distinguish a request from a confirmed outcome.

Keep access and notifications purposeful

Not everyone needs every detail. The person preparing a job might need the approved specification and appointment time without access to billing administration. A customer should only see their own relevant records.

Send notifications to the person responsible for the next step, not every person in the business. Include the reference, the action required and a safe link to the record. Avoid putting sensitive documents or unnecessary personal information in a broad email distribution.

Test the complete journey with clearly marked test data before switching to real customers. Include a duplicate event, a failed notification and a corrected booking—not just one successful checkout.

Measure what still needs attention

A useful operational view shows requests awaiting a decision, bookings awaiting verified payment and handovers that failed. It should help someone act, rather than only display impressive totals.

Reconcile business records with gateway records regularly, using the permissions and reporting appropriate to the business. An integration reduces manual copying; it does not remove the need to review exceptions.

The aim is a workflow the team can trust: clear records, verified transitions and an understandable route when something goes wrong.

Explore Avuno's payments and connected systems work, see how a marketplace brings different workflows together in MyQuack, or talk to us about a handover you want to improve.