Payment — Security

PCI-DSS and scope reduction

PCI-DSS (Payment Card Industry Data Security Standard) applies to any system that stores, processes, or transmits raw card data — and compliance is expensive and operationally heavy (network segmentation, regular audits, strict access controls) precisely in proportion to how much of your system touches raw card data. Scope reduction is the strategy of minimizing how much of your infrastructure is ever in PCI scope at all — the fewer systems that ever see a raw card number, the smaller (and cheaper, and less risky) your compliance burden.

Tokenization: the standard scope-reduction mechanism

Client's browser -> loads the payment processor's OWN hosted form/JS SDK (e.g. Stripe Elements)
  -> raw card number goes DIRECTLY from the browser to the PROCESSOR, never touching your server
  -> processor returns a TOKEN (a reference, not the actual card number) to your frontend
  -> your backend only ever receives and stores the TOKEN, never the raw card number

Tokenization means the raw card number never transits or touches your own servers at all — the browser talks directly to the payment processor's own secured infrastructure, and your backend deals exclusively in tokens (opaque references the processor can use to actually charge the card later, but which are useless to anyone who steals them from your database, since they only work in combination with the processor's own authorization). This is what keeps the vast majority of a typical application's infrastructure entirely OUT of PCI scope — your database, your logs, your application servers never see a raw card number to leak in the first place.

Why raw card numbers must never appear in logs

This directly connects to Centralized Logging's "avoiding logging sensitive data" section — with tokenization in place, this risk is structurally eliminated for card numbers specifically (your code never has a raw card number in memory to accidentally log), which is itself a strong argument for tokenization beyond just compliance scope: it removes an entire class of accidental-logging risk by construction, rather than relying on developers remembering to mask it correctly every time.

Webhook signature verification

@PostMapping("/webhooks/payment")
public ResponseEntity<Void> handleWebhook(@RequestBody String rawPayload,
                                            @RequestHeader("X-Signature") String signature) {
    if (!signatureValid(rawPayload, signature, webhookSecret)) {
        return ResponseEntity.status(401).build(); // reject — don't process an unverified payload
    }
    // only now parse and act on the payload
}

A webhook endpoint is a publicly-reachable URL by necessity (the processor needs to reach it from the internet) — without signature verification, anyone who discovers the URL could send a forged "payment succeeded" event and potentially trigger order fulfillment for a payment that never actually happened. Verifying a cryptographic signature (using a shared secret configured with the processor) before trusting any webhook payload is a mandatory, not optional, security control — directly relevant to the webhook handling discussed in Payment — Failure Handling & Reconciliation.

Fraud-detection signals before charging

• Velocity checks: an unusually high number of payment attempts from the same card, IP, or account in a short window is a common fraud signal worth checking before (or alongside) attempting the actual charge.
• Address/CVV verification (AVS/CVV checks): most processors support verifying the billing address and CVV match what's on file with the card issuer — a mismatch doesn't always mean fraud, but is a signal worth factoring into a risk score rather than ignoring.
• Processor-provided risk scoring: major processors (Stripe Radar, similar tools from others) provide their own fraud-risk scores per transaction, informed by data far broader than any single merchant has access to — using this signal, rather than reimplementing fraud detection from scratch, is the standard, defensible approach for most teams.

Follow-up questions this topic invites — and their answers

Q: If tokenization removes card numbers from your servers entirely, is there anything about payment still in PCI scope? A: Yes — even with tokenization, the systems that handle tokens, initiate charges, and display payment UI are typically still in a REDUCED PCI scope (SAQ A or similar, the lightest compliance tier) rather than zero scope, since a compromised token-handling system could still be misused, even though it never held raw card numbers; "reduced scope," not "no scope," is the accurate framing.

Q: Why can't the browser just send the card number to YOUR backend, which then forwards it to the processor? A: That path puts the raw card number through your own server (even briefly, even without persisting it) — which is enough to bring that server into full PCI scope; tokenization's value specifically comes from the card number never transiting your infrastructure AT ALL, not just from not storing it afterward.

Q: What should happen if a webhook signature check fails — could that ever be a legitimate request with a bug, rather than an attack? A: Reject it either way and alert — investigating a legitimate signing bug is a debugging task for your own integration configuration (checking the webhook secret is correctly configured, matches what's registered with the processor), not a reason to weaken the check itself; a 'fail open' policy on signature verification defeats the entire point of having it.

Q: How aggressive should fraud-prevention checks be, given they can also block legitimate customers? A: This is a genuine business tradeoff (false positives blocking real customers vs false negatives allowing fraud through), typically tuned using the processor's risk-scoring output combined with business-specific thresholds — an overly aggressive fraud filter has a real, measurable cost in lost legitimate revenue, so it's rarely correct to simply maximize fraud-blocking without weighing that cost.