The Sweepstakes Casino Platform Provider SLA Checklist

Demand a sweepstakes casino platform provider SLA that measures 99.95% uptime on payment transaction success rate, not server ping; defines an outage as three consecutive failed minutes below a 95% success threshold; commits to a 15-minute first response, named escalation contacts, 10% monthly fee credits per incident, and quarterly tested failover.

What does a sweepstakes casino platform provider SLA actually cover, and what does it quietly exclude?

Most platform SLAs you'll be handed in a first draft cover one thing: the availability of the provider's own application layer, measured by their own monitoring, excluding anything they route through a third party. Read the exclusions list before the uptime number. In practice it will exclude the acquirer, the ACH originator, the KYC vendor, the card processor, the CDN, "force majeure," any degradation "caused or contributed to" by your integration, and all scheduled maintenance.

That exclusion set is where the loophole lives. In a sweepstakes context, virtually every incident that stops redemptions originates in the payments chain rather than the game server. If your provider disclaims responsibility for every link in that chain, you have bought an SLA that guarantees the part of the stack that rarely breaks.

Three fixes to demand in redlines:

1. Bring third parties in scope. Language: "Provider's uptime obligation applies to the end-to-end payment path, including subprocessors, acquirers and originators engaged by Provider, regardless of whether the proximate cause lies with Provider or its subprocessor." If the provider chose the vendor, the provider owns the vendor's downtime.

2. Cap scheduled maintenance. No more than four windows per month, each ≤60 minutes, outside 18:00–02:00 local peak, with 72 hours' written notice. Any window that overruns by more than 15 minutes converts to an unscheduled outage.

3. Delete "caused or contributed to." Replace with "solely caused by." As drafted, any incident where your API call was in the trace becomes your fault.

How should payment uptime for a sweepstakes casino be measured?

The measurement definition matters more than the percentage. A 99.99% figure computed on HTTP 200 responses from a status endpoint is worth less than 99.5% computed on completed redemptions.

Specify the metric in the SLA itself, not in a linked policy the provider can amend unilaterally:

"Payment Uptime" means, for each calendar month, the number of one-minute Measurement Intervals in which the Payment Transaction Success Rate equalled or exceeded 95%, divided by the total number of Measurement Intervals in the month, expressed as a percentage. "Payment Transaction Success Rate" means successfully completed Purchase and Redemption transactions divided by total attempted transactions, excluding only transactions declined by the issuer for insufficient funds or by Customer's own risk rules.

Four supporting terms make that clause hold up:

• Attribution of declines. Every decline code must map to either "issuer/customer" or "provider/subprocessor." Unmapped codes default to provider. Without this, soft declines get reclassified as customer-side and your outage disappears.

• Independent measurement rights. You get to compute uptime from your own logs, and where the two figures differ by more than 0.1 percentage points, the parties reconcile within five business days using your transaction-level data as the tiebreaker.

• Separate targets per flow. Deposits, redemptions and KYC/verification each get their own target. Redemption failure is the one that generates complaints, chargeback exposure and regulatory attention, so it should carry the highest target — 99.95% or better.

• No monthly averaging away of a bad day. A six-hour redemption outage on a Sunday is 0.8% of a 31-day month. It clears a 99% SLA comfortably. This is why you also need a per-incident maximum duration, covered below.

What counts as an outage, and who starts the clock?

An outage, properly defined, means any period in which the Payment Transaction Success Rate falls below the contractual threshold for three consecutive Measurement Intervals, whether or not the provider's status page reflects it. Write that sentence in. Providers otherwise define an outage as "a Severity 1 incident acknowledged by Provider," which lets them acknowledge late and shorten every duration calculation.

Non-negotiables on the clock:

• Start: first failed interval detected by either party's monitoring, or your ticket timestamp, whichever is earlier.

• Stop: sustained restoration of the success rate for 30 consecutive minutes. Not "when the fix is deployed."

• Partial degradation counts. A 60% success rate is an outage with a 40% weighting, not a "performance issue" outside the SLA. Insist degradation is measured proportionally.

• Per-incident cap: any single outage exceeding four hours triggers a fixed remedy independent of the monthly credit calculation, plus mandatory root-cause analysis.

The trade-off underneath that table is not really cost versus reliability — it is credibility. A provider that offers 99.99% on payment transaction success without asking for a narrower metric either hasn't read your definition or won't honour it. A provider that pushes back to 99.9% while accepting your measurement method, decline attribution and clock rules is offering you something better than the higher number. Watch which lever they defend. And note that 99.5% on redemptions still permits three and a half hours of failed payouts monthly, spread across peak weekends, without breaching anything.

What igaming payment outage failover terms belong in the contract?

Redundancy claims are the least verified section of every platform pitch. "Multi-region," "N+1" and "automatic failover" mean nothing unless the SLA specifies who triggers it, how long it takes, and how often it is proven.

Demand:

• A stated Recovery Time Objective and Recovery Point Objective for the payment path specifically. RTO ≤15 minutes, RPO of zero for financial transactions. Payments RTO is a different number from platform RTO; require both separately.

• Automatic processor failover with a named secondary. The secondary acquirer or originator is identified in the contract. Cascading logic triggers on success-rate thresholds, not manual approval.

• Tested failover, quarterly, with evidence. Language: "Provider shall conduct a full failover test of the payment path no less than quarterly, provide Customer with the test report within ten business days, and remediate all findings within thirty days." A failover test, properly defined, means live traffic served by the secondary path for a sustained period — not a tabletop exercise or a documentation review.

• Your right to run your own rail. Some platform agreements contain exclusivity language over payment processing. Strike it. You need the contractual freedom to maintain a redundant payout rail for casino operators that terminates outside the provider's stack entirely, and to route to it at your discretion during an incident without triggering a breach.

That last point is the one providers resist hardest and the one that matters most. Provider-side failover moves you from their primary acquirer to their secondary acquirer. If the failure is in their orchestration layer, their ledger, or their commercial relationship with a sponsor bank, both paths are down together. Correlated failure is the normal case in igaming payment outage failover, not the exception.

What does a credible sweepstakes platform incident response commitment look like?

Sweepstakes platform incident response should be specified as a set of timestamps with named humans attached, not a promise of "prompt attention."

• Severity definitions written by you. Sev 1 = redemptions failing above 5% or deposits failing above 10%. Not "critical business impact as determined by Provider."

• First response: 15 minutes, Sev 1, 24/7/365. Response means a named engineer with system access acknowledging in your shared channel — not an auto-reply ticket number.

• Escalation ladder in the contract. Named on-call lead at 15 minutes, engineering manager at 60, CTO or VP Engineering at 120, executive sponsor at 240. Include mobile numbers in a schedule updated quarterly. If a name changes, they notify you within five business days.

• Communication cadence: every 30 minutes during Sev 1, whether or not there is news, including a current estimate of affected transaction volume.

• RCA in five business days, containing timeline, contributing factors, affected transaction counts and dated remediation commitments. Not a paragraph on a status page.

• A dedicated channel (Slack Connect or equivalent) that exists before the incident, with your team already in it.

If a provider will not put mobile numbers and a 15-minute Sev 1 response in writing, you are buying business-hours support with a 24/7 label. Price accordingly, or talk to LightningPay about a standby payout rail that doesn't depend on their pager rotation.

How should service credits and exit rights be structured?

Service credits are a pricing mechanism, not a remedy. A 10% credit on a monthly platform fee will not cover one weekend of failed redemptions, player-support load and reputational damage. Negotiate them anyway — they create internal accountability on the provider's side — but do not treat them as the protection.

Structure them as: automatic application without a claim requirement (most drafts require you to claim within 30 days or forfeit); calculated on total monthly fees including transaction fees, not base subscription only; uncapped through 100% of monthly fees for outages exceeding eight hours; and stacking across separate incidents.

Then put the real teeth elsewhere:

• Chronic failure termination. Three consecutive months below target, or any single outage exceeding 12 hours, gives you termination for cause with no early-termination fee and no obligation on remaining committed volume.

• Fee suspension. No platform fees accrue during any Sev 1 outage.

• Data and configuration portability on demand, not on exit — transaction history, player records, ledger data in documented formats, deliverable within 10 business days of any request. This turns a theoretical exit right into a usable one, which is the point of planning for switching platform providers without breaking payments before you need to.

• Annual SLA review with the right to renegotiate targets upward if incident frequency exceeds a stated threshold.

The rail that runs when the platform's doesn't

LightningPay operates instant, always-on settlement over Lightning and stablecoin rails that runs independently of your platform provider's card and ACH stack. It is not an orchestration layer sitting on the same acquirer relationships — it terminates outside them.

That independence is the entire point in an SLA discussion. Every clause above governs what happens after an outage: how it is measured, who is called, what you are credited. None of it puts money into a player's hands during the incident. A second rail does. When the provider's originator drops ACH batches or their orchestration layer starts timing out, redemptions route to a path with no shared dependency, and the blast radius contracts from days of backlog to minutes of elevated latency.

We do not claim 100% uptime; nobody credible does. What changes is correlation. Two independent rails fail independently, and that is the only structural improvement available to you in this negotiation.

Final thoughts

Read every SLA as a price list for failure rather than a commitment to prevent it — the provider has calculated the credit exposure and decided it is cheaper than the engineering. That reframing tells you where to spend negotiating capital: on measurement definitions, decline attribution, clock-start rules and tested failover evidence, because those are the terms that change provider behaviour before an incident rather than compensating you after one. A bigger credit percentage costs the provider nothing to concede and returns you a rounding error on a bad weekend. The asymmetry only breaks when you hold a payout path the provider does not control, at which point their outage becomes an inconvenience instead of an existential event for your brand. Negotiate the definitions, then build the second rail — and never assume the first one bought you the second.

What else do operators ask before signing?

What uptime percentage should I demand in a sweepstakes casino platform provider SLA? 99.95% on redemption transaction success rate, measured in one-minute intervals. That allows roughly 22 minutes of monthly downtime. Deposits can sit at 99.9%. Accept a lower number only in exchange for stricter measurement, decline attribution and clock-start terms — the definition is worth more than the percentage.

How is payment uptime different from platform availability? Platform availability measures whether the provider's application responds; payment uptime measures whether money actually moves. A platform can report 100% availability while every redemption fails at the acquirer. Always contract on transaction success rate, computed from completed purchases and redemptions.

Who should be allowed to declare an outage? Either party. If only the provider can declare, they control the duration calculation and every remedy that flows from it. Write that the clock starts at the first failed measurement interval detected by either party's monitoring, or your ticket timestamp, whichever is earlier.

Are service credits ever worth negotiating hard? Yes, but for behavioural reasons rather than financial ones. Credits create internal cost centres that get escalated inside the provider. Financially, they rarely cover the true loss, which is why chronic-failure termination rights and data portability matter more in the same negotiation.

How often should failover be tested? Quarterly, with live traffic on the secondary payment path and a written report delivered to you within ten business days. Untested failover should be assumed non-functional. Require remediation of all findings within thirty days, with the test obligation stated in the SLA rather than a policy document.

Can I run my own payout rail alongside the platform provider's? Usually yes, but check for exclusivity or "sole payment processor" language and strike it during redlines. Preserving the right to route redemptions through an independent rail at your discretion is the only remedy that restores service during an incident rather than compensating you afterwards.