Tokenization occurs strictly client-side via provider SDK

Server-side tokenization means raw card data — number, expiry, CVC — travels from the user's browser to your server before it reaches Stripe. Even if the server immediately tokenizes and discards the values, your application, reverse proxies, error trackers, and application logs all have an opportunity to capture that data. PCI-DSS 4.0 Req 3.3 prohibits this transit, and Req 4.2 requires that cardholder data in transit be protected with strong cryptography. Under OWASP A02 (Cryptographic Failures), passing card numbers over any server path you control — even encrypted — expands your attack surface and audit scope. The browser-side Stripe SDK sends card data directly from the user to Stripe's servers via an iframe, meaning your JavaScript context never sees the values.

Tokenization must happen in the browser using the Stripe JS SDK. The server SDK's paymentMethods.create() with raw card fields is the anti-pattern to eliminate.

// WRONG — server-side tokenization (card data touches your server)
// app/api/payment/route.ts
const pm = await stripe.paymentMethods.create({
  type: 'card',
  card: { number: body.cardNumber, exp_month: body.expMonth, cvc: body.cvc }
})

// CORRECT — client-side tokenization only
// In a client component
const { paymentMethod } = await stripe.createPaymentMethod({
  type: 'card',
  card: elements.getElement(CardElement)!,
})
// Send paymentMethod.id to your server — never the card fields

Search for stripe.paymentMethods.create and stripe.tokens.create in server-side files. Every occurrence with a raw card object is a violation.