How to Clone Cash App

Create a Cash-App-style P2P payments app called PocketPay using Next.js (App Router), Tailwind, Prisma + SQLite. SIMULATED balances only - no real money, no banking license.

## What to build
Unique $handles, send/request money with notes and emoji, a single wallet balance, an activity feed, shareable payment links/QR, and a free-vs-instant cash-out with fee math.

## Screens
- Landing: hero with send-screen mockup, feature cards, simulation disclaimer
- Home: big balance, numeric keypad, Pay / Request buttons, recent contacts, activity feed
- Send/Request flow: amount → recipient (by $handle/name) → note + emoji → confirm → success receipt
- Activity: chronological transactions (in green, out gray), tap for detail + 'send again'
- Profile: avatar, editable $handle, shareable link + QR
- Scan/QR: scanner mock plus 'My QR' to receive money in person
- Add money / Cash out: simulated top-up; cash out with FREE standard vs INSTANT (1.5% fee)
- Account: balance, linked mock cards, debit-card waitlist upsell

## Prisma schema
User (id, name, avatar, cashtag unique, balance), Transaction (id, senderId, recipientId, amount, note, emoji, status, type, createdAt), PaymentRequest (id, fromId, toId, amount, note, status), LinkedAccount (id, userId, label, type, isDefault)

## Money logic (must actually work, server-side, transactional)
- Send: in a single Prisma $transaction, verify sender.balance >= amount, debit sender, credit recipient, write a Transaction; reject insufficient funds
- Request: creates a PaymentRequest; accepting it runs the same atomic send; declining marks it closed
- Top-up: simulated add-money from a linked mock account credits the balance and writes a topup transaction
- Cash out: standard = free, status pending then completed; instant = balance -= amount, fee = round(amount × 0.015), write both rows
- Balances must always equal the sum of that user's signed transactions - add a /api/reconcile check
- Use integer cents for all amounts; never store money as a float
- Never trust client-sent balances; compute everything server-side

## Routes
- POST /api/send, POST /api/request, POST /api/request/[id]/accept, POST /api/request/[id]/decline, POST /api/cashout, POST /api/topup
- GET /api/activity returns the signed-in user's transactions; GET /api/u/[cashtag] resolves a recipient by $handle

## Style
Bold and modern: single strong accent (electric green or teal) on a near-black UI, oversized balance, large tactile keypad, smooth success animation, emoji-friendly notes, mobile-first. Persistent 'simulation - not a real payment service' disclaimer.

Seed: 8 demo users with $handles and avatars, the signed-in user with a starting balance, ~15 past transactions across send/request/cashout types, a couple of pending requests, and 2 linked mock cards so the UI is populated.

Build a production-quality Cash-App-style P2P payments platform. Balances are SIMULATED for the MVP (no license, no real funds), but the money engine must be a correct, append-only DOUBLE-ENTRY ledger - assume hostile clients trying to spend money they don't have or double-send.

## Stack
- Next.js 14 App Router + TypeScript + Tailwind + shadcn/ui; Framer Motion for send-success feedback
- PostgreSQL via Prisma; NextAuth (email + phone OTP); Zod request validation; integer-cents money math (never floats)
- A BaaS adapter interface (Stripe Treasury / Unit) with a SimulatedProvider implementation now, so the real provider can drop in later

## Core design: double-entry ledger
- Model accounts (one per user wallet, plus system accounts: house, fees, external) and ledger_entries. Every movement is 2 or more entries that net to zero
- A 'send' is: debit sender wallet, credit recipient wallet (and for instant cash-out, an extra debit to the fees account). Balance = sum of an account's entries - never a stored mutable field
- This makes every cent traceable and makes double-spend impossible under proper transaction isolation

## Transfer execution (server-authoritative, atomic, idempotent)
- POST /api/transfers: { toCashtag, amountCents, note, idempotencyKey }. In one SERIALIZABLE Postgres transaction: lock sender balance, verify funds, write balanced entries, return the receipt
- Idempotency keys prevent double-submits; reject replays
- Requests are a separate object; accepting a request triggers the same transfer path

## Schema
users, accounts, ledger_entries (append-only, immutable), transfers (one per user-facing payment, links its entries), payment_requests, linked_accounts, idempotency_keys. Indexes on ledger_entries(account_id, created_at) and transfers(sender_id|recipient_id, created_at).

## Implementation order
1. Schema + auth + accounts/ledger primitives with unit + property tests (sum of all entries == 0; balance never negative; concurrent double-send test must fail to overspend)
2. Transfer endpoint + idempotency + receipt
3. Home: balance, keypad, Pay/Request UI with optimistic + reconciled states
4. Activity feed + transaction detail + 'send again'
5. $handle profiles, shareable payment links + QR (the viral loop)
6. Add money / cash-out with free-vs-instant fee logic (fee posts to the fees account)
7. BaaS adapter seam documented so a licensed provider replaces SimulatedProvider without touching the UI

## Quality bar
- Unmissable 'Simulation - not a regulated payment service' disclaimer; never imply real money transmission
- All money in integer cents; property-test ledger invariants in CI
- Phone-OTP auth, rate limiting on transfers, basic velocity checks even in the sim

Start with step 1; show me the accounts/ledger schema and the concurrent-double-send test (which must prove overspend is impossible) before continuing.

Design the complete UI for a Cash-App-style P2P payments app called PocketPay. React + Tailwind + shadcn/ui + lucide-react. Aesthetic: bold, confident, modern fintech - single strong accent (electric green or teal) on a near-black surface (plus a clean light mode), oversized balance number, big tactile numeric keypad, smooth success animations, friendly avatars and emoji. Mobile-first.

## Screens

### 1. Home / pay
- Top: avatar + $handle, settings icon; HUGE wallet balance number centered
- Large numeric keypad to enter an amount; primary 'Pay' and secondary 'Request' buttons under it
- Recent-contacts avatar row; small 'Simulation' badge
- Bottom tab bar: Home, Activity, Scan/QR, Card, Profile

### 2. Send / request flow
- After entering an amount: recipient picker (search by $handle/name, recent contacts grid)
- Note field with emoji; review card; CONFIRM with a satisfying animated checkmark and a shareable receipt card (amount, who, note, time)

### 3. Activity feed
- Chronological list: avatar, name, note, time, +amount in accent green / -amount in gray; section dividers by date
- Transaction detail sheet: big amount, status pill, note, 'Send again' / 'Split' actions

### 4. Profile / $handle
- Avatar, display name, editable $handle; a prominent shareable payment link and a large QR code; 'Share' button

### 5. Add money / cash out
- Add money: amount + linked mock card selector
- Cash out: choose FREE Standard (1–3 days) or INSTANT (1.5% fee) - show the fee and net amount clearly; confirm screen

### 6. Card / account
- A virtual debit-card mockup (waitlist state), linked accounts list, instant-transfer fee info, and an upsell card for a future Cash-Card-style product

### 7. Scan / QR
- Full-screen scanner mock plus 'My QR' state showing the user's $handle QR for receiving money - the in-person send flow

## Components to design once and reuse
- Contact avatar chip (avatar + name + $handle) used in the recipient picker and recent-contacts row
- Money amount display that handles large numbers gracefully
- Transaction row (avatar, name, note, signed amount in accent/gray) used across feeds

Fully responsive, mobile-first. Fill every screen with realistic names, $handles, avatars, emoji notes and amounts (a populated activity feed of ~15 items), and include a clear 'Simulated payments - not a regulated money service' disclaimer in onboarding and the footer.

Build a Cash-App-style peer-to-peer payments app called PocketPay. Balances are SIMULATED - no real money moves and no banking license is involved. Show that disclaimer clearly.

## Entities
- User: name, avatar, cashtag (unique handle), balance
- Transaction: sender, recipient, amount, note, emoji, status (pending/completed), type (payment/request/cashout/topup), createdAt
- PaymentRequest: from user, to user, amount, note, status (pending/paid/declined)
- LinkedAccount: user, label, type (card/bank), isDefault
- Contact: user, friend reference - the people list that powers the recipient picker

## Roles
- Member: sends and requests money, views the activity feed, manages their $handle and linked accounts, cashes out, generates a receive-QR
- Admin: views all users and transactions, dashboard with total volume and active users per day, can freeze a user and reverse a transaction

## Pages
1. Home: big wallet balance, numeric keypad, Pay and Request buttons, recent contacts, activity feed
2. Send/Request: enter amount, pick a recipient by $handle/name, add a note and emoji, confirm with a success receipt
3. Activity: chronological transactions (incoming green, outgoing gray), tap for detail and 'send again'
4. Profile: avatar, editable $handle, shareable payment link and QR code
5. Scan/QR: a scanner and a 'My QR' screen to receive money in person
6. Add money / Cash out: simulated top-up; cash out as FREE standard or INSTANT with a 1.5% fee
7. Account: balance, linked mock cards, debit-card waitlist upsell
8. Admin: all users and transactions, dashboard of total volume and active users per day

## Rules
- A send requires balance >= amount; it debits the sender and credits the recipient atomically; insufficient funds is blocked
- Requests notify the recipient; accepting a request creates the payment; declining closes it
- Top-up: a simulated add-money credits the balance and logs a topup transaction
- Cash out: standard is free and settles later; instant charges a 1.5% fee immediately
- Every movement writes a transaction; a user's balance must always reconcile to their transaction history
- All amounts are stored in integer cents; never use floating-point money

## Look & feel
Bold modern fintech: one strong accent color on a near-black UI, oversized balance number, large tactile keypad, smooth success animations, friendly avatars and emoji notes, mobile-first. Persistent 'simulated payments' disclaimer.

Seed: 8 demo members with $handles and avatars, the signed-in user with a starting balance, ~15 past transactions across types, and 2 linked mock cards so the app looks alive.