Security · PCI DSS
Card data never touches our servers.
gov.online uses an outsourced Hosted Payment Page (HPP) integration with Geidea, a PCI DSS Level 1 certified processor. Card numbers go directly from your browser to Geidea's PCI-compliant infrastructure — they never traverse, transit, or land on our servers.
Architecture
- Geidea is the card processor. Card-entry happens inside an iframe served from payments.geidea.ae / www.merchant.geidea.net / www.ksamerchant.geidea.net depending on region.
- Our server creates a payment session via authenticated server-to-server API call. The session ID is returned to the customer's browser and handed to Geidea's iframe SDK.
- The iframe collects the card number, expiry, and CVC. Submission posts directly to Geidea — our origin is never in the request path.
- Geidea POSTs a signed webhook to /api/webhook-geidea with the order outcome. The webhook payload contains no full card number — only a brand and last-4 for receipts and chargeback evidence.
PCI DSS v4.0.1 SAQ-A coverage
Mapped to the 22 SAQ-A controls applicable to our architecture as of v4.0.1. Last reviewed 2026-05-06.
| Req | Control | How we satisfy it |
|---|---|---|
| 2.1 | No vendor-default passwords | Cloudflare-managed infrastructure; no shared services have vendor defaults. Admin access is single-tenant via authenticated dashboard. |
| 3.2.1 | No SAD (sensitive auth data) stored after authorisation | N/A — we never receive SAD. Geidea handles all card-data flow. |
| 6.4.3 | Maintain inventory of payment-page scripts; ensure integrity | PciScriptMonitor.astro on every payment page reports every loaded script's origin/hash to /api/admin/script-inventory. CSP locks the allowed origins — see _headers. |
| 6.4.4 | Justify each script and confirm authorisation | The CSP allowlist is the canonical inventory; each addition is reviewed in code-review with a justification line. |
| 8.3.1 | Strong authentication for system access | Cloudflare Access SSO + per-user 2FA on the admin surface. Wrangler CLI uses OAuth. |
| 9.5.1 | Physically secure media containing CHD | N/A — no physical media; all processing happens in Cloudflare's edge network. |
| 11.6.1 | Detect unauthorised changes on payment pages | Same script-inventory endpoint flags any first-seen script on a payment page in the last 24h. Admin dashboard surfaces the alert. Cloudflare Client-Side Monitoring (formerly Page Shield) is enabled at the zone level for defence-in-depth. |
| 12.3.1 | Targeted risk analysis for any custom-frequency control | Documented in /security/risk-analysis.md (internal). Reviewed quarterly. |
| 12.8.1 | Maintain list of service providers handling CHD | Single provider: Geidea (PCI DSS Level 1, Attestation of Compliance held by Geidea Saudi for Digital Payments). |
| 12.8.2 | Written agreement acknowledging shared responsibility | Geidea Merchant Services Agreement — signed. |
| 12.8.4 | Monitor service provider PCI status annually | Annual review of Geidea's AoC + status on PCI Council's validated-providers list. |
| 12.8.5 | Maintain information about which PCI requirements are managed by which entity | This page is the public summary; the full responsibility matrix is at /admin/security/pci-responsibility-matrix. |
Defence-in-depth controls (above SAQ-A)
Even though SAQ-A doesn't require these, we run them anyway:
- HTTPS everywhere — TLS 1.2+, HSTS preloaded, automatic upgrade-insecure-requests.
- Strict CSP on payment pages — see /apply/review* + /vip* sections of _headers. Blocks script-injection, frame-jacking, and data-exfiltration.
- Documented chargeback evidence pack — IP, user-agent, timestamps, billing details, card last-4, and consent text are bundled per transaction at /api/admin/evidence/<applicationId>.
- No localStorage / sessionStorage of card-related data — we deliberately never persist any card-shaped value client-side.
- Webhook signature verification — every Geidea callback is HMAC-verified against the merchant API password before mutating an application.
Scope statement
gov.online does not store, process, or transmit cardholder data. We do not have a Cardholder Data Environment (CDE). Our PCI DSS scope is limited to the redirect / iframe-embedding code that hands customers off to Geidea, and the systems that ensure the integrity of those redirects (CSP, script monitoring, secure session creation).
Card data flows look like:
customer browser
│ PAN, expiry, CVC entered into Geidea iframe
│
└──→ payments.geidea.ae (PCI DSS Level 1)
│
└──→ Geidea acquiring bank
│
└──→ card scheme (Visa / Mastercard / Mada)
gov.online server
│ receives session ID + signed webhook (NO PAN, last-4 only)
└──→ updates application status Reporting a security issue
If you find a vulnerability in our payment integration or our security controls, please email [email protected] with subject "SECURITY". We acknowledge within 24 hours and treat reports as confidential. Bug bounty programme TBA.
This statement covers PCI DSS v4.0.1 (mandatory since 2025-03-31) for gov.online Ltd. Last reviewed 2026-05-06. Next scheduled review: twelve months from last-reviewed date.