# In-app payments & payouts

### TB-017 — Card checkout with saved payment methods

- **Size:** L
- **Hours:** 23
- **Scope:** MVP

Card checkout with saved payment methods

Size reason: L — PCI-sensitive card capture plus saved-method management is the highest-risk money code in the app.

**Acceptance criteria**

- Owner can add a card via the PCI-compliant provider without raw card data touching the app server
- Owner can complete checkout using a previously saved payment method
- A declined/failed payment shows a clear error and does not confirm the booking
- Owner can remove a saved payment method
- Successful payment moves the booking into a confirmed state

### TB-018 — Walker payout scheduling and connected-account onboarding

- **Size:** L
- **Hours:** 23
- **Scope:** MVP

Walker payout scheduling and connected-account onboarding

Size reason: L — connected-account onboarding, payout timing and failure retries are third-party-dependent and hard to test.

**Acceptance criteria**

- Walker must complete connected-account onboarding before payouts are enabled
- Payouts run on the defined cadence and include only completed, paid bookings
- A failed payout triggers retry logic and notifies the walker
- Payout access is blocked until onboarding status is verified
- Walker can view their payout history

### TB-019 — Refunds and disputed-charge handling

- **Size:** L
- **Hours:** 23
- **Scope:** Full

Refunds and disputed-charge handling

Size reason: L — partial refunds interacting with payout timing is real money logic with many edge cases.

**Acceptance criteria**

- Admin/system can issue a full or partial refund tied to a specific charge
- Refund correctly adjusts an already scheduled or paid walker payout
- A disputed charge updates booking/payment status and notifies the relevant admin
- Every refund is logged with amount, reason and actor
- A duplicate refund on the same charge is prevented

### TB-020 — Receipts and payment history

- **Size:** M
- **Hours:** 11
- **Scope:** MVP

Receipts and payment history

Size reason: M — a historical ledger view that must reconcile correctly against the checkout and payout logic above.

**Acceptance criteria**

- Owner and walker can each view their own transaction history
- Each entry shows correct amount, date, status and linked booking reference
- History reconciles correctly against the checkout and any applied refunds
- A receipt can be viewed or downloaded per transaction