Tokenization narrows PCI scope, but it does not erase it

Self-hosting a payment gateway changes who operates the software. It does not, by itself, determine a merchant’s PCI DSS obligations. The decisive question is where account data travels, which systems can affect that path, and which self-assessment questionnaire the merchant is eligible to use.

That distinction matters when a gateway plugin sends card details to a payment provider for tokenization. If a merchant’s server never receives or stores the card number, its exposure may be lower than in a flow that handles card data directly. But “we use tokens” is not a compliance finding. The plugin’s actual flow, the checkout implementation and the provider’s role all need to be checked.

What the revised self-assessment means

PCI DSS self-assessment questionnaires are not interchangeable shortcuts. A merchant must meet the eligibility criteria for the questionnaire it submits, and its acquiring bank or payment brand may determine which validation it accepts. Recent revisions to SAQ A eligibility put explicit emphasis on the merchant confirming that its e-commerce site is not susceptible to attacks that could affect the payment process. That makes the merchant’s own site relevant even when payment processing is outsourced.

For a self-hosted checkout, do not assume that a provider-hosted tokenization step automatically qualifies the whole installation for SAQ A. Confirm whether the provider’s fields are hosted by the provider or whether the merchant page handles card data; identify what scripts and server components can change or redirect the payment flow; then compare that design with the current SAQ instructions. If the flow does not meet the stated criteria, a different assessment path may apply. Ask the acquirer or a qualified assessor when the boundary is unclear.

There is a practical reason to inspect the integration rather than rely on its label. A plugin may communicate with a provider while other parts of the merchant’s environment still serve checkout pages, manage configuration or control scripts. The precise boundary depends on implementation. Keep records of the data flow and the controls that support the chosen assessment; do not treat a successful token response as proof that every connected system is out of scope.

Compare the operating models

A fully hosted checkout shifts more of the payment-page operation to the provider. It can be a sensible fit for a small team that wants fewer payment components to maintain. The trade-off is less control over the checkout experience and more reliance on the provider’s hosted flow and available integrations.

A self-hosted gateway connected to provider tokenization offers a different balance. The merchant operates the gateway and can keep more control over its domain, integrations and records, while a provider may handle sensitive card entry. This option suits teams prepared to verify each plugin’s data path and maintain the server and checkout environment. “Self-hosted” describes where the gateway runs; it does not establish that card data stays there or that it never enters the server.

A system that accepts or stores card numbers directly gives the merchant more responsibility and a broader security problem to manage. That can be necessary for some specialized flows, but it should be a deliberate architecture choice, not an accidental result of a plugin configuration. Teams without the people and processes to secure that environment should prefer a flow that keeps card data with the provider.

Database isolation is a separate boundary

PCI scope and tenant isolation overlap, but they are not the same question. A tokenized payment flow may reduce the card data held by the application. It does not prevent one storefront’s staff, credentials or application bug from exposing another storefront’s customer records.

OwnPay provides multi-brand architecture for managing storefronts from one installation. That is an application capability, not evidence that every deployment has database-level separation. Operators should establish what is shared and what is isolated: database and application credentials, access permissions, backups, logs, secrets and administrative access. Test whether a user or API credential for one brand can retrieve another brand’s records. Where the risk calls for stronger boundaries, consider separate databases or installations and weigh that against the extra operational work.

For ledger design, the earlier guide to querying balanced entries for reconciliation is useful background. A balanced ledger supports accounting checks; it is not a substitute for access controls or a PCI assessment.

What OwnPay changes—and what it does not

OwnPay is open-source, AGPL-licensed payment gateway software that runs on PHP servers. It has a WordPress-style plugin hook system, REST API endpoints, cryptographically signed webhooks and integrations with more than 120 payment gateway plugins, including card, wallet and crypto options. It also includes a double-entry ledger, multi-brand architecture and white-label checkout with custom domains. Its platform transaction cut is zero; provider fees and the cost of operating infrastructure are separate considerations.

Those capabilities give operators control over hosting and integration choices. They do not certify a deployment or remove the need to review plugin behavior, patch the server, protect credentials and validate the checkout flow. The same applies to webhook handling: signatures help verify event authenticity, but operators still need sound endpoint and secret-management practices. For deployment considerations, see the guidance on keeping PHP payment servers responsive for webhook work.

For teams weighing self-hosted payment gateway security, the useful decision is not “hosted or compliant.” It is which party handles card data, which systems can influence the payment page, and whether the team can maintain the boundaries it chooses. Tokenization can reduce exposure. It cannot replace that accounting.