Product Checkout Real-time dashboard AI Workforce VCI verified identity Six payment states
Pricing
Developers Documentation API reference Webhooks SDKs Full docsComing soon Updates Changelog SandboxComing soon Migration toolComing soon
Compare Security
Company Our story Press Brand kit Updates Changelog
Live Try the demoComing soon Sign inComing soon Talk to us Get started

Live

Fluxa live operation status.

00d 00h 00m 00s

Pre-launch · sandbox monitoring active

Components.

All operational

Six service components powering Fluxa. Each has independent monitoring. Pre-launch, all components confirm the sandbox is reachable; production uptime begins counting from the first live payment.

Card authorisation Payments
30-day uptime –
p95 latency –
90-day history populates from first live payment.
Visa · Mastercard · Apple Pay · Google Pay through UK payments partner
Capture Payments
30-day uptime –
p95 latency –
90-day history populates from first live payment.
PAYMENT_RECEIVED → CAPTURED state transition, ledger-write inclusive
Settlement Payments
30-day uptime –
Settlement lag –
90-day history populates from first live payment.
SETTLING → SETTLED. Direct to merchant's GBP account. T+1 settlement is the aim, subject to approval and risk review
Refunds Payments
30-day uptime –
p95 latency –
90-day history populates from first live payment.
Full & partial refunds via dashboard or API. Issued back to original card
Webhooks Platform
24h delivery –
p95 delivery –
90-day history populates from first live payment.
HMAC-SHA256 signed. Trailing 1h success rate, first-attempt only
Dashboard & API Platform
30-day uptime –
p95 response –
90-day history populates from first live payment.
Merchant dashboard, admin console, public REST endpoints. London-hosted

Now

Awaiting first live merchant

Live operational metrics. All values reset to zero pre-launch and start counting at the first live merchant transaction.

Volume processed today awaiting data
£0
Resets at 00:00 UTC
Transactions today awaiting data
0
Authorisations · live count
Processing latency awaiting data
0ms
Median · auth + risk + capture
API response · p95 awaiting data
0ms
Public REST endpoint · p50 0ms
Webhook delivery awaiting data
0%
Trailing 1h · HMAC-signed
Avg saving vs Stripe awaiting data
£0
Per merchant, this month

Stream

Awaiting first event

Live event feed. Authorisation, capture, settlement, webhook and heartbeat events appear here as they happen, redacted of PII. The example rows below illustrate the format; real entries begin at the first live payment.

00:00:00 capture network is quiet. first live payment will appear here.
12:48:31 authorised card **** · GBP · merchant role m_a · 218ms p95
12:48:31 captured PAYMENT_RECEIVED → CAPTURED · ledger write 41ms
12:48:32 webhook delivered to endpoint m_a · HMAC ok · 89ms first attempt
12:49:07 settling CAPTURED → SETTLING · batched for T+1 GBP rail
12:49:09 heartbeat sandbox region ok · pre-launch · production heartbeat starts at first payment

Last 30 days.

Daily uptime history. Each square represents 24 hours of production monitoring.

No production data yet. The 30-day strip populates from the first live merchant payment onwards. Sandbox monitoring is active and reachable, but sandbox traffic is not counted toward this view.

Incidents

Past 90 days

Every production incident, grouped by day. Severity, affected components, timeline and the public RCA once published.

No production incidents to report yet.

Fluxa is in pre-launch sandbox testing. The first incident-eligible day is the first day a live merchant is processing payments.

All times UTC.

After an incident.

What we do when something goes wrong, and what we owe affected merchants afterwards.

  1. 1. Resolve and verify.

    Restore card processing first. Verify against synthetic traffic, real merchant traffic and a settlement test before declaring resolved. The page above flips back to operational only when verification passes.

  2. 2. Affected-merchant email.

    Within 24 hours, every affected merchant gets a direct email: what happened, when, what we did, what we still need to verify. Plain English. No "we experienced an issue" templating.

  3. 3. Public RCA for SEV-1 and SEV-2.

    Within 5 business days, the root-cause analysis goes public on this page, linked to the incident entry. Timeline, contributing factors, what we changed so it does not happen again. No blameless-language theatre, just the facts.

  4. 4. Account credit where due.

    Founding-cohort merchants get processing-fee credit for transactions impacted during a confirmed outage window. Applied automatically the next settlement after the RCA is published, not on request.

  5. 5. Fix lands in the changelog.

    Permanent remediation goes into the changelog with the originating incident ID linked. So you can see how an incident ten weeks ago shaped a real code change you can verify.

Incident severity.

How we classify incidents and what response cadence you can expect.

SEV-1
Critical.
Card processing down, settlement at risk, or any data exposure. Affects all merchants or a material proportion.
First response5 minutes
Status updatesHourly
Public RCA5 business days
SEV-2
Major.
A subset of merchants affected, or material latency on a core path. Feature unavailable but core still works.
First response15 minutes
Status updatesEvery 2 hours
Public RCA5 business days
SEV-3
Minor.
Non-customer-facing degradation or partial feature impact with a workaround. Caught by monitoring before merchants notice.
First response1 hour
Status updatesDaily
Public RCAInternal only
SEV-4
Informational.
No merchant impact. Cosmetic, internal, or anticipated. Logged for completeness.
First responseBest effort
Status updatesAs needed
Public RCANot required

Service level targets.

Service level commitments and the error budget. Measured on a rolling 30-day window once production traffic begins.

99.95%
Production card processing uptime
Measured rolling 30 days, excluding scheduled maintenance announced 72 hours in advance. Error budget: 21.6 minutes per month.
200ms
API response time at p95
Public REST endpoints, /v1/* surface, measured at the application layer. Authorisations, captures, refunds and reads all hold this target.
99.9%
Webhook delivery at 24 hours
HMAC-SHA256 signed events delivered to your endpoint within 24 hours, including retries. Exponential backoff at 1s, 4s, 16s, 1m, 5m, 30m, 2h, 8h.
500ms
Hosted checkout first paint
Time from request to first contentful paint on the hosted checkout page, measured from UK origin, p95.

Component status definitions. Every component on this page can be in one of five states:

Operational.
All checks return 2xx within target latency. The default state.
Degraded.
Latency exceeds target, or a non-critical subset of checks failing. Service still usable.
Partial outage.
A feature unavailable but core payment processing still works.
Major outage.
Card processing impaired. Merchants unable to take payment.
Maintenance.
Planned window announced at least 72 hours in advance.

Scheduled maintenance

Planned maintenance windows announced at least 72 hours in advance.

No scheduled maintenance.

Announced 72 hours before the window opens.

Status API and feeds.

Programmatic access to the same data this page shows. RSS, JSON, webhook subscribe, and a typed REST endpoint.

Current state, JSON.
GET https://fluxapay.co.uk/api/status

Snapshot of every component, latest status, last check time and overall page state. Returns 200 with JSON, cached 5 seconds at the edge.

Incident history, JSON.
GET https://fluxapay.co.uk/api/status/incidents

All incidents in the past 365 days. Pagination via ?before=<iso>. Each incident includes severity, components, timeline events and RCA URL once published.

RSS feed.
https://fluxapay.co.uk/live/feed.xml

Atom/RSS 2.0 feed of incidents and scheduled maintenance. One entry per state transition, signed with the canonical incident URL.

Webhook subscribe.
POST https://fluxapay.co.uk/api/status/webhooks

Register a URL to receive HMAC-SHA256-signed POSTs on every incident state change. Same retry curve as the merchant webhook system.

This page polls /api/status every 30 seconds via Server-Sent Events. On disconnect the client falls back to 60-second long-poll. The page reloads itself if the SSE connection is dropped for more than 5 minutes. See REST API reference, webhook signing, and help: system and status.

Question about an incident? Email us.

Every entry on this page is written by the engineer who fixed the incident. If you need more detail on a past incident, the full RCA, or have a question about an SLA target, write directly. We do not use a triage tier or a status-page chatbot. The reply comes from the same person who would be on call if it happened again.

Thanks, we’ll reply within one working day.
Or email direct: status@fluxapay.co.uk
Security Developer docs Help Updates Changelog