Payment architecture that keeps card data
out of your servers, not just out of your logs
The cheapest way to handle PCI DSS is to never touch a raw card number at all, and that is an architecture decision, not a checkbox you add later. We build checkouts so card data goes directly from the customer's browser or app to the gateway, your servers only ever see a token, and the scope boundary is documented so your own compliance review has something concrete to point at.
What it is
PCI-aware payment architecture is a design discipline, not a product: the goal is for your own servers, logs and database to never hold a raw card number, so your PCI DSS obligations shrink to the smallest realistic scope (commonly SAQ A) instead of the much heavier scope that applies when you process card data directly. This is done by using the gateway’s hosted fields or client-side SDK, so a card number goes from the customer’s browser or app straight to the gateway, and your backend only ever receives a token that is useless to anyone who steals it.
When you need it (and when you do not)
You need this before building or rebuilding any checkout that accepts cards directly, because the architecture decision is far cheaper to make upfront than to retrofit once a raw-card-data flow is already live and has to be migrated under time pressure (often because an assessor or a gateway flagged it). 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 is already using the gateway’s hosted fields or SDK and you have never stored a raw card number; a quick architecture review confirms that rather than a rebuild. This is also not the right page if what you actually need is a formal PCI certification process; that goes through a Qualified Security Assessor, and our job here is the technical architecture a QSA will be looking at, not the assessment itself.
How we build it
Card input moves to the gateway’s hosted field or client SDK, embedded in your page or app but served from the gateway’s own domain, so the card number is typed directly into a frame your server never sees. Your backend receives a token after the fact and uses that token for the charge, for saving the card for next time, and for any refund, never a card number. We review every place card data could theoretically leak, logs, error-tracking tools like Sentry, database columns left over from an old integration, and close those paths. TLS configuration, header hardening and basic infrastructure review cover the parts of your stack that remain in scope even with tokenization. The result is documented against the relevant Self-Assessment Questionnaire type, so your own compliance process or a QSA has a clear map of what changed and why.
What to watch
This reduces scope; it does not eliminate every obligation; whatever remains 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 involving your bank and payment brand requirements, and we are explicit that this page covers the architecture, not 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 underlies payment gateway integration and fraud prevention for checkout, and pairs with secrets management for the credentials that remain in scope. It is part of the development and audit services. The architecture discipline here matches the payment layer in the ProBay AI agent team and the systems rebuild in factory ERP recovery case studies.
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 is outside what we do and 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, but formal compliance (the actual SAQ or ROC) is validated by you or a Qualified Security Assessor, not by us; we build the architecture, not the certification.
Which gateways support this approach?
Stripe, Opn (Omise) and most modern gateways provide hosted fields or an SDK built for exactly this; the harder cases are older or local providers whose only integration method is a raw API post, which we flag early if that 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), so repeat charges never require storing or re-entering raw card data.