PCI Compliance
PayRequest is a billing platform, not a card processor. Every payment method that involves a card — one-time payments and recurring mandates alike — is handled entirely by the connected payment provider (primarily Mollie, with Stripe, PayPal, and Payoneer available as alternatives). This is a deliberate architecture choice, not just a policy: it’s how the checkout code actually works.How Card Data Actually Flows
Customer initiates payment
At checkout, PayRequest never renders a card number, expiry, or CVC input field — there is no such form anywhere in the product. Payment collection happens on the processor’s own hosted page.
PayRequest redirects to the processor
PayRequest creates a payment with Mollie (or Stripe/PayPal/Payoneer) and redirects the browser to the
checkoutUrl / returnUrl returned by that provider’s API. The customer enters their card details directly on the provider’s hosted, PCI-compliant page — never on a PayRequest-controlled page.The provider notifies PayRequest by webhook
Once payment completes, the provider sends a webhook with the payment status and a masked reference (e.g. a mandate ID or last-4 digits) — never the full card number.
PayRequest stores only the masked reference
For saved payment methods (mandates), PayRequest stores the provider’s mandate ID and the masked card summary it returns (card brand + last 4 digits) so customers can recognize their saved method — for example
•••• 4242. The full card number and CVC are never transmitted to or stored by PayRequest at any point.What This Means in Practice
| Question | Answer |
|---|---|
| Does PayRequest ever see a full card number? | No — card entry happens on the processor’s hosted checkout, outside PayRequest’s servers. |
| Does PayRequest store CVC/CVV? | No — CVC is never collected by PayRequest and is not a field that exists anywhere in the codebase. |
| What does PayRequest store for a saved card? | The processor’s mandate/token ID and a masked display value (card brand, last 4 digits) — sufficient to show it in the customer’s saved payment methods, not to reconstruct the card. |
| Are provider API credentials protected? | Yes — connected-provider API keys, OAuth access tokens, and refresh tokens (Mollie, and other integrated services) are encrypted at rest before being written to the database. |
| Is this true for every supported payment method? | Yes for card-based methods across all supported processors — Mollie, Stripe, PayPal, and Payoneer are all integrated via redirect/hosted-checkout flows, not embedded card forms. |
Reducing Your Own Risk
Two-Factor Authentication
Add 2FA to your dashboard login to protect access to payment settings and customer data.
Audit Logs
Every account and payment-related action is logged with who, what, and when.
FAQ
Is PayRequest itself PCI DSS certified?
Is PayRequest itself PCI DSS certified?
PayRequest does not directly handle raw cardholder data — that happens on the payment processor’s infrastructure. This significantly reduces PayRequest’s own PCI scope, but PayRequest doesn’t claim its own PCI DSS certification. The certification applies to Mollie (and other connected processors) for the systems that actually touch card data.
What card data does PayRequest store for saved payment methods?
What card data does PayRequest store for saved payment methods?
A mandate/token reference and a masked summary (card brand and last 4 digits) returned by the processor — never the full PAN, expiry, or CVC.
If I connect Stripe instead of Mollie, does the same apply?
If I connect Stripe instead of Mollie, does the same apply?
Yes. Every supported card-capable processor is integrated through a redirect or hosted-checkout flow, so the same “PayRequest never touches raw card data” model applies regardless of which processor you connect.
Where can I read more about how saved cards (mandates) work?
Where can I read more about how saved cards (mandates) work?
See Saved Payment Methods for the full mandate lifecycle.