Fluxa Help

Question 1

Sign up and verification

Accepted Answer

Sign up with a UK business email at app.fluxapay.co.uk. You receive sandbox keys immediately and can integrate against test mode while KYB verification runs in parallel. KYB verification needs: company number (we auto-pull from Companies House), beneficial owner list, business bank account (for settlement), and proof of address for the primary contact. UK businesses only at launch. Typical verification time is one to three working days. Live keys are issued once KYB completes; sandbox keys keep working throughout.

Question 2

Sandbox and testing

Accepted Answer

Every Fluxa account gets sandbox keys from minute one. The sandbox mirrors production exactly: same API surface, same webhook events, same payment-state machine, same dashboard. Only the money is fake. Test cards simulate every scheme response: successful authorisation, soft decline (retryable), hard decline (lost or stolen card), 3DS challenge required, 3DS frictionless, AVS mismatch, and chargeback flow. Sandbox data is wiped nightly at 02:00 UK time so a clean state is always close by. Live and sandbox use different key prefixes (sk_test_ vs sk_live_) so accidental cross-environment requests fail loudly.

Question 3

First payment

Accepted Answer

Three integration paths, pick whichever fits your stack: hosted checkout (one HTTP call, we render the form, you handle the redirect), embedded SDK (drop-in component in your page, no PCI scope expansion), or direct API (full control, server-to-server, hosted checkout iframe for the card field). The quick-start on /developers#quick-start walks all three with copy-paste Node.js, Python and curl. Time from sandbox key to working payment is typically under five minutes.

Question 4

Going live

Accepted Answer

Going live means swapping sk_test_ for sk_live_ and updating your webhook endpoint. That is it. Same API surface, same payload schemas, same event types. Before flipping, make sure: KYB verification is complete (status visible in dashboard), production webhook endpoint validates HMAC signatures, you have tested all three failure paths (decline, 3DS challenge, chargeback) in sandbox, and you have a recovery procedure if your endpoint goes down. Going live does not require code review or a sales call. Click the toggle in your dashboard.

Question 5

Test cards

Accepted Answer

The standard test card is 4111 1111 1111 1111 (Visa) with any future expiry, any CVV and any postcode. It succeeds with no 3DS challenge by default. To simulate specific outcomes, use different last-four digits: ...0002 for hard decline, ...0010 for insufficient funds (soft decline, retryable), ...3155 for 3DS frictionless approval, ...3220 for 3DS challenge required, ...0259 for chargeback after settlement. The complete table covering Mastercard, AVS responses, currency-conversion fees and dispute reason codes is on the developer reference.

Question 6

Onboarding timeline

Accepted Answer

Sign up is instant, sandbox keys are immediate. KYB verification typically completes within one to three working days for straightforward UK limited companies and sole traders. Documents needed: business registration (Companies House number for limited companies, HMRC UTR for sole traders), beneficial owner list with passport or driving licence, UK business bank account for settlement, and proof of address for the primary contact. Higher-risk verticals (financial services, gambling, regulated industries) take longer because they require additional checks. We tell you at signup if your MCC falls into one of those categories.

Question 7

3D Secure and SCA

Accepted Answer

3D Secure 2 is mandatory on most UK card-not-present payments under the Payment Services Regulations 2017 implementation of Strong Customer Authentication. Fluxa runs 3DS 2 on every payment by default and handles the challenge flow inline: frictionless authentications complete with no visible step; challenges show the issuer's page (biometric, OTP or password). Liability for fraud chargebacks shifts to the issuer on authenticated payments. Exemptions are available for low-risk transactions (TRA, under £30, trusted beneficiary) and Fluxa applies them automatically where allowed. You do not configure 3DS; you configure the business rules around exemption appetite.

Question 8

Apple Pay and Google Pay

Accepted Answer

Apple Pay and Google Pay work out of the box on hosted checkout and embedded SDK. The wallet shows when the visitor's device supports it; otherwise the card form is presented. Same headline rate as a direct card payment. No premium for wallet payments. The wallet wraps a Visa or Mastercard credential with a device-bound token plus a cryptogram, and biometric in-device authentication counts as SCA, so the customer never sees a 3DS challenge. To enable on your own domain, the domain has to be verified with Apple Pay. Fluxa walks you through that in a single dashboard step.

Question 9

Recurring billing

Accepted Answer

Subscription billing engine, customer self-serve cancellation, automated dunning on failed charges, and SCA-compliant card-on-file storage for repeat charges. Recurring charges use the MIT (merchant-initiated transaction) flag with the scheme, exempt from SCA on the recurring leg as long as the initial transaction was authenticated. Soft declines retry on a configurable schedule (default: day 1, day 3, day 7) before the subscription pauses. Failed recurring payments trigger an email to the cardholder asking them to update their card; the dunning template is editable per merchant.

Question 10

MOTO and phone orders

Accepted Answer

Mail Order / Telephone Order payments are supported but flagged differently to the scheme. MOTO transactions do not benefit from a 3DS liability shift, so the merchant carries the full chargeback risk on fraud disputes. To process a MOTO payment in the dashboard, open the \"New payment\" flow and tick the MOTO box; the API takes a payment_method.type: moto flag. Card details are entered by the merchant, not the cardholder, and there is no 3DS step. MOTO is permitted only for specific MCCs and is subject to enhanced risk monitoring. Not enabled by default; ask support to flip it on for your account.

Question 11

Failed payments

Accepted Answer

Two categories. Soft declines (insufficient funds, daily limit, issuer outage, SCA required) are recoverable on retry. Hard declines (card reported lost or stolen, blocked by issuer, closed account) are final and should not be retried. Every failed payment returns a structured failure_code and a retryable boolean. Your dunning logic should retry only when retryable: true. Recurring billing retries default to three attempts on soft declines; hard declines pause the subscription immediately. Generic decline messages (no specific code) are returned for privacy reasons; the dashboard shows the full scheme response.

Question 12

Card-on-file

Accepted Answer

Storing a cardholder credential after an initial cardholder-authenticated transaction so you can charge it again later. Every subsequent charge carries a stored-credential indicator and a CIT (customer-initiated) or MIT (merchant-initiated) flag. Required for recurring billing, click-to-buy, and any post-purchase upgrade. Fluxa vaults the credential in the payments partner's PCI Level 1 environment; you receive a token, never card data. Cards stored before SCA (pre-September 2019) need to be re-authenticated by the cardholder before the next MIT charge. Fluxa handles that re-auth flow automatically when needed.

Question 13

Settlement timing

Accepted Answer

Standard settlement uses BACS three-working-day cycle: capture today, settle to your bank three working days later. Faster Payments accelerated settlement is available for an additional fee, typically settling the next working day. Settlement happens daily for all captured transactions from the previous business day. Weekends and UK bank holidays push settlement out by one working day each. Refunds within the settlement window net against the outgoing batch; refunds after settlement create a debit on the next batch.

Question 14

Settlement reference

Accepted Answer

Format is STL-YYYY-MM-DD-FX-NNNNN. YYYY-MM-DD is the settlement date, FX is the payments partner partner code, and NNNNN is the per-day counter. The reference shows on your bank statement next to the credit line so you can match it to a specific settlement batch in the Fluxa dashboard with one grep. Each batch report shows every payment included, every refund netted, every fee deducted, and the net amount that arrived. If a settlement batch is missing from your bank statement, search by the date portion of the reference; banks occasionally truncate the full string.

Question 15

Fees and statements

Accepted Answer

Flat-rate pricing, no per-transaction fees layered on top, no monthly subscription, no setup fee. 1.8% flat for UK businesses. Monthly statements are generated on the first of each month and emailed to billing contacts. Each statement lists every settlement batch, every dispute fee, and any scheme fees that passed through. Downloadable as PDF and CSV. Operational fees (chargebacks, refund scheme fees, dispute arbitration) are itemised separately so you can see exactly what each fee is for. No hidden fees, no surprise charges.

Question 16

Reconciliation

Accepted Answer

Every settlement batch generates a CSV settlement report you can download from the dashboard or pull from the API. The report lists every payment in the batch with its ID, amount, fee, and net contribution. The ledger state model exposes the full lifecycle: AUTHORISED, CAPTURED, SETTLING, SETTLED. A payment is on your dashboard but not yet in a settlement report means it has not settled yet; filter by SETTLED to see what is reconciled. Discrepancies between dashboard total and bank credit are rare and almost always explained by refunds posted after settlement. Email support@fluxapay.co.uk with the settlement reference if anything looks off.

Question 17

Failed settlements

Accepted Answer

If a settlement does not arrive on the expected day, the usual cause is a bank holiday, the BACS cut-off (16:30 UK on the working day before), or a name-on-account mismatch flagged by your bank. Check the dashboard settlement page first: it will show status SETTLING (still in transit), SETTLED (payments partner has released it; your bank may be holding it for review), or FAILED with a reason. If it shows SETTLED but is not in your bank account by end of next working day, contact your bank with the settlement reference. For payments partner-side delays (rare), check /live for any active incidents. Otherwise email support with the settlement reference.

Question 18

Bank account details

Accepted Answer

Updating the settlement bank account requires re-verification because it is the highest-risk change on an account. The process: submit new bank details in the dashboard, upload a recent bank statement or void cheque showing the account in the business name, wait for confirmation (typically one working day). New settlements route to the new account from the confirmation timestamp. In-flight settlements already initiated to the old account continue to that account. The account name must match your registered business name on Companies House. Personal accounts are not accepted for limited company settlements.

Question 19

Refunds

Accepted Answer

Issue full or partial refunds from the dashboard or via the API. Refunds carry their own scheme fee (typically 10-15p depending on card type) but no platform fee from Fluxa. Refunds appear on the cardholder's statement within three to ten working days depending on the issuer. The credit references the original transaction ID and the original merchant descriptor. Refunds within the settlement window net against the outgoing batch. Refunds after settlement create a debit on the next settlement; if there is insufficient outgoing volume, the difference is direct-debited from your operating account.

Question 20

Chargebacks

Accepted Answer

A chargeback is a forced reversal of a transaction initiated by the cardholder via their issuing bank. You get notified within hours of the issuer raising it, with the reason code, the amount, and the response window. Scheme reason codes group into: fraud (no liability shift on non-3DS payments; protected on authenticated 3DS payments), authorisation (issuer claims auth was not granted), processing errors (technical), and consumer disputes (goods not received, not as described). Chargebacks carry a fee (typically £15-25) win or lose. The dashboard shows your chargeback ratio and a warning when you are approaching scheme monitoring thresholds (1% by count or 1% by value for Visa, 1.5% for Mastercard).

Question 21

Representment

Accepted Answer

Representment is your response to a chargeback: evidence submitted within the scheme's response window (typically 7-30 days depending on reason code) that the original transaction was legitimate. Strong evidence includes: signed delivery receipt, IP/device fingerprint matching previous successful orders, photo or screenshot of goods or service delivery, cardholder communications referencing the transaction, and any AVS or 3DS authentication data. Fluxa builds the representment package in the dashboard, you add the evidence files, we submit through the payments partner. Win rates vary by reason code; we publish ours on /developers#disputes.

Question 22

Dispute fees

Accepted Answer

Three fees on a chargeback. The chargeback fee (£15-25 depending on scheme) is charged when the chargeback is raised, win or lose. The arbitration fee (around £250) applies only if a case goes to scheme arbitration after a second chargeback. The reversal fee is refunded to you if you win. If you win the representment, the original transaction amount is credited back to your settlement. The chargeback fee is not refunded; that pays for the scheme processing. Excessive chargeback ratios trigger scheme monitoring programmes (Visa VAMP, Mastercard ECP) which add monthly programme fees on top.

Question 23

Pre-arbitration

Accepted Answer

If the cardholder rejects your representment, the case can escalate to pre-arbitration (also called second chargeback). The cardholder's issuer reviews your evidence and decides whether to send it to scheme arbitration. At this stage the cost rises sharply. The scheme charges a non-refundable arbitration fee (around £250 per case) plus admin fees. Win or lose, those fees stick. Most pre-arbitration cases are resolved without going to full arbitration because the additional cost is rarely worth it for the merchant or the issuer. Fluxa flags pre-arbitration cases prominently in the dashboard with a recommendation: accept and write off, or contest with stronger evidence.

Question 24

Fraud vs service disputes

Accepted Answer

Two very different disputes need different responses. Fraud chargebacks (reason codes 10.x on Visa, 4837 on Mastercard) claim the cardholder did not authorise the transaction. If 3DS authenticated, you have liability shift and almost always win on representment with the 3DS data alone. If not authenticated (MOTO, exempt low-value, recurring without prior auth), you carry full liability. Service-quality chargebacks (goods not received, not as described, defective, refund not issued) carry no liability shift even with 3DS. The defence is delivery proof, customer communications, and your terms-of-service. These have higher merchant win rates than fraud disputes.

Question 25

Team members and roles

Accepted Answer

Three roles per account. Owner: full access including bank details, billing, and account closure (one per account, transferable). Admin: full operational access excluding bank details and closure. Operator: payment ops, refunds, dispute response; no settings access. Invite teammates from Settings > Team. Invitations go by email with a one-time signup link; the invitee picks their own password and enrols in 2FA at first login. Every action is audit-logged with actor, IP, user agent and outcome. The audit log is exportable to your SIEM via webhook for compliance retention.

Question 26

Two-factor authentication

Accepted Answer

TOTP-based 2FA on every Fluxa account. SMS 2FA is not offered (SMS is a known weak factor under PSRs 2017 SCA requirements). At first login, you scan a QR code with your authenticator app (Authy, 1Password, Google Authenticator, Bitwarden, etc.) and confirm the rolling 6-digit code. Ten single-use recovery codes are generated; save them in your password manager. 2FA is enforced for Owner and Admin roles by default; Operators can be policy-required to enrol via the Team settings. Account recovery without your 2FA device requires a recovery code or a human-verified flow.

Question 27

Lost access

Accepted Answer

If you lose your 2FA device: use one of the ten single-use recovery codes from initial setup. Each works once, can be regenerated after use, and should be kept in a password manager not on the device that does TOTP. If you have lost both the device and the recovery codes, the human-verified recovery path applies. Email support from the email address on file with: your account name, the bank account details for settlement, recent transaction IDs, and an ID document. Human-verified recovery takes one to two working days. It is deliberately not fast: the slowness is the security.

Question 28

Closing your account

Accepted Answer

Account closure is initiated by the Owner from Settings > Account > Close. Closure does not happen immediately: there is a 30-day wind-down during which active subscriptions complete, in-flight settlements process, and outstanding disputes resolve. Closed account data is retained for the regulatory minimum (six years under Money Laundering Regulations 2017 for AML records; seven years for financial records under HMRC). Personal data is anonymised after the retention period. If you change your mind during the 30-day wind-down, you can reactivate from the dashboard. After 30 days, reactivation requires a new application.

Question 29

IP allowlisting

Accepted Answer

Restrict dashboard access and API key usage to specific IP ranges or CIDR blocks. Configurable per API key (so a production key can be locked to your production server IPs while the dashboard remains accessible from anywhere your team logs in). Matching is bitwise CIDR, supporting individual IPs (203.0.113.42), ranges (203.0.113.0/24), and IPv6. Deny-by-default once enabled. A break-glass override is available: if you lock yourself out, the Owner can disable allowlisting through a recovery flow that requires re-verifying the account email plus a 2FA challenge.

Question 30

Audit log

Accepted Answer

Every action on a Fluxa account is logged: actor (user ID and email), timestamp (millisecond precision), IP and user agent, action (string identifier), affected resource, and outcome (success or specific failure code). The log is browseable in the dashboard with filtering and search, exportable as CSV, and streamable to your SIEM via a webhook subscription to the audit.log.created event. Retention is for the regulatory minimum: six years for actions touching customer data (UK GDPR Article 30 records of processing) or financial transactions (HMRC). Immutable: log entries cannot be edited or deleted by any role including the Owner.

Question 31

API keys

Accepted Answer

Three key types. Publishable (pk_) for client-side use, exposes only the operations safe to do from a browser. Secret (sk_) for server-side use, full account access; never put one in client code. Restricted (rk_) for least-privilege automation; scope it to specific operations (e.g. read-only, refunds-only). Keys come in test and live flavours (sk_test_ vs sk_live_). Mixed-mode calls fail loudly with a clear error. Rotation: generate a new key, deploy it, revoke the old one. Old and new can coexist briefly so there is no downtime window. Keys are shown once at creation; if lost, you have to generate a new one.

Question 32

Webhooks

Accepted Answer

Every state change emits a webhook to the URL you configured: payment created, captured, settling, settled, failed, refunded, chargeback raised, dispute updated, and so on. 29 event types at last count, full catalogue on /developers#webhooks. Each event is signed with HMAC-SHA256. Your endpoint must validate the signature before trusting the payload. Sample verification code is provided in Node.js, Python, PHP, Ruby, Go and C#. Delivery is at-least-once with exponential backoff (1, 2, 4, 8, 16, 32 minutes). Pair the event ID with your idempotency layer to handle duplicates safely. Failed delivery after 24 hours raises a dashboard alert.

Question 33

SDKs and tools

Accepted Answer

Official Node.js SDK at launch (npm install @fluxapay/node). Python, PHP and Ruby SDKs in development. The API itself is REST + JSON so any HTTP client works against it. OpenAPI 3.1 spec is published at docs.fluxapay.co.uk/openapi.yaml for generating clients in any language. Postman collection at docs.fluxapay.co.uk/postman.json for interactive testing. Webhook signature verification samples in six languages, a CLI helper for sandbox testing, and a hosted-checkout JS SDK for embedded payments are all in the developer docs.

Question 34

Errors and rate limits

Accepted Answer

Errors return a stable error code (card_declined, insufficient_funds, 3ds_authentication_required) plus a human-readable message and a documentation URL. Cards declines also include a retryable boolean. Rate limits are per-key per-second with a daily ceiling. The default for new accounts is 100 requests/second; live accounts can request an increase. Limit headers (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset) on every response. Exceeding the limit returns HTTP 429 with a Retry-After header. Implement exponential backoff; the SDK does this automatically.

Question 35

Idempotency

Accepted Answer

Send an Idempotency-Key header on every POST that creates or modifies. Any UUID works; pick one your code can deterministically reproduce on retry (e.g. a hash of the order ID). Fluxa stores the response for 24 hours keyed by the idempotency key. A repeat request with the same key returns the original response, not a new operation. This makes retries safe even if the network ate the original response after the work completed. GET and DELETE do not need idempotency keys: GET is idempotent by definition, DELETE is idempotent by API design (deleting a deleted resource is a no-op, not an error).

Question 36

Sandbox vs live

Accepted Answer

Sandbox and live are completely separate environments. Separate keys, separate data, separate webhook URLs, separate dashboards. Sandbox data is wiped nightly; live data is retained for the regulatory minimum. The API surface is identical: same endpoints, same payloads, same event types, same error codes. The only difference is that sandbox returns simulated scheme responses (configurable via test card numbers) and does not move real money. Switch environments with a single env variable: FLUXA_API_KEY=sk_test_... vs FLUXA_API_KEY=sk_live_.... No code changes between sandbox and live.

Question 37

PCI compliance

Accepted Answer

Hosted checkout and embedded SDK keep merchants in PCI SAQ-A scope, the lightest tier of PCI DSS, available to merchants who fully outsource cardholder data handling. How it works: card data is entered into an iframe served from the payments partner's PCI Level 1 environment, tokenised, and returned to your server as an opaque token. Card data never touches your servers, your database, or your logs. If you use direct API with raw card data (rare; almost no one needs this), you are in SAQ-D scope and we will tell you so explicitly during onboarding. We do not enable raw-card flows by default.

Question 38

Data protection (UK GDPR)

Accepted Answer

Fluxa is a data controller for merchant account data and a data processor for cardholder data on the merchant's behalf. UK GDPR Article 28 Data Processing Agreement is in your terms. UK-only data residency: all merchant and cardholder data is stored in UK data centres (Neon Postgres EU-West-2 region). No data is transferred outside the UK without an explicit adequacy decision under UK GDPR. Data subject access requests (DSARs) are honoured within 30 days; submit at /contact#data. Retention schedules vary by data category: AML records six years, financial records seven years, marketing data one year after last interaction.

Question 39

Complaints procedure

Accepted Answer

Fluxa's complaints process aligns with FCA DISP rules under the Payment Services Regulations 2017. Submit a complaint by emailing complaints@fluxapay.co.uk or via the complaints form on /complaints. Acknowledgement within three working days. Resolution within fifteen working days for the majority of complaints, thirty-five working days for the most complex (we will tell you within fifteen days if your case will take longer). You can escalate an unresolved complaint to the Financial Ombudsman Service within six months of our final response. The FOS is independent, free for consumers, and binding on Fluxa.

Question 40

Anti-money laundering

Accepted Answer

Fluxa operates under the UK Money Laundering Regulations 2017 (MLR 2017) via the FCA authorisation of the payments partner. Every merchant goes through KYB checks at onboarding: company verification, beneficial owner identification, PEP and sanctions screening. Transaction monitoring runs in real time on every payment. Patterns flagged for review include unusual transaction sizes, sudden volume spikes, structuring (sub-threshold layering), and recipient/sender risk indicators. Suspicious activity reports (SARs) are submitted to the National Crime Agency. Affected merchant accounts may be frozen pending review; we cannot tell you a SAR has been submitted (legally prohibited).

Question 41

Sub-processors

Accepted Answer

The full list of third-party services that touch Fluxa data, kept current on /security#subprocessors. Each has a UK GDPR Article 28 contract and is included in Fluxa's Data Processing Agreement. Categories include: the payments partner (card data processing, PCI Level 1), Neon (Postgres database, EU-West-2), Cloudflare (CDN and WAF), Fly.io (container hosting), Zoho (transactional email), and a small number of additional services for specific subsystems. Any change to the sub-processor list triggers a 30-day notification email to merchants. If you object to a new sub-processor, you have the right to terminate without penalty.

Question 42

Financial Ombudsman Service

Accepted Answer

The Financial Ombudsman Service is the UK's independent dispute-resolution body for financial services complaints. Free for consumers and businesses below a turnover threshold (currently £6.5m). You can escalate to the FOS if you are not satisfied with Fluxa's final response to a complaint, within six months of the final response date. Apply at financial-ombudsman.org.uk. The FOS decision is binding on Fluxa once accepted. We pay any FOS-awarded redress regardless of outcome on our part. The FOS award limit is currently £430,000 for complaints from April 2024 onwards.

Question 43

Live status page

Accepted Answer

Real-time uptime by component: API, dashboard, hosted checkout, webhook delivery, settlement. Rolling 90-day chart per component, plus the all-time incident archive with root-cause summaries. Status pings every 30 seconds from monitoring nodes in London, Amsterdam, Frankfurt and Dublin. Component status updates within a minute of a degradation being detected. Incident posts within five minutes of an incident being confirmed by on-call. We do not paint the status page green during partial outages. If a single endpoint is degraded, the relevant component shows degraded.

Question 44

Incidents

Accepted Answer

Every incident follows the same lifecycle: detection (monitoring alerts or merchant report), confirmation by on-call (within five minutes), public post on /live, mitigation in progress, mitigation complete, monitoring, resolved. Affected merchants are notified by email to the registered operations contact, by dashboard banner, and by status page update. Severity-one incidents (full outage, settlement frozen, security breach) also trigger SMS to the registered phone number if provided. Within seven days of an incident closing, a post-incident report is published on /live with timeline, root cause, customer impact, and remediation work.

Question 45

Maintenance windows

Accepted Answer

Planned maintenance happens off-peak UK hours (typically 02:00-04:00 UK time on a Tuesday or Wednesday) and never on a settlement day. Most maintenance is zero-downtime; the few that require brief outages are announced at least seven days in advance. Notification goes to all merchants by email and dashboard banner. The maintenance window shows on /live with start time, expected duration, affected components, and what to expect (often nothing visible to merchants because we deploy behind a rolling load balancer).

Question 46

Incident notification

Accepted Answer

How affected merchants find out about an incident. Email goes to the registered operations contact within five minutes of the incident being confirmed. Dashboard shows a top-banner with link to the status page. Status page (/live) updates with severity, affected components, and timeline. Severity-one incidents (full outage of a critical component) also trigger SMS to the registered phone number if you have provided one. Severity-two and below do not SMS by default. If you do not want incident emails, you can unsubscribe in dashboard preferences, but the dashboard banner cannot be disabled because it is the primary alerting channel.

Question 47

Status feed (RSS / JSON)

Accepted Answer

Programmatic access to the status feed for monitoring stacks that do not read email. RSS feed at status.fluxapay.co.uk/feed.rss for subscription in any feed reader or notification service. JSON feed at status.fluxapay.co.uk/feed.json for direct integration with your alerting (Slack, PagerDuty, Opsgenie, custom). Feed updates within a minute of any status change. Includes incident metadata: severity, affected components, mitigation status, and post-incident report URL once published.

Question 48

Historical uptime

Accepted Answer

Rolling 90-day uptime by component on /live: API, dashboard, hosted checkout, webhook delivery, settlement. Each component shows percentage uptime, longest incident, and total downtime minutes. All-time incident archive with severity, duration, affected components, root cause, and remediation. Searchable by date or component. Useful for vendor evaluations or audit evidence. Fluxa publishes the raw data, not a marketing version. Bad months are visible; we do not hide them.

Find the answer. Quickly.

Getting started.

Sign up and verification

Sandbox and testing

First payment

Going live

Test cards

Onboarding timeline

Accepting payments.

3D Secure and SCA

Apple Pay and Google Pay

Recurring billing

MOTO and phone orders

Failed payments

Card-on-file

Money and settlement.

Settlement timing

Settlement reference

Fees and statements

Reconciliation

Failed settlements

Bank account details

Disputes and refunds.

Refunds

Chargebacks

Representment

Dispute fees

Pre-arbitration

Fraud vs service disputes

Account and security.

Team members and roles

Two-factor authentication

Lost access

Closing your account

IP allowlisting

Audit log

Developers.

API keys

Webhooks

SDKs and tools

Errors and rate limits

Idempotency

Sandbox vs live

Compliance and regulation.

PCI compliance

Data protection (UK GDPR)

Complaints procedure

Anti-money laundering

Sub-processors

Financial Ombudsman Service

System and status.

Live status page

Incidents

Maintenance windows

Incident notification

Status feed (RSS / JSON)

Historical uptime

Cannot find what you need? Email us.

Sign up and verification

Sandbox and testing

First payment

Going live

Test cards

Onboarding timeline

3D Secure and SCA

Apple Pay and Google Pay

Recurring billing

MOTO and phone orders

Failed payments

Card-on-file

Settlement timing

Settlement reference

Fees and statements

Reconciliation

Failed settlements

Bank account details

Refunds

Chargebacks

Representment

Dispute fees