This section describes how the MIDSuite API behaves under production workloads and provides guidance for building resilient integrations.

Expected Response Times

Individual MIDSuite services are designed to respond quickly to support real-time transaction decisioning.

Typical response times:

Service	Expected Response Time
PreCheck	≤ 500 ms
Rules	≤ 500 ms
Sentry	≤ 500 ms
ID Verify	≤ 500 ms
Pipeline	Varies based on stages

Pipeline requests may take longer than individual service calls because each stage in the pipeline is executed sequentially. The total latency is therefore approximately the sum of the stages executed within the pipeline.

MIDSuite does not publish specific P95 or P99 latency targets.

Timeouts

Clients should configure HTTP timeouts that allow sufficient time for slower responses while still protecting their own infrastructure.

Recommended settings:

• Client-side timeout: up to 30 seconds

• Typical upstream timeout: approximately 30 seconds

Timeouts shorter than this may prematurely terminate valid responses, particularly when using the Pipeline API or during periods of network congestion.

Retry Strategies

Transient failures can occur due to temporary network conditions or upstream system issues. MIDSuite requests are safe to retry when a request fails due to:

• HTTP 5xx server errors

• Network timeouts

• Temporary processing results such as:

  • TEMP_ERROR

  • RETRY

Retries should use exponential backoff rather than immediate repeated requests. This helps prevent cascading failures during temporary service degradation and improves overall system stability.

Safe Retry and clientReferenceId

When retrying requests, the behavior of the clientReferenceId should be considered carefully.

• If clientReferenceId represents a client-side record (such as an order ID or transaction ID), retries should reuse the same value.

• If clientReferenceId represents a unique MIDSuite request identifier, a new value should be generated for each retry.

The MIDSuite platform does not treat duplicate clientReferenceId values as idempotent, so repeated requests with the same identifier may be processed independently.

Handling Pipeline Failures

The Pipeline API executes multiple services as part of a single request. If any stage in the pipeline fails:

• The entire pipeline request is treated as an error

• Partial results are not returned

• The response will contain error information rather than stage outputs

Clients should treat pipeline failures as a single failed operation and retry the request if appropriate.

Rate Limiting

MIDSuite does not impose a fixed default rate limit. However, the platform may return HTTP 429 (Too Many Requests) if the system is overloaded.

The API is designed for real-time transactional usage, not high-volume batch processing. Systems that submit large bursts of simultaneous requests or sustained high-throughput workloads may be temporarily rate-limited or disabled.

Clients should implement:

• request pacing

• exponential backoff retries

• monitoring for HTTP 429 responses

These practices help maintain reliable operation during periods of high demand.

Availability

The MIDSuite platform is designed for high availability in production payment environments.

Target uptime:99.999% (Five Nines)

This availability target supports mission-critical transaction workflows and real-time fraud detection systems.