ux-checkout-payment

• SKILL.mdcore · 15,580 bytes

# Checkout & Payment Flow Skill

## How this skill behaves (read first)

This is a **generative** skill. Checkout is the highest-stakes flow in the product — every bit of friction here is paid for in abandoned carts, and the defaults are *leaky*. The instinctive design — force account creation, show one long form, validate only on Submit, drop a blank promo box, surface the final price with no breakdown, and dead-end after payment — bleeds motivated buyers at the last step. This flow is a sequence — **cart → identity → details/address → payment → processing → confirmation** (booking swaps the front for *search availability → select*) — and which stages need investment depends on what's being bought. So this skill gates:

1. **Establish what's being bought and for whom** — that decides the stages, the fields, and the payment mix.
2. **Apply the always-true core** — the conversion-protecting patterns that hold for essentially every transaction.
3. **Surface the context-dependent decisions** (name fields, payment-method count, single- vs. multi-page, booking pickers, promo prominence) with trade-offs.

Then it hands the result to the audit lenses for validation (candidates; posture per `docs/orchestration-policy.md`). **Composition (§9):** checkout composes `ux-inputs-and-forms`, `ux-buttons`, and `ux-selection-controls` as core children, and defers confirmation-modal mechanics to `ux-modals-and-dialogs` and toast behavior to `ux-notifications-and-toasts` (peers — they own those sub-parts if reached). Under an existing design system, inherit color/type/spacing tokens.

---