Payment Checkout Flow Designer

What this prompt does

This prompt generates a complete payment checkout UI specification by combining your business context — type, payment methods, average order value, and known abandonment issue — with a set of hardcoded industry design rules I've written directly into the template. Those rules aren't suggestions; they're constraints: single-page layout, express payment buttons above the fold, order summary always visible. The AI doesn't invent an aesthetic — it executes a structure proven to reduce friction.

What makes it work is the specificity of the eight output sections. You're not getting a vague "checkout page." You're getting card auto-detection logic, 3D Secure iframe handling, field-to-field autofocus behavior, and a framework-specific card form with real validation. The anti-pattern list embedded in the prompt actively blocks the AI from generating decisions that kill conversions — no forced account creation, no hidden fees at the payment step, no redirecting away from the checkout page, no security badges buried away from the payment button, no removal of the back button.

The [framework] variable ties the output to real, runnable code rather than pseudocode, making the result immediately applicable to your stack.

When to use it

• You're building a new checkout page and want a senior-level UI/UX spec before writing a single line of code.
• Your current checkout has a specific abandonment issue — card errors, mobile UX, unexpected fee shock — and you need targeted fixes.
• You're integrating a new payment method (Apple Pay, Google Pay) and want correct placement and fallback logic.
• You need to brief a designer or frontend developer with precise, opinionated requirements rather than vague direction.
• You're reviewing an existing checkout and want a structured checklist of what's missing against industry standards.
• You want a framework-specific card form implementation with inline validation rather than pseudocode you have to translate yourself.

Example output

For business_type: boutique e-commerce, payment_methods: Stripe card + Apple Pay + PayPal, aov: $120, abandonment_issue: card declined with no clear retry path, framework: React + Stripe.js:

Express Checkout Row (above fold):
  [ Apple Pay ] [ PayPal ] [ Google Pay ]
  — auto-hidden when browser/device does not support the wallet method

Card Form (React + Stripe.js):
  <CardNumberElement> → live Visa/MC/Amex icon detection on first 4 digits
  <CardExpiryElement> + <CardCvcElement> — autofocus chain triggers on field completion
  Inline error: "Your card number is incomplete" — field-level, not form-level

Declined State:
  "This card was declined. Try a different card or pay with PayPal."
  — CTA: [Try Another Card] [Pay with PayPal]
  — No generic "payment failed" language
  — Alternative payment method surfaced immediately, not buried in a help link

Trust Signal Placement:
  SSL badge + Visa/MC/Amex logos rendered directly above [Pay $120.00] button
  — not in the footer, not in a sidebar

Pro tips

• Set [aov] honestly. A $12 order and a $1,200 order need fundamentally different trust signal strategies. High-AOV checkouts need visible money-back guarantees and a phone support link near the payment button; low-AOV flows need speed above everything else — every extra trust element at low price points adds friction without payoff.
• Name the specific abandonment issue. "Drop-off" is too vague. If your issue is the mobile keyboard covering the CVV field, say that — the prompt's anti-patterns and UX output will be far more targeted than if you write "users abandon checkout."
• Use [framework] for your actual stack. Specify Vue 3 + Stripe.js, not just Vue. The more specific the framework reference, the more the generated code matches your existing component patterns and the correct provider SDK methods.
• Run the prompt twice for A/B ideas. Change only [current_issue] between runs — once for "card errors" and once for "address friction" — to generate two divergent checkout variants worth testing against each other.
• Watch how [aov] interacts with the 3D Secure section. 3DS2 has two flows: a frictionless path (invisible to the user) and a challenge path (the modal/redirect). High-AOV transactions are far more likely to trigger the challenge path. If your AOV is above $500, ask the AI to expand the 3DS challenge UX specifically — the default output covers the basics, but high-ticket checkouts need clearer "your bank is verifying this purchase" copy to prevent users from abandoning the modal thinking it's a phishing attempt.