Payment evidence

The booking’s quoted amount describes the expected charge. The ride session carries the recorded fare. Payment evidence answers a different operating question: which authorization, capture, refund or void did the provider report for this booking, and has the evidence been verified? Booking Supervisor examines that trail before explaining payment status to the rest of the team.

Each event retains its provider event identifier, provider reference, amount and occurrence time. Those identifiers matter when a message arrives late or the same event is delivered again. Keep the event trace attached to the booking so Auditor can follow the amount back to its source without inferring payment from a completed ride.

• Provider evidence. Arrange the connection that brings payment events into the booking record. Preserve the provider’s event identity and distinguish Authorization, Capture, Refund and Void throughout reconciliation.
• Verification. Booking Supervisor examines unverified events against the provider evidence and linked booking. Define the authorized verification procedure before staff rely on an event to satisfy a deposit or completion-related check.
• Reporting. Auditor reads verified payment events by booking and event type. Retain separate totals for each type so a capture and its refund remain visible rather than disappearing inside an unexplained combined amount.

Choose the payment provider and agree how event identity, verification and retries will work. Decide which payment evidence is required before a Held booking can become Confirmed. A provider authorization may meet one operator’s deposit rule while another requires a capture; make the rule explicit and test it with the selected provider.

The booking quote, ride fare and payment evidence use USD amounts. Agree how your payment connection supplies those values when the organization’s configured currency differs. Keep that decision visible in implementation and reconciliation procedures so staff do not compare amounts that represent different monetary units.

Use a ride quoted at 12 USD. The provider first reports an authorization for that amount, then a capture for 10 USD after the actual ride. Booking Supervisor checks each event’s identity and verification state. The quoted amount remains useful context, while the capture evidence explains the provider’s reported collection.

Now send the same capture notification again. Rehearse the connection’s handling so it preserves the provider identity and does not count the same capture twice. Add a later refund event and confirm Auditor can inspect it separately from the capture. If a refund is still unverified, leave that uncertainty visible in the verification queue until the provider record supports a decision.

• Verified payment events — Provider events whose verification supports payment reconciliation, with event type and reference.
• Payment verification queue — Events still requiring evidence checks before the team relies on them.

Follow Reconciliation and payment, and agree the provider boundary in Integrations before the first operating cycle.