Skip to main content
Skip to main content
Anteyko

Case Study

Anti-refund payment flow: deposit UX

Flow: link → terms → confirmation → payment as deposit → status lock.

32% → 8%No-show rate
-90%Chargebacks
Year: 2025Industry: E-commerce / ServicesTimeline: 4 weeks

Problem

Service business had high no-show rate (30%+) and chargebacks from customers who changed their minds. Needed a booking flow that reduced both while remaining customer-friendly.

Constraints

  • Must be legally enforceable as deposit
  • Can't feel hostile to customers
  • Integration with Stripe required
  • Mobile-first (70% traffic from phones)

Solution

Designed multi-step flow: clear terms presentation, explicit confirmation checkboxes, payment framed as 'deposit to secure your slot'. Built status system that locks booking after payment, with clear cancellation policy shown at every step.

Deliverables

  • Booking flow (4-step)
  • Terms acceptance with audit trail
  • Stripe integration (deposits)
  • Booking status system
  • Admin panel for managing bookings
  • Email notification templates

Screenshots / UX Flow

Step-by-step walkthrough of the product interface

01

Step 1 — Start: trial lesson booking with clear how-it-works instructions

02

Step 2 — Terms: deposit conditions with summary, full text, and explicit consent checkbox

03

Step 3 — Deposit: payment summary with amount (1000 KGS) and purpose clearly stated

04

Step 4 — Confirmation: deposit received with receipt details and next-step CTAs

05

Step 5 — Complete: all done with next steps checklist and lesson link placeholder

Artifacts

Documents and deliverables from the project

Deposit flow spec

4 steps

Legal terms template

Consumer protection

Verification / Quality gates

6-phase checklist before release

01Build
Pass
02UX flow testing
Pass
03Stripe integration
Pass
04Legal terms review
Pass
05Mobile responsiveness
Pass
06Email delivery tests
Pass
All gates passed
6/6

Tech stack

Next.jsTypeScriptStripePostgreSQLResendVercel

Outcome

No-show rate dropped from 32% to 8%. Chargebacks reduced by 90%. Customer complaints about the process: zero. Booking completion rate improved 15%.

Hard parts we solved

Legal-Friendly UX

Each step designed with legal team. Terms are clear, not buried. Checkboxes are explicit, not pre-checked. Passes consumer protection review.

Chargeback-Resistant Payment Architecture

Standard card payments allow chargebacks within 120 days — the client was losing 8-12% of revenue to fraudulent refund claims. We designed a deposit-based payment architecture: (1) the charge is classified as a 'deposit' (not 'purchase') with explicit pre-authorization, making it harder to dispute under card network rules; (2) each transaction stores a signed consent artifact (timestamp + IP + explicit checkbox + terms version hash) that serves as evidence in chargeback disputes; (3) the payment amount is split: non-refundable deposit portion (booking fee) + refundable service portion, clearly displayed before confirmation; (4) webhook-based reconciliation with the payment gateway catches state mismatches within 30 seconds. After deployment, chargeback rate dropped from ~10% to under 1.5%.

Idempotent Payment Flow with Double-Charge Prevention

Users on flaky mobile connections tap 'Pay' multiple times, or the browser refreshes mid-payment. Without idempotency, this creates duplicate charges. We implemented: (1) client-side generates a unique idempotency key (UUID v4) before the first payment attempt; (2) backend stores the key in Redis with a 24-hour TTL — subsequent requests with the same key return the original result without re-charging; (3) a distributed lock (Redlock) prevents race conditions when two identical requests arrive within milliseconds; (4) if the payment gateway confirms but our webhook handler crashes before recording, a reconciliation cron (every 5 minutes) catches orphaned payments and syncs state. Zero double-charges in production across 15K+ transactions.

Have a similar project? Get an estimate or book a call.