What is the optimal PCI-DSS compliant architecture for integrating Visa/Mastercard payment processing into a fully custom PHP website while minimizing SAQ scope and avoiding direct cardholder data handling?

Hello everyone,

I am currently working on a client project and need some guidance regarding payment gateway architecture and implementation.

The website is a fully custom-built website rather than a WordPress, Shopify, WooCommerce, or other CMS-based solution. The client provides carpentry and interior design services and would like to accept online payments using Visa and Mastercard.

My primary concern is designing the integration according to modern security standards while minimizing PCI-DSS compliance requirements. Since the website is custom-developed, I would like to avoid storing, processing, or transmitting raw cardholder data through my own application servers whenever possible.

From a technical perspective, I would appreciate insights on the following:

  • Should I implement a hosted payment page, embedded payment fields (iFrame), or a direct API integration?
  • What is currently considered the best architecture for reducing PCI-DSS scope (SAQ-A vs SAQ-A-EP)?
  • How do modern gateways such as Stripe, Adyen, Checkout.com, or Braintree tokenize card data before it reaches the merchant server?
  • What are the security implications of client-side tokenization versus server-side payment processing?
  • If the website later requires partial payments, deposits, refunds, recurring invoices, or saved payment methods, how would that influence the overall payment architecture?
  • For a custom implementation, what strategies are recommended for handling webhooks, idempotency keys, payment state reconciliation, and race conditions between asynchronous gateway callbacks and frontend success responses?

I am particularly interested in understanding the most scalable and secure approach that would be suitable for a custom production environment handling Visa and Mastercard transactions.

Any recommendations regarding payment gateway selection, tokenization workflows, PCI compliance boundaries, or reference architectures would be greatly appreciated.

Thank you.

Rule #1 of PCI compliance is not to do any of these things…

Minimizing PCI-DSS compliance is easy.

Get someone else to do it.

(Seriously. Unless your client’s paycheck has at least 7 zeroes and comes with a legal staff of hundreds, get someone else to do it for you. And I say this as someone who works in banking whose company DOES have to work with PCI-DSS compliance requirements.)

I’ve found that the easiest way to stay out of PCI headaches is to let a PCI-compliant payment provider handle the card entry. Once your server starts processing or storing cardholder data, the compliance requirements increase quickly. Keeping your app limited to order creation, token handling, and webhook verification is usually the most maintainable approach.