A customer pays for an eligible service and receives two references: one from the wallet and one from the booking system. Trouble begins when either business can see only its own reference. For a utility ecosystem such as ALFA, the connection between those records deserves as much attention as the payment screen.
Give the purchase a common identity
The service order should exist before payment begins. It can hold the provider, selected service, agreed amount and customer instruction without exposing those details publicly. The transaction reference then attaches to that order. Support can establish what the payment was intended to purchase rather than asking a customer to reconstruct the conversation from screenshots.
Separate payment from reservation
A received transfer does not necessarily secure a particular appointment or training slot. Availability might change while funding completes. An integration needs a reservation window and a clear action when it closes. Holding capacity indefinitely wastes resources; accepting payment after capacity disappears creates an avoidable recovery exercise for both the operator and the customer.
Reconcile at the service boundary
At the end of a working day, the provider should be able to compare paid orders with confirmed bookings and completed services. Unmatched items belong in a small exception queue with an owner. A dashboard showing aggregate token activity would conceal the individual booking that still requires action, especially across several participating businesses.
Make the evidence portable
A useful receipt brings the service description, provider reference and payment reference together in an export the customer can retain. It should identify whom to contact about delivery. This is a practical design consideration for ALFA utility: the strongest evidence of use is a fulfilled order that remains understandable after the browser closes.
