Payment Security at Park Graph

The single most important fact on this page: Park Graph does not touch the cardholder primary account number. Card data leaves the driver's browser inside an iframe served by Stripe, gets tokenized at Stripe, and only the resulting token reaches Park Graph. The diagram below shows every actor in that flow and who sees what.

Doing it this way is not a marketing posture; it is a deliberate architecture choice that shrinks our PCI scope to SAQ A — the smallest scope a merchant can occupy. SAQ A is what allows us to publish this page without an attestation report attached; Stripe, who sits in the cardholder-data path, holds PCI-DSS Level 1 for that scope on our behalf.

The complete list of payment-adjacent fields Park Graph stores per session is short on purpose: PaymentMethod token, card brand, last four digits, expiry month and year, amount, currency, operator account ID, lot ID, session start and end, and the audit-log entries that ledger the booking and the settlement. There is no field anywhere that holds the full PAN or the CVC; there is no intermediate log line that captures either; the database column does not exist.

That short list is enough to render a receipt, support a chargeback defence, and reconcile a payout. It is not enough for any kind of card cloning or account takeover; even a successful exfiltration of the entire payments table would not give an attacker a usable card number.

Park Graph uses Stripe Connect's standard accounts. When an operator onboards (see operator verification), they create a Stripe-hosted Connect account and complete Stripe's identity, business, and bank-account verification. Funds from each driver session go to that connected account, with Park Graph's platform fee taken out on Stripe. The one exception is a new account's first-payout hold: until the first payout is released, Park Graph keeps that account's payments on its own Stripe balance, then sends them to the operator in one transfer. That release happens once 7 days have passed since the first payment, the operator's identity is verified, Stripe has turned on payouts for the account, and no fraud report or wrong-sign report is open.

Park Graph cannot redirect a payout or change the payout bank account; both live in the operator's Stripe account. When a driver is refunded, Park Graph reverses the matching transfer, so the operator's share comes back out of their account and Park Graph gives back its platform fee. Operators keep control of their bank details and of their refund policy, and the first payout's timing is stated here and on the payouts page rather than left vague.

Refunds are operator-initiated (from the dashboard) or driver-requested (from the receipt link, subject to operator policy). Either way, they run through Stripe and reach the original payment method. Park Graph never initiates an out-of-band ACH for a refund.

Disputes are issued by the cardholder's bank through the card network. We answer session disputes with our payment records. For monthly passes we pre-fill the evidence and the owner submits it. Stripe submits the response. The diagram below shows each stage of the lifecycle and the typical timing.

A driver paying through a Park Graph QR sign should expect a few things, all of which are checkable on the page that loads: a parkgraph.com address (the link the camera shows starts with https://parkgraph.com/p/), the TLS padlock in the browser address bar, the operator name and lot name visible above the payment sheet, an Apple Pay or Google Pay sheet (or Stripe Elements card fields inside an iframe), and a final receipt sent from a parkgraph.com sender. If a "Park Graph" page asks for a password, an SSN, a full name, or a full card number outside an iframe, treat it as a fake. See QR code safety for the full driver checklist and the report inbox.

We do not claim that Park Graph itself is "PCI compliant" in any unqualified sense. Stripe holds PCI-DSS Level 1 for the cardholder-data path; our scope is SAQ A. We do not claim a fixed payment uptime number — payment availability is a dependency on Stripe's uptime, which Stripe publishes themselves. The Park Graph status page surfaces our portion of the payment path (Park Graph backend + webhook delivery) plus the upstream Stripe status when degradation is observed.

We also do not represent ourselves as a money-services business. Park Graph is the technical platform; Stripe is the payment processor. We collect session payments as the owner's payment agent. Owners sell monthly passes as merchant of record.

A common alternative to the Stripe Connect architecture used here is a payment aggregator: the platform takes the driver's payment into its own merchant account, then pays out the operator on a separate schedule. Aggregator architectures are simpler in some respects but they create a fundamentally different trust posture. The aggregator holds the driver's funds, controls when the operator gets paid, decides on chargeback losses, and carries the merchant relationship with the card networks. Park Graph chose Stripe Connect to keep most of that out of its hands: after a new account's first payout is released, each payment goes to the operator's own connected account, which pays out to the bank account the operator chose, on the schedule set by their plan.

The limits are concrete, and so are the exceptions. Park Graph cannot change an operator's payout bank account or send a payout anywhere else. Park Graph does hold a new account's payments until the first payout is released, and it pauses payouts while a fraud signal or a report that a sign doesn't belong to the operator is under review (see operator verification). A refund reverses the operator's share of that payment. Operators set the refund policy in the dashboard. The trade-off is that operators carry a small amount of additional onboarding work — a Stripe Connect account, a verified bank account, an identity verification — and in return their money lands in an account they own, under hold and release rules written down on this page.