How Skedular Handles Failed Bookings and Refunds Reliably

What happens when a booking cannot be completed

The current public booking form performs a live availability check, but that check happens before the final write. Availability can change in the meantime. The platform is implementing a final server-side allocation step that checks and claims the requested capacity as one operation. This is usually called atomic allocation: the availability decision and the reservation happen together, so another request cannot slip into the gap between them.

When that final step fails, the target behavior is a classified result rather than a generic error. The reason might be an unavailable date, an unsuitable requested resource, or a failure to complete the operation. The result remains available in the application, and if payment has already been captured it becomes the starting point for the refund workflow.

• Check and claim availability at the final point of booking commitment.
• Keep a durable failure record with the reason, time, booking context, and related events.
• Show the result in booking history and details, not only in a temporary form message.
• Offer a clear recovery path, such as choosing another time or returning to the listing.

Recording failed booking attempts

A customer, host, and organization administrator do not need the same message, but they do need the same truth. A customer should know whether no booking was created, whether only some recurring dates were created, and whether any payment is being returned. An owner should know which place or resource needs attention. A host should not discover a failed customer experience by accident.

A durable failure record means the outcome survives a page refresh, a workflow retry, and an operator handoff. A temporary message or email is not the system of record. The application history must remain the place where someone can confirm whether a booking was created, what happened to the payment, and what action is still open.

Booking failure notifications for customers, hosts, and operators

The notification design ties each message to the recorded availability outcome. Customers need to know whether no booking was created or whether a series changed. Hosts and organization owners or administrators need the affected location, product, resource, and dates so they can act. Notifications are delivered in the background. If delivery needs to be retried, the same recipient should not receive the message twice. Internally, this is handled through idempotency controls.

Handling partial recurring bookings

Consider a customer booking a meeting room every Tuesday for twelve weeks. Eleven dates are available, but one date becomes unavailable before the series is saved. Payment may already have been authorized or captured. The system needs to identify the unavailable occurrence, retain the result, and show the customer which dates were created and which were not.

The confirmed product rule is a 24-hour decision window. During that window, the created occurrences are held while the customer reviews the changed series. If the customer accepts, the unused portion is refunded. If the customer rejects the series or does not respond, the created occurrences are cancelled and the full payment is refunded. The operator receives the same outcome and can see the related payment and refund state.

How the customer accepts or rejects a partial series

This decision window exists for a practical reason. The customer needs time to decide whether eleven Tuesdays still work, while the operator cannot leave capacity reserved indefinitely. The application should show the successful dates, the unavailable date, the proposed partial refund, and the deadline for a decision in one place.

The partial outcome is not calculated from a guess about the subscription root. It is linked to the billed recurring booking and the occurrences that could not be created. That keeps the amount tied to the actual payment and booking scope.

A cancelled booking is not the same as a completed refund

Cancellation ends the booking or future entitlement. Refund completion means the money has been returned or the relevant manual payment has been confirmed. Those events can happen at different times and must remain separate in the customer view.

The customer should not have to guess whether the money has actually been returned. A refund approved for processing is not a completed refund, and a provider timeout should not be treated as either success or failure until the provider result is checked.

The refund lifecycle

How refund amounts are calculated

The refund calculation uses the cancellation policy saved when the customer purchased the booking. A later policy change must not alter the original agreement.

The calculation records the original payment, eligible amount, deductions, taxes, previous refunds, and final refundable amount. Financial calculations must preserve exact currency values and avoid floating-point rounding errors.

For every refund, the platform must first identify which billed booking owns the payment. This may be a one-time booking, a billed recurring booking, or a billed subscription cycle. Skedular uses that record as the single source of truth for the refund, internally referred to as the canonical billed owner. The same record is then used for the payment status, cancellation policy, refund calculation, payment allocation, and audit history.

Payment allocations connect each refund to the captured payment that funded the booking. This prevents completed and pending refunds from exceeding the amount actually paid.

Handling Stripe, Xero, and bank-transfer refunds

The refund workflow depends on how the customer originally paid. Stripe, Xero, and bank transfers each require different evidence before a refund can be considered complete.

Stripe refunds

The refund must use the original account, charge, and payment context. A post-payout refund may require a transfer reversal or another funding path. Stripe webhooks can update status, but duplicate events must be safe to process.

Xero credit notes and customer refunds

A Xero credit note is an accounting record against an invoice. It does not by itself prove that money has returned to the customer. The accounting state and the customer-money outcome therefore need separate handling and reconciliation.

Bank-transfer refunds

An authorized operator must approve and record the manual payment. The record should include who completed it, when it happened, and the payment reference. It should not be marked complete until that action is confirmed.

Refund retries, idempotency, and reconciliation

Networks fail. Webhooks are delivered more than once. A worker can time out immediately after a provider accepts a request. Every refund therefore carries a stable idempotency key, which is a unique reference that prevents the same financial operation from being submitted twice.

Provider operations use bounded retry behavior and preserve that same key. Reconciliation means comparing Skedular's refund record with the provider record to resolve missing, delayed, or contradictory results. Stripe can usually update the refund status through webhooks shortly after the provider responds. Xero and bank-transfer refunds may require scheduled checks or manual confirmation.

When human review is required

Sometimes the payment provider's response is unclear. In that situation, the system should stop and request human review. The same applies when a bank-transfer refund needs confirmation, a provider record cannot be matched, or local and external states disagree. When an operator begins reviewing a refund, the record should be temporarily assigned to them so another operator does not work on the same case at the same time. The reviewer should have the complete booking, payment, provider, and audit context before making a decision.

The target workflow is deliberately conservative: unresolved financial outcomes enter reconciliation or an operational review queue instead of being silently marked complete.

The booking and refund process

The intended end-to-end flow is:

1. Check and claim the requested availability.
2. Record whether the booking succeeded, partially succeeded, or failed.
3. Notify the relevant customer, host, or organization administrator.
4. Determine whether payment must be fully or partially returned.
5. Calculate the refundable amount using the original purchase terms.
6. Submit the refund through the correct payment provider.
7. Track the provider result until completion.
8. Send unresolved outcomes for reconciliation or human review.

What this means for customers

Customers should be able to:

• Know whether the booking was created.
• See which recurring dates succeeded or failed.
• Understand how much is being refunded.
• See the current refund status.
• Know whether any action is required.
• Find the result in the application even if an email is delayed.

What this means for hosts and workspace operators

Hosts and operators should be able to:

• See a durable record of the failure.
• Identify the affected location, product, resource, and dates.
• Understand the payment and refund state.
• Avoid duplicate refund attempts.
• Review unresolved provider outcomes.
• See an audit history of important actions.

Frequently asked questions

These are the questions customers and operators are most likely to ask when a booking or refund does not follow the usual path.