Payment architecture that keeps card data
out of your servers, not just out of your logs
The cheapest way to handle PCI DSS is simple: never touch a raw card number. That is an architecture choice, not something you bolt on later. We build checkouts so card data goes straight from the customer's browser or app to the gateway. Your servers only ever see a token. The scope boundary is documented, so your compliance review has something concrete to point at.
Why “never touch the card number” wins
PCI-aware payment architecture is a design choice, not a product. The goal is simple: your servers, logs and database never hold a raw card number. That shrinks your PCI DSS scope down to the smallest realistic level, commonly SAQ A. The alternative is the much heavier scope you get when you process card data directly. We do it with the gateway’s hosted fields or client-side SDK. A card number travels from the customer’s browser or app straight to the gateway. Your backend only ever receives a token, and that token is useless to anyone who steals it.
When it matters, and when it does not
Get this right before you build or rebuild any checkout that takes cards directly. The architecture decision is far cheaper to make upfront than to retrofit once a raw-card-data flow is already live. Migrating under time pressure, because an assessor or a gateway flagged it, costs even more. It matters most for custom checkouts, since platforms like Shopify Payments or a well-configured WooCommerce gateway plugin are usually already built this way.
You do not need a separate engagement if your checkout already uses the gateway’s hosted fields or SDK and has never stored a raw card number. A quick architecture review confirms that, no rebuild needed. This also is not the right page if what you actually need is formal PCI certification. That goes through a Qualified Security Assessor. Our job is the technical architecture a QSA will be looking at, not the assessment itself.
How the checkout actually works
Card input moves to the gateway’s hosted field or client SDK. It sits inside your page or app but is served from the gateway’s own domain. The card number is typed directly into a frame your server never sees. Your backend receives a token after the fact and uses it to charge the card, to save it for next time, and for any refund. Never a card number.
We check every place card data could leak: logs, error-tracking tools like Sentry, database columns left over from an old integration, and we close those paths. TLS configuration, header hardening and a basic infrastructure review cover whatever stays in scope even with tokenization. The result is documented against the relevant Self-Assessment Questionnaire type, so your compliance process or a QSA has a clear map of what changed and why.
What this does not solve
This reduces scope. It does not remove every obligation. Whatever stays in scope, your web server, your network, still needs basic security hygiene, which is a smaller but real ongoing cost. Switching gateways later is easier with this architecture than with a raw-card-data integration, but it is not free, since hosted-field implementations differ by provider.
Formal PCI validation, the actual signed SAQ or a QSA’s report, is a business process tied to your bank and payment brand requirements. This page covers the architecture. It does not cover that process.
Price and timeline
| Option | Price | What it covers | Timeline |
|---|---|---|---|
| MVP | from $2,500 | Migrate one checkout to hosted fields or SDK tokenization, scope documentation | 3 to 6 weeks |
| Production | from $6,000 | Multiple checkouts or apps, saved-card tokenization, log and infrastructure review | 6 to 10 weeks |
Related
This work underlies payment gateway integration and fraud prevention for checkout, and it pairs with secrets management for the credentials that stay in scope. It is part of our development and audit services. You can see the same discipline in the payment layer of the ProBay AI agent team case and in the factory ERP recovery rebuild.
Ready to find out what your current checkout actually touches? Get in touch and we will map it with you.
FAQ
How much does a PCI-aware rebuild cost?
From $2,500 for a standard checkout, migrated to hosted fields or SDK tokenization, with a documented scope boundary. A full compliance program with a QSA engagement costs more, and it is quoted by the QSA, not us.
How long does it take?
3 to 6 weeks, depending on how much of your current checkout handles raw card data today and needs to change.
Does this make us PCI compliant?
It reduces your scope and gives you something concrete to show an assessor. Formal compliance, the actual SAQ or ROC, is validated by you or a Qualified Security Assessor, not by us. We build the architecture. The certification is on you.
Which gateways support this approach?
Stripe, Opn (Omise) and most modern gateways already have hosted fields or an SDK built for this. The harder cases are older or local providers where the only integration option is a raw API call. We flag that early if it is what you are on.
What about saved cards for returning customers?
Saved cards use the gateway's own tokenization: a reusable token tied to the customer, not the card number. Repeat charges never need you to store or re-enter raw card data.