Payment is the financial spine of RideNow. It answers “is the rider’s card good before we match, what fare did we commit, how do we hold and capture it, what do we pay the driver and when, and what do we do when something goes wrong?” Cashless by design — every ride ends with an automatic capture and a delivered receipt, every driver gets a Monday weekly payout (with optional instant payout), and every refund is automatic on system fault or operator-reviewed on dispute. The ubiquitous language — PaymentMethod, FareBreakdown, Pre-authorization, Capture, DriverBalance, RefundRequest, Receipt — is shared with the system requirements and domain model.

Product statement

Vision. Payment in RideNow is invisible when it works and instantly recoverable when it does not. The committed fare is the charged fare; the pre-auth is honest; the capture is automatic; the driver sees their earnings within five seconds of completing a ride; weekly payouts arrive on time; refunds are automatic on system fault and operator-reviewed within 24 hours on dispute.

Scope. Payment-method validation (zero-value auth on save and revalidation at request), fare estimation and committed-fare locking, pre-authorization at request and release on free cancellation, capture on completion with retry/fallback, debt recording without blocking the ride, driver per-ride earnings credit and platform commission, weekly Monday payouts with reconciliation, optional instant payout to debit card, automatic refunds on system cancellation, operator-reviewed refunds on dispute (full or partial), driver-fault deductions, ride receipts and corrected receipts on refund.

Non-goals. Holding deposits or acting as a bank or issuer (we integrate with processors and banks); accepting cash (cashless by design); negotiating fares (pricing is algorithmic); running rider identity verification (handled by Rider/Driver Management); blocking a completed ride if the post-ride capture fails (debt is recorded instead).

Problem statement (SCQ)

  • Situation. Riders need a frictionless cashless flow with predictable fares; drivers need transparent earnings and reliable, predictable payouts; operators need a clean dispute path; the platform needs every fare captured, every payout reconciled, and every disputed transaction resolved within a published SLA.
  • Complication. Cards expire, get cancelled, or are stolen between save and capture; processors have transient failures and occasional outages; refunds and driver-fault deductions must land precisely; instant payout creates fraud exposure; PCI-DSS Level 1 compliance and a 7-year financial audit trail are non-negotiable; competing platforms have eroded driver trust with payout delays and opaque deductions.
  • Question. How do we run a cashless marketplace where every fare is committed before the ride and captured within a minute of completion, every driver earnings line is visible within five seconds and paid out within two business days, and every refund — automatic or disputed — closes within its SLA, all under PCI-DSS and GDPR without ever leaking card data?

Personas & jobs

  • Daily commuter rider. “Cash-less, surprise-less, receipt in hand.” Jobs: know the exact fare before committing, never get stuck at the end of a ride with a declined card, get an automatic refund when the system cancels — no chasing support.
  • Part-time driver. “Earn predictably during chosen hours; get paid quickly when I need the cash.” Jobs: see per-ride earnings within seconds of completion, cash out available balance on demand for a transparent fee.
  • Full-time driver. “Predictable weekly income I can budget around.” Jobs: see weekly payout amount and arrival date, understand commission and any deductions on the breakdown.
  • Trust and safety operator. “Land costs where fault lies, on a clean audit trail.” Jobs: review refund requests with full ride context, approve full or partial refunds, deduct from driver balance when fault is on the driver.

Features, stories & acceptance criteria

Feature: payment method validation

Problem addressed: a card that fails at capture is a payment problem the rider lives through in the back of a moving car. Catch it earlier.

  • Story — Stored card validated in advance. “As a daily commuter rider, I want my stored card to be validated in advance, so that I never get stuck at the end of a ride with a declined payment.”
    • AC: When a rider adds a payment method, the system runs a zero-value authorization with the processor and marks the method active only if the authorization succeeds. (REQ-PAY-001)
    • AC: When a rider confirms a ride request, the system revalidates the rider’s default payment method before matching begins. (REQ-PAY-002)
    • AC: If the default method revalidation fails, the rider is prompted to update the method and the ride request is rejected until a valid method is in place. (REQ-PAY-003)

Feature: fare calculation

Problem addressed: the committed-fare promise must be backed by a fare engine that produces a transparent breakdown, applies a minimum, and computes a fair cancellation fee.

  • Story — Committed fare from estimate to receipt. (platform-driven, consumed by Ride Management)
    • AC: When a fare estimate is requested with pickup, dropoff, and ride type, the system computes the estimate from base fare, per-km rate, per-minute rate, and applicable surge multiplier. (REQ-PAY-010)
    • AC: When a rider confirms a ride request, the system locks the displayed fare as the committed fare for the ride, binding the rider to that amount unless the route materially deviates. (REQ-PAY-011)
    • AC: When a final fare is requested with actual distance and duration, the system computes the final fare applying any promotions or adjustments, bounded below by the committed fare except in cases of material route deviation. (REQ-PAY-012)
    • AC: The system enforces a per-market minimum fare; if the computed fare is below the minimum, the minimum applies. (REQ-PAY-013)
    • AC: Every ride exposes a fare breakdown showing base fare, distance charge, time charge, surge charge, tolls, promotions, fees, and total. (REQ-PAY-014)
  • Story — Cancellation fee for late rider cancels.
    • AC: When a ride is cancelled by a rider after driver assignment, the cancellation fee is computed from the per-market published policy and the time elapsed since assignment. (REQ-PAY-015)

Feature: pre-authorization at request

Problem addressed: protect drivers from uncollectable fares without surprising the rider with a charge that does not match what they confirmed.

  • Story — Pre-auth amount and release policy in receipts. “As a daily commuter rider, I want the pre-authorization amount and release policy shown in my receipts, so that the hold on my card is not a mystery.”
    • AC: When a rider confirms a ride request, the system places a hold on the rider’s default payment method for the committed fare amount. (REQ-PAY-020)
    • AC: When a ride is cancelled with no fee, the system requests release of the associated pre-authorization hold within 1 business day. (REQ-PAY-021)

Feature: auto-charge on completion

Problem addressed: completion is the moment the cashless promise is kept or broken.

  • Story — Capture from the pre-auth at completion.
    • AC: When Ride Management initiates payment capture for a completed ride, the system captures the final fare from the pre-authorized hold, adjusting the hold amount where necessary. (REQ-PAY-022)
    • AC: If capture fails, the system records the debt on the rider’s account, notifies the rider, and lets the ride reach completed status — payment failure does not block the rider in the car. (REQ-PAY-023)
    • AC: While a rider has outstanding payment debt, the system rejects payment authorization for new ride requests. (REQ-PAY-024)
    • AC: When a capture fails with a transient error, the system retries up to 3 times with exponential backoff. (REQ-PAY-025)
    • AC: When the primary payment method fails after all retries, the system attempts to capture from the rider’s next active payment method. (REQ-PAY-026)
  • Story — Receipt within a minute. “As a daily commuter rider, I want a clear receipt with fare breakdown immediately after the ride.”
    • AC: When a ride is completed and payment is captured, a receipt is delivered in-app within 60 seconds, showing base fare, distance, time, surge if any, fees, total, route summary, driver details, and payment method. (REQ-PAY-080)
    • AC: When a refund is issued for a completed ride, a corrected receipt is generated reflecting the adjusted fare and delivered to the rider. (REQ-PAY-081)

Feature: driver weekly payout

Problem addressed: the headline trust signal for drivers is whether the weekly payout arrives on time, with a breakdown they can trust.

  • Story — Predictable Monday payouts. “As a full-time driver, I want my weekly earnings deposited every Monday, so that I can rely on a regular income schedule.”
    • AC: When a ride is completed and the final fare is computed, the system computes driver earnings as fare minus platform commission and credits the driver’s payable balance. (REQ-PAY-040)
    • AC: The driver earnings breakdown is published to the driver app within 5 seconds at p95 of ride completion. (REQ-PAY-041)
    • AC: The system deducts a per-market platform commission from each fare before crediting the driver’s balance. (REQ-PAY-042)
    • AC: When the weekly payout cutoff occurs on Monday at 00:00 local market time, the system initiates payout of each driver’s accumulated balance to their registered bank account and publishes a PayoutInitiated event. (REQ-PAY-043)
    • AC: A weekly payout executes only if the driver’s balance exceeds the per-market minimum payout threshold; balances below threshold roll over. (REQ-PAY-044)
    • AC: When a weekly payout is initiated, funds arrive in the driver’s bank account within 2 business days at p99. (REQ-PAY-045)
    • AC: When a weekly payout is initiated, the driver is notified with the amount and expected arrival date. (REQ-PAY-046)

Feature: instant payout

Problem addressed: drivers who need cash before Monday churn to platforms with daily payouts. Instant cash-out closes that gap.

  • Story — Cash out within minutes for a published fee. “As a part-time driver, I want to cash out my available balance within minutes, so that I can pay a bill without waiting for the weekly payout.” (priority could, status proposed)
    • AC: Where instant payouts are enabled in the driver’s market, when a driver confirms an instant payout with a fee and arrival-time quote, the system transfers the available balance to the driver’s linked debit card minus the fee. (REQ-PAY-047)
    • AC: Where instant payouts are enabled, funds arrive within 30 minutes at p95 of confirmation. (REQ-PAY-048)
    • AC: Where instant payouts are enabled, the system enforces a per-market published daily cap on instant payout amount per driver. (REQ-PAY-049)

Feature: refunds on cancellation and disputes

Problem addressed: riders must never have to fight to get their money back when something goes wrong; costs must land where fault lies.

  • Story — Automatic refund when the system cancels. “As a daily commuter rider, I want an automatic refund when the system cancels my ride, so that I do not have to chase customer support.”
    • AC: When a ride is cancelled by the system (for example reason no-driver-available), a full refund of any captured amount is initiated and any pre-authorization hold is released within 5 minutes. (REQ-PAY-060)
    • AC: When a refund is issued, the rider is presented with the processor’s standard arrival window. (REQ-PAY-065)
  • Story — Operator-reviewed dispute resolution.
    • AC: When a rider requests a refund for a completed ride, the system records the request and places it in the operator review queue. (REQ-PAY-061)
    • AC: When a rider refund request is recorded, an operator decision is delivered within 24 hours at p95. (REQ-PAY-062)
    • AC: When an operator approves a partial refund, the specified amount is refunded to the rider’s original payment method and the driver’s earnings are adjusted accordingly. (REQ-PAY-063)
  • Story — Driver-fault refunds deducted from driver balance. “As a trust and safety operator, I want driver-fault refunds deducted from driver balance, so that costs land where fault lies.”
    • AC: When a refund is classified as driver-fault, a deduction is created against the driver’s payable balance and exposed in the driver earnings breakdown. (REQ-PAY-064)

Goals & success metrics

  • Capture latency p95 ≤ 60 seconds. (REQ-PAY-NFR-002) — capture speed keeps receipts near-instantaneous and is the headline rider-side payment metric.
  • Weekly payout on-time arrival ≥ 99% within 2 business days. (REQ-PAY-045) — the headline trust metric for drivers; reconciled per batch against bank settlement.
  • Disputed fare resolution p95 ≤ 24 hours. (REQ-PAY-062) — operator queue throughput target; pulls directly from the Earn trust on payments and payouts PRD goal.
  • Earnings-breakdown visibility ≤ 5 seconds at p95 from RideCompleted to driver-app display (REQ-PAY-041).
  • Receipt delivery ≤ 60 seconds of capture, in-app, with full breakdown (REQ-PAY-080).
  • Capture idempotency = 100%. Retries with the same capture identifier never produce duplicate charges (REQ-PAY-NFR-003). Below 100% is a direct financial-loss incident.
  • Instant payout arrival ≤ 30 minutes at p95 (REQ-PAY-048) — the value proposition is speed; below this threshold the feature does not differentiate.

Constraints

  • Regulatory — PCI-DSS Level 1. All payment card data must be stored, transmitted, and processed in compliance with PCI-DSS Level 1; card data never crosses non-compliant boundaries. Source: PRD constraint “PCI-DSS Level 1 compliance” — pinned to REQ-PAY-NFR-001.
  • Regulatory — GDPR & equivalents. Personal financial data of riders and drivers is handled under GDPR (EU), CCPA (California), and equivalent regimes; the audit trail respects right of access, correction, erasure, and data minimization where compatible with the 7-year financial retention window. Source: PRD constraint “GDPR and equivalent privacy regimes”.
  • Operational — 7-year audit trail. Every authorization, capture, refund, deduction, and payout is recorded in an append-only audit log retained for at least 7 years for chargeback defense and regulatory review (REQ-PAY-NFR-004).
  • Risk — payment fraud. Stolen cards and rider/driver collusion are the highest-likelihood, highest-impact payment risk. Mitigations: zero-value validation up front, fraud scoring on authorization and on instant payouts, capture idempotency, instant-payout daily caps. Source: PRD risk “Payment fraud via stolen cards and collusion”.
  • Operational — processor dependency. RideNow integrates with PCI-DSS-certified processors (primary + failover) and bank/ACH/SEPA networks for payouts; we do not act as a bank or issuer. PRD assumption “Payment processor supports pre-auth with release at our scale” underpins pre-auth and refund features.
  • Operational — non-blocking failure. A failed capture must never block a completed ride from reaching completed — debt is recorded and settled later (REQ-PAY-023, REQ-PAY-024).

Traceability. Every feature above references REQ-PAY-… identifiers formalized in the System Requirements page. Those requirements become value types, entities (RiderAccount, Payment, DriverBalance, RefundRequest, Receipt), state machines, services, commands, and events in the Domain Model page. Cross-context boundaries: PAY consumes RideRequested, RideRequestCancelledByRider, RideCompleted, RideCancelledByRider, RideCancelledRiderNoShow, NoDriverAvailable from Ride Management; publishes PaymentMethodValidated to Rider Management, PaymentAuthorized, PaymentCaptured, PaymentFailed to Ride Management, and DriverEarningsCredited, WeeklyPayoutInitiated, DriverBalanceDeducted to Driver Management; integrates with the PaymentProcessor, BankTransferService, and InstantPayoutNetwork infrastructure services.