Designing trust into
every transaction.

A wedding booking is
not a normal checkout.

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 traditional ecommerce model—click buy, charge immediately—didn’t fit the relationship. A vendor still needed to confirm availability and accept the work, while the couple needed confidence that their payment would not disappear into an uncertain booking.

The design problem became bigger than checkout: how could the product make money movement, commitment, timing, and responsibility understandable to both sides?

Separate intent
from commitment.

Instead of immediately capturing payment, Plan Zinnia creates a pending booking and authorizes the payment while the vendor reviews the request. The vendor then has a defined confirmation window.

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.

Every payment state needs
a human explanation.

The challenge was not exposing Stripe terminology. It was translating financial state into language and actions that make sense during an emotional, high-stakes purchase.

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.

The UI was only
one layer of the experience.

Underneath the screens, the booking lifecycle coordinates Stripe PaymentIntents with manual capture, Stripe Connect accounts, subscriptions, verified webhooks, scheduled jobs, transactional email, and the Plan Zinnia booking model.

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.

Trust is clearest
at the edges.

The happy path is only part of a payments product. The harder design work is deciding what happens when people do nothing, change their minds, or a system fails.

Payments are a
trust experience.

Building Plan Zinnia’s payment system pushed me beyond designing a checkout screen. I had to think about money as a lifecycle shared by two customers, a payment provider, and the marketplace itself.

The most important design work was making that lifecycle legible: when a couple has committed, when a vendor has committed, when money actually moves, what happens when something goes wrong, and what each person should expect next.

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.