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 settle directly to that connected account; Park Graph nets the platform fee on Stripe.

The architectural consequence is that Park Graph cannot move operator funds. We cannot pull funds back to a Park Graph balance, we cannot redirect a payout, and we cannot change the payout bank account. Operators retain control of their money and of their refund policy. This is also why Park Graph does not publish a "we hold your funds for X days" policy — we don't hold them at all.

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. Park Graph automatically attaches the standard dispute-evidence packet: timestamped session record, geofenced QR scan location, device fingerprint where Apple Pay or Google Pay was used, the audit-log entry for the booking, and the driver receipt. Operators can add additional evidence (entrance photo, gate timestamp) before the network's deadline. Stripe submits the response. Park Graph does not contest disputes on the operator's behalf without an explicit dispute-policy setting. 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/p/ URL, 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; the operator is the merchant of record on their own connected account.

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 specifically to avoid that posture: the operator is the merchant of record on their own connected account, holds their own funds, and runs their own payout schedule from their own Stripe dashboard.

Architecturally the consequences are concrete. Park Graph cannot freeze an operator's funds. Park Graph cannot delay an operator's payout. Park Graph cannot decide whether to refund a session over the operator's objection (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 — but the trade buys them custody of their money and a direct relationship with the payment processor. That is the trade we made and that is the trade the payment-security page documents.