Payment capture timing
Why it matters
Charging a card before the booking record is safely persisted and confirmed creates a class of support incidents that requires manual refunds: "I was charged but have no booking." CWE-841 (behavioral workflow violation) and CWE-362 both apply — the payment and booking writes are implicitly ordered, and that ordering is not enforced by the code. Stripe's authorize-then-capture flow (capture_method: 'manual') exists precisely for this scenario: authorize the payment (reserve funds) while processing the booking, then capture (collect funds) only after the booking is guaranteed. Any other ordering introduces a window where money moves without a corresponding booking.
Severity rationale
High because premature capture means every downstream booking failure — DB error, webhook delay, constraint violation — produces a charged customer with no reservation, requiring manual refund per incident.
Remediation
Use capture_method: 'manual' on the PaymentIntent and capture only after the booking record is confirmed. Implement this in src/app/api/checkout/route.ts or src/lib/payment-service.ts.
// 1. Persist booking first
const booking = await db.booking.create({
data: { ...bookingData, status: 'PENDING_PAYMENT' }
});
// 2. Authorize (no money moves yet)
const intent = await stripe.paymentIntents.create({
amount,
currency: 'usd',
capture_method: 'manual',
metadata: { bookingId: booking.id },
});
// 3. Confirm booking, then capture via webhook
// stripe.paymentIntents.capture(intent.id) — called in the webhook handler
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Booking Flow & Lifecycle Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- cwe · CWE-841 — Improper Enforcement of Behavioral Workflow
- cwe · CWE-362 — Concurrent Execution Using Shared Resource with Improper Synchronization
- iso-25010:2011 · functional-suitability.functional-correctness
Taxons
History
- 2026-04-18·v1.0.0·Initial import from booking-flow-lifecycle·automated