Security

Cards never touch our servers.

Fluxa never receives or stores the full primary account number. Card data is tokenised at the FCA-authorised payments partner, which holds the cardholder funds and operates the Level 1 PCI environment. Fluxa sits in PCI DSS v4.0 SAQ-A scope. The rest of this page documents what is in place today and what is on the roadmap. Honest, specific, no security theatre.

At a glance

The headline facts before the detailed sections.

Card numbers never reach Fluxa. The full PAN is tokenised at the FCA-authorised payments partner; Fluxa receives only network tokens, last-four digits, expiry and card type.
PCI DSS v4.0 SAQ-A scope. Because Fluxa never holds card data, the merchant and Fluxa both qualify for the lightest PCI validation scope. The payments partner operates at PCI DSS Level 1.
UK data residency. Production application, database and backups all hosted in the United Kingdom. No routine non-UK data transfers.
Encryption everywhere. TLS 1.2 or above on every public endpoint with HSTS enforced. AES-256 at rest on production database and backups.
Nineteen anomaly detectors. Authentication, transaction and admin operations monitored in real time with automated alerts.
HMAC-SHA256 webhooks with idempotency keys and atomic state transitions.
Audit logging retained thirteen months. Every state-changing operation is logged for forensic investigation.
Article 33 breach response. Personal data breaches reported to the Information Commissioner’s Office within seventy-two hours of becoming aware.
Responsible disclosure. security@fluxapay.co.uk for vulnerability reports.

Compliance and certifications

An honest list of where Fluxa stands today, what the payments partner provides on Fluxa’s behalf, and what is on the audit roadmap.

In place today

PCI DSS v4.0 SAQ-A: Fluxa operates in PCI DSS v4.0 SAQ-A scope. The merchant integration is designed so the full PAN never reaches Fluxa or the merchant; it is tokenised at the payments partner. SAQ-A is the lightest validation scope under the standard and is appropriate where all cardholder data functions are fully outsourced to PCI DSS-validated third parties.
Payment Facilitator under an FCA-authorised payments partner: Fluxa Ltd is not directly authorised by the Financial Conduct Authority. Card processing is performed under the FCA authorisation of a payments partner, which is the regulated entity under the Payment Services Regulations 2017 and operates at PCI DSS Level 1, the most stringent service-provider scope under the standard. Tokenisation of the full PAN takes place inside the payments partner’s Level 1 environment, before any card data reaches Fluxa.
UK GDPR and Data Protection Act 2018: Fluxa Ltd is registered as a data controller with the Information Commissioner’s Office and pays the annual data-protection fee. Detailed disclosures are on the privacy page.
UK Modern Slavery Act: Fluxa complies with the Modern Slavery Act 2015 transparency requirements in its supplier engagement.

UK regulatory frameworks Fluxa operates under

Fluxa is not directly authorised by the Financial Conduct Authority, but the payments partner is, and several UK regulatory frameworks shape how Fluxa operates as part of that authorised firm’s programme:

FCA Operational Resilience (PS21/3): The payments partner is subject to the FCA’s Operational Resilience rules. Fluxa is an Important Business Service in the payments partner’s mapping where the relationship requires it, and Fluxa’s availability, recovery and incident commitments are designed to support the payments partner’s impact tolerances.
FCA SYSC 8 outsourcing governance: Where Fluxa performs functions on behalf of the payments partner’s authorised programme, the arrangement is governed by the payments partner’s SYSC 8 outsourcing controls. Fluxa supports the payments partner’s required oversight, audit access and exit-planning obligations.
Payment Services Regulations 2017: The payments partner is the regulated payment institution under PSRs 2017. Fluxa operates as a Payment Facilitator within the payments partner’s programme, which is the route by which UK payment-services regulation reaches the service that merchants experience.
NIS Regulations 2018: Fluxa monitors its status under the Network and Information Systems Regulations 2018, which apply to relevant digital service providers above prescribed thresholds. Technical and organisational measures on this page are designed to meet a digital-service-provider security baseline irrespective of formal designation.

Card scheme security programmes

Visa Account Information Security (AIS) and CISP: Visa’s Cardholder Information Security Program applies to all entities that store, process or transmit Visa cardholder data. Compliance is demonstrated through PCI DSS validation, which Fluxa holds at SAQ-A scope and the payments partner holds at Level 1.
Mastercard Site Data Protection (SDP): Mastercard’s SDP programme is Mastercard’s implementation of PCI DSS. Same validation route as for Visa.
PCI Token Service Provider: Network tokenisation is performed by a PCI-validated Token Service Provider operated by or integrated with the payments partner. Fluxa references tokens issued by the TSP; the TSP holds the mapping back to the underlying PAN inside its PCI environment.

What Fluxa does not yet hold

Fluxa is a UK company preparing for a public launch. The following independent attestations are on the security roadmap (see the roadmap section below) but are not in place at the time of writing. Fluxa makes no claim to hold them today:

SOC 2 Type II report
ISO/IEC 27001 certification
ISO/IEC 27017 (cloud security) certification
ISO/IEC 27018 (PII in the cloud) certification

Where a merchant or partner requires an attestation Fluxa does not hold, the payments partner’s certifications and Attestation of Compliance documents can be made available under a non-disclosure agreement.

Card data handling

The architecture that keeps the full PAN out of Fluxa and out of the merchant.

Where the card data goes

At checkout: Cardholder card details are submitted directly to the payments partner’s PCI-validated card data environment from the cardholder’s browser, using an embedded iframe or hosted-checkout flow. The merchant’s page and Fluxa’s servers do not receive the full PAN at any point.
At authorisation: The payments partner returns a network token, the last four digits, the expiry month and year, the card scheme (Visa or Mastercard) and the card type to Fluxa. Fluxa stores those non-sensitive fields and references the token for any future operation against the same card (refund, retry, recurring charge).
At storage: Fluxa stores tokens. The payments partner is the controller of the underlying card-data environment and maintains its PCI DSS Level 1 obligations for the actual PAN, CVV and full track data.
At display: Card displays in the merchant dashboard show last-four only. No interface in any Fluxa product exposes the full PAN, the CVV or the magnetic stripe data.

What Fluxa never receives or stores

The full primary account number (PAN)
The card verification value (CVV / CVC / CVV2)
The full magnetic stripe data or chip data
The cardholder’s PIN

Encryption

Data is encrypted at every layer where it sits or moves.

In transit: TLS 1.2 or above on every public endpoint. Older TLS versions and the SSL family are not accepted. HSTS is enforced with a long max-age. Perfect Forward Secrecy cipher suites are preferred. Certificates issued by a publicly-trusted certificate authority and rotated automatically.
At rest: Production database encrypted with AES-256 by the database service. Backups encrypted with AES-256 before leaving the database service. Object storage encrypted with AES-256 with provider-managed keys.
Key management: Encryption keys are managed by the cloud provider’s key management service. Application-level secrets (API keys, webhook signing keys) are held in a managed secrets store, not in source control, not in environment files in repositories, and not in build artefacts.
Webhook signing: Outbound webhooks are signed with HMAC-SHA256 using a per-merchant signing secret. The merchant verifies the signature before trusting the payload. Signing secrets rotate on merchant request without downtime.
API authentication: API access uses bearer tokens with a documented expiry and rotation pattern. Tokens are scoped per merchant. There are no shared service-level credentials accessible by API consumers.

Access control

Who can do what, on which surfaces, with what proof of identity.

Least-privilege by default: Internal access to production systems is granted on a least-privilege, need-to-know basis. Engineering, operations and compliance roles each see only the systems and data their function requires. Production database access is not granted by default to engineering staff.
Multi-factor authentication: Multi-factor authentication is required on every internal account that can affect production: cloud-provider consoles, the source-code host, the production database, the admin dashboard, the secrets store. SMS-only factors are not accepted; time-based one-time-password (TOTP) or WebAuthn are the supported factors.
Single sign-on: Internal team access to operational tooling is brokered through a single sign-on identity provider with MFA enforced at the IdP. Joiner / mover / leaver changes are made centrally in one place.
IP allowlisting on admin surfaces: The admin dashboard and operational tooling are restricted to a defined IP allowlist. Bitwise CIDR matching is enforced server-side; allowlist changes are logged and reviewed.
Role-based access in the merchant dashboard: Each merchant account supports multiple users with role-based permissions (owner, admin, finance, support, read-only). Role assignment is auditable and exportable.
Privileged operations require justification: Operations such as merchant deletion, balance correction, settlement re-issue and webhook secret rotation require a written justification recorded in the audit log alongside the operator identity and timestamp.

Application security

The defensive engineering that keeps the surface area small.

Idempotency on every state-changing endpoint: Capture, refund, void, transfer and webhook delivery all accept and require an idempotency key. Retries are safe by design.
Atomic state transitions: Payments move through a defined six-state lifecycle (RECEIVED, CAPTURED, SETTLING, SETTLED, FAILED, REFUNDED) under a state machine that prevents impossible transitions. Database transactions enclose the state change and the ledger posting so that one cannot succeed without the other.
Double-entry ledger: Every monetary movement is recorded as a double-entry posting against named accounts. Balances reconcile by construction; a single missing or duplicated posting fails the integrity check.
CSRF protection: Cross-site request forgery protection on every state-changing form in the dashboard and on every cookie-authenticated endpoint.
Input validation and parameterised queries: All user input is validated server-side against a typed schema before reaching business logic. Database access uses parameterised queries through an ORM; raw concatenated SQL is not used.
Rate limiting: Public endpoints are rate-limited per IP and per merchant. Authentication endpoints have stricter limits and lock-out behaviour.
Dependency hygiene: Production dependencies are pinned to specific versions. Automated tooling flags known vulnerabilities in the dependency tree. Vulnerability patching is governed by the severity-based SLA in the security-testing pipeline below (critical seven days, high thirty days, medium ninety days).
Webhook delivery integrity: Webhooks are signed with HMAC-SHA256, include a delivery timestamp to prevent replay, and carry an idempotency key for safe redelivery. Failed deliveries are retried with exponential backoff and exposed in the dashboard.

HTTP security headers

Every Fluxa response sets a defensive header baseline:

Strict-Transport-Security · HSTS enforced with a long max-age and preload list inclusion.
Content-Security-Policy · CSP set in enforce mode, scripts and styles loaded only from defined origins, no inline scripts without nonce or hash, no unsafe-eval.
X-Frame-Options · DENY on dashboard surfaces; SAMEORIGIN on the hosted checkout where embedding is required.
X-Content-Type-Options · nosniff on every response.
Referrer-Policy · strict-origin-when-cross-origin.
Permissions-Policy · restrictive defaults; camera, microphone, geolocation and similar surfaces explicitly disabled where not required.
Cross-Origin-Opener-Policy · same-origin on sensitive surfaces.

Subresource integrity and CORS

Third-party scripts and stylesheets are loaded with Subresource Integrity (SRI) hashes where the third party supports it. CORS policy on the public API explicitly allowlists origins for browser-side calls; same-origin enforced on dashboard endpoints.

Security testing in the build pipeline

Static analysis (SAST): Static application security testing runs on every pull request. High-severity findings block merge.
Software composition analysis (SCA): Dependency-tree scanning runs on every build. Known vulnerable versions are flagged and tracked in the issue tracker until patched. Critical CVEs are patched within seven days of disclosure; high within thirty days; medium within ninety days.
Dynamic application security testing (DAST): DAST scans run against staging environments on a defined schedule. Findings triaged into the same severity-based SLA as SCA.
Software Bill of Materials (SBOM): An SBOM is produced for every production release and retained for the production support lifetime of that release.

Monitoring and detection

What Fluxa watches for, how it watches and how long the evidence is kept.

Nineteen automated anomaly detectors: Real-time detection covering authentication failure spikes, unusual transaction patterns, abnormal admin operations, settlement variances, webhook delivery anomalies and access-pattern outliers. Detections route to an on-call channel with named owners.
Structured audit logging: Every state-changing operation in the admin dashboard and the API is logged with operator identity, timestamp, source IP, target object and full diff. Logs are append-only, structured and queryable.
Thirteen-month retention: Audit logs are retained for thirteen months for forensic investigation, security review and regulatory enquiry response. Server logs (HTTP access, application errors) are retained for the same period.
Real-time alerting: Critical alerts page the on-call engineer immediately. Non-critical anomalies post to a security channel with response SLAs documented internally.
Integrity verification: Ledger balances are reconciled continuously by a dedicated process. Any non-zero net imbalance triggers an immediate alert and a hold on the affected settlement run until resolved.

Infrastructure

Where Fluxa runs, how it scales and how it recovers.

UK data residency: Production application, database and backup storage are all hosted in the United Kingdom by UK-region cloud providers. Personal data described in the privacy notice is processed and stored in the UK by default. No routine non-UK transfers.
Network isolation: Production runs in private virtual networks. Public endpoints are restricted to the application load balancer; the database, secrets store and internal services are not reachable from the public internet. Inter-service traffic is restricted to private VNets; mutual TLS is used between the application tier and the secrets store and where the underlying cloud primitive provides it.
DDoS and edge protection: The application sits behind an edge provider that absorbs common volumetric and application-layer attacks (SYN floods, UDP reflection, HTTP floods). A web application firewall blocks common attack patterns (SQL injection, XSS, traversal, SSRF probes).
Backups: Production database backups taken on a continuous basis with point-in-time recovery available for the previous seven days. Daily snapshots retained for ninety days on a rolling basis. Backups encrypted with AES-256 and stored in a separate UK region.
Disaster recovery: Documented recovery procedures with a Recovery Time Objective of four hours and a Recovery Point Objective of fifteen minutes for the production payment service. Recovery procedures are tested at least annually against the most recent backup set.
Business continuity: Business continuity plan covering personnel, supplier and infrastructure scenarios. Plan reviewed at least annually and after any material incident. Important Business Service mapping aligns with the payments partner’s operational-resilience obligations.

Domain and email security

SPF · strict policy on fluxapay.co.uk and subdomains; sending sources explicitly listed.
DKIM · all outbound mail signed with DKIM keys rotated on a defined schedule.
DMARC · published with policy p=reject on the apex domain; aggregate and forensic reports monitored.
DNSSEC · DNSSEC enabled on the fluxapay.co.uk zone where the registrar and authoritative provider support it.
MTA-STS and TLS-RPT · published for the mail-receiving domain to enforce TLS on inbound SMTP and to receive failure reports.

Incident response

What happens when something goes wrong, who is notified and within what timeframe.

Personal data breaches

In the event of a personal data breach, Fluxa will notify the Information Commissioner’s Office under UK GDPR Article 33 within seventy-two hours of becoming aware where the breach is likely to result in a risk to the rights and freedoms of data subjects. Affected individuals will be notified directly under UK GDPR Article 34 where the breach is likely to result in a high risk to their rights and freedoms.

Operational incidents

Detection: Through automated anomaly detectors, on-call paging, customer reports or the security@ inbox.
Containment: Initial response by the on-call engineer to stop the bleed: revoke credentials, isolate the affected service, halt the affected workflow.
Communication: Status page updated within minutes for customer-facing incidents. Affected merchants notified directly through the dashboard and by email. Payments partner notified for incidents affecting transaction processing.
Investigation: Forensic review using the audit log and structured event store. Root cause documented.
Post-incident review: Blameless review within five working days of resolution. Corrective actions tracked to closure. The post-incident summary is shared with affected merchants on request.
Regulatory notification: Where the incident triggers a regulatory notification obligation (ICO, FCA via payments partner, card schemes), the notification is sent within the timeframe set by the applicable regulation.

Responsible disclosure

If you find a vulnerability in Fluxa, please tell us first. The terms below describe how Fluxa engages with security researchers.

Where to report: Email security@fluxapay.co.uk. Include a clear technical description, steps to reproduce, the impact you have demonstrated and any non-destructive proof-of-concept. Encrypted submissions are welcome on request.
What to expect: Acknowledgement of receipt within two working days. An initial triage outcome (in scope, out of scope, duplicate) within ten working days. Status updates while the issue is being investigated and remediated.
In-scope targets: The production Fluxa web application, dashboard, public API, webhook delivery pipeline and the hosted checkout flow. The marketing website is in scope for security-impacting issues only.
Out of scope: Social engineering against Fluxa staff or merchants; physical attacks on Fluxa or its providers; denial-of-service testing; vulnerabilities in third-party services that Fluxa does not control; reports based on outdated browsers, scanner-only findings with no demonstrated impact, or general best-practice recommendations without a concrete vulnerability.
Safe-harbour position: Fluxa will not pursue civil or criminal action against researchers who comply with these terms, act in good faith, do not access or modify other users’ data, do not degrade the service and give Fluxa a window to remediate before public disclosure of ninety days from acknowledgement.
Bug bounty: Fluxa does not currently operate a paid bug-bounty programme. Recognition is offered with the researcher’s consent in a public researcher acknowledgement list once an issue is fixed.

Operational security

The procedural controls behind the technical ones.

Background checks: Pre-employment background screening on all staff with production access, proportionate to the role and to UK employment law.
Confidentiality agreements: Confidentiality and acceptable-use undertakings in every employment and contractor agreement.
Security training: Onboarding security training for every member of staff with production access. Refreshers at least annually and whenever a material change occurs in the threat landscape or the platform.
Joiner / mover / leaver controls: Access provisioning and de-provisioning routed through a documented process. Departing staff access revoked on the same day; the audit log records the revocation.
Sub-processor governance: Each sub-processor is engaged under a written Article 28 data-processing agreement and assessed against Fluxa’s minimum security baseline before onboarding. The sub-processor list is reviewed at least annually and is available to merchants under NDA.
Hardware: Company-issued laptops with disk encryption, automatic patching and remote-wipe capability. Personal devices are not used for production access.
Change management: Production changes deployed through code review, automated test pass, and a documented release process. Emergency hotfixes follow a defined out-of-hours path with post-hoc review.

Security roadmap

What Fluxa is committing to add over the first eighteen months from public launch.

SOC 2 Type II readiness: Targeted within the first twelve months from launch. Type I report to follow the readiness assessment; Type II report once the observation window completes.
ISO/IEC 27001 certification: Targeted in parallel with SOC 2 work. ISMS scope, statement of applicability and supporting controls documented as part of the same effort.
Public status page: Independent status page for the production API, dashboard and webhook delivery, with historical uptime, incident timeline and subscriber notifications.
Annual third-party penetration test: Engaged with a CREST-accredited or equivalent third-party tester at least annually. Summary letters available to merchants under NDA.
Bug-bounty programme: Paid programme once the public attack surface stabilises and an issue-triage capacity is in place to handle the inbound flow responsibly.
Customer-managed encryption keys (BYOK): Planned for merchants with specific data-residency or sovereignty requirements, dependent on the cloud-provider key management supporting the necessary primitives.
Cyber Essentials Plus: Targeted in the first six months from launch. The Cyber Essentials Plus certification is recognised across the UK public sector and a useful baseline for the rest of the controls on this page.
ISO/IEC 22301 (business continuity): Targeted alongside the ISO 27001 ISMS work. Provides an external attestation for the business continuity controls already described in the infrastructure section.
Public Trust Centre: A self-service portal for merchants to download the SOC 2 report, ISO certificates, current sub-processor list, the SBOM for the active production release and the most recent pen-test summary letter, under a click-through NDA.
SBOM publication: Once the Trust Centre is live, the production SBOM is published behind the same NDA gate. SBOMs are produced on every release; only the publication channel is on the roadmap.
HackerOne or equivalent bug-bounty programme: Public programme once the inbound triage capacity supports a higher report volume responsibly. Until then, security@fluxapay.co.uk remains the disclosure channel with the safe-harbour terms on this page.

Where this roadmap changes materially, it will be reflected on this page and summarised in the changelog.

Found something? Tell us first.

If you have identified a security vulnerability in Fluxa, email the security inbox below with a clear technical description and reproduction steps. Acknowledgement within two working days; initial triage outcome within ten working days. Safe-harbour terms set out in the responsible-disclosure section above.

Thanks, the security team will acknowledge within two working days.

Or email direct: security@fluxapay.co.uk

Privacy Updates Changelog Status Complaints