Skip to documentation content

Troubleshooting

Recover booking and payment journeys

Repair a failed Book Now, Payment or Confirmation journey by reading server state and preserving exactly-once ledger behavior.

Use the sequence Book Now → Payment (when required) → verified provider return → Booking Confirmation. Start from the saved booking code and read server booking status, payment status, balance, transaction identity and confirmation access rather than trusting a browser message. The signed booking-access token is required for anonymous payment and confirmation links; a booking code alone is not authorization.

For Stripe, card fields and the client secret belong only on the dedicated Payment step. Confirmation reads verified transaction state and must not embed the Payment Element. For PayPal, follow the external approval and verified capture flow. For WooCommerce, check active checkout, currency, decimal precision, public permalink and strict order amount/currency matching. Pay at hotel has no online transaction and should retain a payable balance.

If a provider callback is pending, declined, duplicated or mismatched, do not manually mark the booking paid or replay an event without idempotency. The server verifies authenticity, amount and currency before an exactly-once ledger write. Payment does not implicitly confirm the booking, and payment events do not recalculate live tax rules. A retry should reconcile the existing transaction, not create a second one.

Redact secrets, card data, signed URLs and customer details. Escalate with the booking code, sanitized state transition and provider event class only.

Was this article helpful?

Your feedback helps us improve the documentation.