Trust, but read the network tab.
We almost shipped a payment integration that sent customers’ raw card numbers through our own server. This is the story of how one open DevTools panel changed which processor we use.
Moving payments to the new platform meant evaluating the checkout connector offered by our existing payment processor. Install, sandbox credentials, test order — standard evaluation. But I keep browser DevTools open during evaluations, and the network tab showed something that stopped me cold: the request leaving the checkout page carried the full card number and security code — addressed to our domain.
That’s not how modern checkout works. Card data is supposed to travel directly from the customer’s browser to the processor; the merchant’s server should only ever see a one-time token. When card data touches your server, you inherit a compliance and liability burden that no seamless-checkout convenience is worth.
The vendor’s answer: that’s sandbox-only behavior. So we read the source. The sandbox and production paths differ only in credentials and endpoint — the card-capture path is identical. There was no hosted or iframe option anywhere in the code, and card data was being written where card data must never persist. Asked directly which PCI self-assessment their integration qualified for, the vendor wouldn’t say.
So we walked. We stood up a different processor whose tokenized flow does it right, proved a full checkout end-to-end, and confirmed in the network tab — the same tab that started all this — that our server now sees only a token. Never a card number.
The uncomfortable part: this connector is out in the world, and the behavior had apparently stopped no one before us. I don’t think we’re smarter than anyone else. We just kept one habit: watch the network tab while you evaluate, and when an answer doesn’t smell right, read the code.
Trust, but read the network tab.