Service Levels & Support
Written by
Last editedMay 20261 min read
When payments fail or the platform is unavailable, the quality of your provider’s support and the speed of their response directly affects your revenue and your customers’ experience. This section covers the platform availability commitments, incident management processes, support channels, and service exit provisions you should evaluate.
| # | Question | Explanation / what to look for |
|---|---|---|
| 1 | What are your uptime SLA commitments for platform availability, and what credits or remedies apply if SLAs are missed? | Ask for both the contractually committed uptime figure and the historically achieved one. Understand what constitutes downtime (total unavailability vs. degraded performance), and what the financial remedy is if the SLA is missed. |
| 2 | What is your maximum throughput capacity, and can your platform scale to meet our peak demand without degradation? | Payment volume can spike dramatically at month-end, following a marketing campaign, or during a billing cycle. Understand whether the platform is architected to scale elastically, and ask for evidence of peak handling. |
| 3 | How do you manage scheduled maintenance, and what notice do you provide before taking the system offline or reducing capacity? | Scheduled maintenance at the wrong time can disrupt your payment submissions. Understand the typical maintenance window, the notice period, and whether you can request changes to the schedule. |
| 4 | What is your notice period for changes that require action on our side, such as API updates, scheme changes, or data format changes? | Provider-initiated changes that require your engineering team to act will create unplanned work. Ask for the minimum notice period and how changes are communicated. |
| 5 | Do you provide a technical helpdesk for incident reporting, and what are your hours of operation? | Payment incidents don’t respect business hours. Understand whether 24/7 support is available, or whether out-of-hours incidents are handled by an on-call team with a different SLA. |
| 6 | Through what channels can we report incidents and request support (phone, email, ticketing portal)? | The availability of your preferred contact channel matters. A portal-only approach may be too slow for a Severity 1 incident; a phone line may be essential. |
| 7 | What are your response times for incidents at each severity level? | Response time SLAs should be distinguished based on the severity of the incident. Ask what constitutes each level of severity. |
| 8 | How are incidents reported, triaged, resolved, and communicated throughout their lifecycle, and what root cause analysis is provided after resolution? | A provider with a mature incident process will have defined severity criteria, automated escalation paths, regular status updates, and post-incident reports. |
| 9 | Will we have a named point of contact such as a service manager or customer success manager with direct escalation authority? | A named contact who knows your account, your technical setup, and your escalation preferences is significantly more valuable than a generic support queue particularly when something goes wrong. |
| 10 | How and how quickly will you notify us in the event of an unplanned outage or major incident that affects our payment processing? | Proactive notification of incidents that affect you is a mark of a mature provider. Ask what triggers a notification, how it is sent, and what the target notification time is. |
| 11 | Do you provide a public status page that shows the real-time operational status of all platform components? | A public status page reduces support call volume during incidents and allows your team to self-serve status information without raising a ticket. Ask for the URL. |
| 12 | Does the status page automatically reflect active incidents and post-resolution summaries, or does it require manual updates? | Manually updated status pages are often out of date during incidents, the very time when accurate information matters most. Automated status updates are significantly more reliable. |
| 13 | If we decide to move to a different provider, what is your formal exit and transition process, and what data portability do you offer? | Exit planning is often overlooked at procurement but becomes critical if you later switch providers. Understand the notice period required, what data you can export and in what format, and whether the provider will cooperate with a migration to a competitor. |
Sample RFP
Our sample RFP includes all of the questions in this guide and more. You can download it and use it as a template for creating your own.
Note: The questions suggested on this page are intended as a starting place for writing your own RFP. They're provided for general information only: they're not intended to be prescriptive or to provide legal advice. We suggest working closely with your management to develop an RFP that is tailored towards the specific requirements of your business.
