The Activity timeline on a booking (and the Transactions list on an order) shows every charge and pre-authorization that was attempted, not just the ones that succeeded. Rows labelled Payment attempt or Pre-auth attempt never moved any money -- they exist so you can see that a charge was tried, and why it did not complete.
This page explains each status you may see on those rows.
Card declined
Status pill: Failed
The customer's bank rejected the charge. No funds were captured and nothing needs to be refunded. When the bank provides a reason, it is shown on the row, for example:
- Insufficient funds -- the account did not have enough available balance. Ask the customer for another card, or retry later.
- Do not honor / generic decline -- the bank refused without a specific reason. This is the most common decline; it usually means the customer needs to call their bank or use a different card.
- Expired card -- the saved card is out of date. Collect a new card.
- Incorrect CVC / incorrect number -- the card details were mistyped. Re-enter the card.
- Card not supported -- the card type cannot make this kind of purchase (some prepaid or corporate cards).
- Lost or stolen card -- the bank has blocked the card. Never retry these; ask for another payment method.
What to do: retry with the same card only if the reason suggests a temporary issue (insufficient funds), otherwise collect a different payment method. Every attempt stays visible in the timeline, so a declined-then-retried charge will show one failed attempt and one successful payment.
Action required
Status pill: Action required
The card's bank requires 3-D Secure verification (the "confirm this purchase in your banking app" step). Only the cardholder can complete that challenge -- staff cannot do it from the dashboard, so a staff-initiated charge or pre-auth against a card that demands 3-D Secure stops here.
What to do:
- Have the customer pay or authorize the booking themselves through their booking link or the online checkout, where they can complete the verification.
- Or use a different card that does not require the challenge.
- Terminal (chip/tap) payments authenticate the cardholder physically, so running the card in person also works.
The attempt expires on Stripe's side after a while; it never turns into a charge unless the customer completes the verification.
Awaiting confirmation
Status pill: Awaiting confirmation
A payment was set up but never confirmed -- typically an online checkout the customer abandoned before the final "Pay" step, or an interrupted payment flow. No money moved and no action is usually needed; treat it as an abandoned attempt.
What to do: nothing, unless the customer reports they did try to pay -- in that case take the payment again through the normal flow.
Processing
Status pill: Processing
The payment is in flight with the bank. Most card payments settle in seconds, but some methods (and some bank-redirect payments) can stay in processing for longer. The row updates to Succeeded or Failed on its own.
What to do: wait before retrying. Charging again while a payment is processing risks a double charge.
Pre-auth attempts
A Pre-auth attempt row is the same as a payment attempt, except the intent was a hold (pre-authorization / damage deposit) rather than a charge. All the statuses above apply the same way. A failed pre-auth means no hold was placed -- the booking has no funds reserved, so place the hold again with another card or collect the deposit a different way.
Where the reason comes from
The reason shown under a failed row is the card issuer's own explanation, passed through from the payment network (with the decline code in parentheses, for example insufficient_funds). When the bank does not provide one, a generic "card was declined" message is shown. The same reason is shown to the staff member at the moment the payment fails.

