If a student paid but no booking appears, do not ask them to pay again and do not create an appointment from the bank screenshot alone. Trace the payment and the appointment as separate records. First prove the provider’s current payment status. Then search for the booking in every relevant status. Only after both checks should staff recover one booking from the existing payment, offer another time, preserve the paid value for later scheduling, or start the school’s approved refund process.
The immediate goal is not to make the calendar look right. It is to reach one explainable result: one payment connected to one order, and either one valid booking or one documented unresolved value.
Open one incident record before changing anything
Give the case one internal reference and collect facts in one place. This prevents two staff members from separately charging, booking, crediting or refunding the same purchase.
| Field | What staff should record |
|---|---|
| Customer report | Time, email or phone used, amount shown, requested service, requested date and pickup |
| Payment evidence | Provider, PaymentIntent or equivalent payment ID, charge ID if present, amount, currency and current provider status |
| School records | Cart/session ID, order ID, transaction ID, appointment IDs and any entitlement created |
| Requested booking | Exact service, duration, instructor preference, pickup, start time and branch |
| Recovery state | Investigating, waiting for payment status, booking recovered, value held for scheduling, alternate offered or refund started |
| Ownership | Staff owner, next action, deadline and final outcome |
Use provider and school IDs, not card details. Stripe recommends associating an order ID with a PaymentIntent for reconciliation and warns against putting sensitive information in payment metadata. Its documentation also says one PaymentIntent typically corresponds to one cart or customer session. See Stripe’s Payment Intents guidance.
Check what “paid” means at the payment provider
A bank notification or a pending line on a statement does not tell the office which state the payment provider has recorded. Open the payment in the provider dashboard or retrieve the object through the school’s authorized system.
For Stripe PaymentIntents, the current lifecycle includes states such as requires_payment_method, requires_action, processing, requires_capture, succeeded and canceled. Stripe says an asynchronous payment can remain in processing for days, while succeeded means the payment flow is complete and the order can be fulfilled. Review the current PaymentIntent lifecycle.
Record the actual status and its checked time. Do not turn processing into “paid,” or succeeded into “booked.” The first is a provider payment state. The second would be a school appointment state.
Search for the appointment before rebuilding it
The booking may exist but be hidden from the normal calendar view. Search by customer, requested time, order, payment reference and creation time. Include pending, abandoned, canceled, failed, rescheduled and duplicate records—not only confirmed appointments.
Then inspect the connected records:
- Did an order or transaction save even though the appointment did not?
- Did an appointment save without its payment or order relationship?
- Did a package unit or other entitlement get issued?
- Did a retry create a second order, transaction or appointment?
- Did the requested slot become unavailable before booking creation finished?
Do not “fix” the case by typing a free-standing credit into the student profile. Preserve the original payment and order references so the result can be reconciled later. The RouteOS guide to preserving payment, order and appointment relationships explains why matching totals without those links is not enough.
Use the payment-and-booking recovery matrix
| Verified payment state | Booking state | Office action |
|---|---|---|
| Not successful or still processing | No booking | Do not create a paid booking yet. Mark the case unresolved, monitor the authoritative provider state and tell the student when the school will check again. |
| Succeeded | One valid booking exists | Reconnect or surface the existing records. Send one accurate confirmation; do not create another appointment. |
| Succeeded | No booking; original slot still deliverable | Use the existing payment and order reference to complete one guarded booking. Recheck student, instructor, vehicle, pickup, travel, buffers and conflicts before committing. |
| Succeeded | No booking; original slot no longer deliverable | Do not force the old time into the calendar. Follow the school’s disclosed terms and approved process: offer a valid alternative, preserve the purchased value for later scheduling, or begin the appropriate refund path. |
| Unknown or conflicting | Any state | Hold further automated action. Assign an owner to reconcile the provider event, school transaction, order and booking before money or capacity changes again. |
The table is an operating pattern, not a universal refund policy or accounting rule. The school’s written terms, payment method and approved financial process control which remedies are available.
Recover the booking once, even when the request repeats
A slow page, double tap or retried provider event can repeat the same request. The recovery operation needs a stable key tied to this incident and intended result. If that key already produced a booking, return the recorded outcome rather than creating another one.
Stripe’s idempotency documentation describes this safeguard for API writes: repeating the same request with the same key returns the first result instead of performing the operation twice. Stripe also warns that webhook events can be delivered more than once and recommends recording processed event IDs. See its webhook duplicate-handling guidance.
Idempotency does not prove the slot is still usable. Before the one booking commits, repeat the current availability and entitlement checks. The separate guide to locking lesson credits and capacity together explains the same principle when two actions compete for finite lesson value or time.
Close the incident with four linked facts
A completed case should let another staff member see:
- the final provider payment state and payment reference;
- the order or purchased entitlement created from that payment;
- the booking, alternate arrangement or refund action that resolved the value; and
- the actor, time and reason for every manual correction.
If a refund is chosen, connect it to the original payment and the affected order rather than deleting the payment record. Stripe documents separate cancellation and refund paths depending on payment status; after a PaymentIntent succeeds, a refund can be issued against the PaymentIntent or its underlying charge. See Stripe’s refund documentation. This article does not decide whether the school owes a refund in a particular case.
Test this failure before relying on checkout
In a test environment, cause payment confirmation to finish while booking creation fails. Then verify that:
- the customer is not prompted to pay again;
- one case contains the provider, order and appointment references;
- a repeated recovery request cannot create a second booking;
- the original slot is rechecked rather than assumed available;
- staff can choose only an approved recovery outcome; and
- the customer receives one clear final message.
RouteOS Task Operations is designed to give administrative requests an owner, deadline and visible outcome. RouteOS publishes this guide and sells driving-school software, so treat that as a disclosed product perspective. The September 2, 2026 code review found relevant order, transaction, appointment, entitlement, reconciliation and idempotency controls in the inspected source, but source presence does not prove a specific school has a payment-recovery workflow enabled or configured. Ask RouteOS—or any vendor—to demonstrate the exact failed-booking test above.
Research reviewed September 14, 2026. Technical claims were checked against current Stripe documentation and the supplied RouteOS implementation report. No real student, transaction or failed booking was used in the example.