Designing payments around a wedding booking.

A booking request needs vendor confirmation.

Couples may be paying thousands of dollars to a small business they have never worked with. Vendors need confidence that a booking is real—and that they will actually get paid.

A couple could select a service and request a date, but the vendor still needed to confirm availability and accept the work. Charging immediately would move money before both sides had agreed to the booking.

I needed to design the agreement between those steps: what the couple was requesting, what the vendor was accepting, when payment would be captured, and what each person should expect if the booking did not go ahead.

Authorizing payment before capturing the charge.

I chose a pending-booking model with separate authorization and capture. Plan Zinnia authorizes payment when the couple submits a request, then gives the vendor a defined window to review it. This keeps the request moving without treating it as an accepted booking.

If the vendor confirms, the payment is captured and the booking moves forward. If they decline—or the request expires—the authorization is canceled rather than becoming a completed charge.

Explaining what happens at each booking step.

I designed the flow to answer practical questions: Is this a request or a confirmed booking? Has payment been captured? Who needs to act next?

The couple needs to know whether a request is pending, confirmed, declined, expired, or canceled. The vendor needs to know what action is required, how long they have, and what happens to the payment when they respond.

Connecting vendor decisions to payment behavior.

I implemented the booking workflow using Stripe PaymentIntents with manual capture, Connect accounts, and Transfers. The booking record, payment state, notifications, and scheduled operations needed to stay aligned as a request moved through review, confirmation, and payout.

Booking records retain cent-denominated fee breakdowns and payment state so the product can explain what happened without relying on Stripe as the only source of context. Sensitive payment operations happen server-side and identify the current vendor from authenticated context rather than trusting client-provided identity.

Handling unanswered requests and failed payments.

I worked through the cases where a request could stall or money could move at the wrong time: no vendor response, a declined request, failed capture, and a payout that was not eligible for release.

What I delivered and what comes next.

I designed and implemented the payment lifecycle as part of Plan Zinnia’s live marketplace, connecting checkout, vendor review, capture, and scheduled payout. The work included the UX, payment integration, booking state, and operational checks around those steps.

The platform is early in adoption. This case study describes the delivered workflow; it does not yet establish payment volume, conversion gains, or a reduction in support requests. Those outcomes need evidence as usage grows.

AI-assisted development accelerated implementation, but I remained responsible for the product model, UX decisions, integration behavior, testing, debugging, and evolution of the production system.