# Support
source: https://developer.mastercard.com/rpps-biller-maintenance-service/documentation/support/index.md

## FAQ {#faq}

### General {#general}

**Answer:** The RPPS Biller Maintenance Service supports **REST only**. All requests must use RESTful HTTP endpoints.

**Learn more:** [API Reference](https://developer.mastercard.com/rpps-biller-maintenance-service/documentation/api-reference/index.md) --- see endpoint specifications
**Answer:** The RPPS Biller Maintenance Service is available in the **United States only** at this time.

**Next step:** To ask about availability in other regions, use the Get Help button at the bottom of this page.
**Answer:** Yes. The official cutoff time is 11:00 PM US Central Time (CT). Requests submitted after the cutoff are rejected with `BPBMSAPI_ERR_0118`.

**Next step:** Submit Biller changes on a business day before 11:00 PM CT. Requests submitted on non-business days or holidays are rejected with `BPBMSAPI_ERR_0116` or `BPBMSAPI_ERR_0117`.

**Learn more:** [Code and Formats](https://developer.mastercard.com/rpps-biller-maintenance-service/documentation/code-and-formats/index.md)
**Answer:** The service supports a total throughput of up to **500 requests per second (RPS)** across all connected clients.

**Recommended Per-Customer RPS**
Because all customers share this capacity, we recommend that no single customer exceed 200 RPS, which corresponds to approximately 120 concurrent in-flight requests. Plan bulk submissions at a moderate, steady rate. If you expect an unusually large onboarding volume, contact us in advance so we can advise on timing and pacing.

**Cut-off Time**
The official cutoff time for processing is 11:00 PM US CT. Requests submitted after this time are rejected and must be resubmitted the following business day. The cutoff exists because each request triggers approval workflows that must finish before the end of the business day. Submissions after 11:00 PM would not leave enough time for that processing, so Billers might not be active on their intended effective date.
We strongly recommend that you build in a buffer, for example by stopping new submissions at 10:00 PM, so that all in-flight requests complete and are accepted before the cutoff.

**Expected Behavior When Rate Limits Are Exceeded**
If the request rate across all clients exceeds the supported threshold, the API responds as follows:

* HTTP 429 (Too Many Requests): the gateway is signaling that the submission rate is too high. Stop sending and retry after a delay.
* HTTP 500 (Internal Server Error): this can occur under extreme load at the gateway. Treat it as transient and retry with backoff.

**Best Practices:**

1. Validate payloads before bulk submission. Run a small test batch of 10 to 20 records to confirm that your payload structure is correct before you send thousands of requests. A schema error in the first record might repeat across the entire batch.
2. Spread submissions over time. Avoid concentrated bursts, because a steady rate is better than high-volume spikes.
3. Track submission progress in your system. Log which requests succeeded and which failed, with their Biller IDs, so you can retry only the failed records.
4. Ramp up gradually. Increase from a low rate to your target over 30 to 60 seconds so that connection pools and backend resources can stabilize.
5. Monitor HTTP response codes in real time. If HTTP 429 responses appear during a run, reduce your rate immediately.

**Recommended Retry Strategy**

1. On HTTP 429, pause and retry using exponential backoff with jitter. Start with a 1 to 2 second wait and double it with each consecutive retry.
2. On HTTP 500, apply the same backoff strategy and log these occurrences separately, because they indicate higher gateway saturation.
3. Never retry immediately in a tight loop. Rapid retries make the problem worse for all customers that share the gateway.
4. Set a maximum of 3 to 5 retry attempts per request. If a request still fails, mark it as failed, log it, and move on. Resubmit failed records in a separate follow-up batch.

**Common causes of throttling:** Burst traffic patterns, concurrent requests from multiple systems, or automated testing without rate limiting.

**Next step:** If you exceed the limit, add exponential backoff retry logic to your integration. If you need a higher limit, use the Get Help button at the bottom of this page.

**Learn more:** [Code and Formats: Quick Reference](https://developer.mastercard.com/rpps-biller-maintenance-service/documentation/code-and-formats/index.md#quick-reference-common-http-errors)

### Onboarding {#onboarding}

**Answer:** Complete these prerequisites in order:

1. Sign and return the RPPS agreements to Mastercard.
2. Create a Mastercard Developers account.
3. Create a project for the RPPS Biller Maintenance Service.
4. Download your Sandbox Signing Key (`.p12` file).
5. Copy your Consumer Key from the project page.
6. Send your Consumer Key to your assigned Implementation Manager to start Sandbox configuration.

**Next step:** Follow the [Quick Start Guide](https://developer.mastercard.com/rpps-biller-maintenance-service/documentation/getting-started/index.md) for step-by-step instructions.
**Answer:** Mastercard allows **5-7 business days** for Sandbox configuration after you provide your Consumer Key to your Implementation Manager.

**Common causes of delays:** Incomplete onboarding information, missing credentials, or holiday schedules.

**Next step:** If configuration exceeds the SLA, escalate to your Product Delivery Manager (see escalation entry below).

**Learn more:** [Quick Start Guide --- Escalation Path](https://developer.mastercard.com/rpps-biller-maintenance-service/documentation/getting-started/index.md#escalation-path)

### Policy {#policy}

**Answer:** **No.** A successful API response (HTTP 200 with `statusIndicator: SUCCESS`) means that the work request was created and passed format validation. The Biller must still:

1. Pass additional business rule validation, which runs in the background.
2. Be approved in the Mastercard review.
3. Reach the effective date you specified, which is at least 5 business days after submission.

**Common causes of rejection:** Duplicate biller, restricted words, incomplete information, or failed business rule validation.

**Next step:** Use the [Work Request Status API](https://developer.mastercard.com/rpps-biller-maintenance-service/documentation/use-cases/work-request-status/index.md) to monitor the status of your Biller. If the work request is rejected, check the RPPS UI for the reason.

**Learn more:** [Use Cases --- Work Request Status](https://developer.mastercard.com/rpps-biller-maintenance-service/documentation/use-cases/work-request-status/index.md)
**Answer:** The effective date you submit must be at least **5 business days after the submission date** and no more than 7 business days after it. Weekends and federal banking holidays do not count as business days.

**Common causes of errors:** An effective date that is too soon (`BPBMSAPI_ERR_0010`), too far in the future (`BPBMSAPI_ERR_0009`), or on a weekend or holiday (`BPBMSAPI_ERR_0008`).

**Next step:** Recalculate your effective date as at least 5 business days in the future, excluding weekends and federal holidays, and resubmit.

**Learn more:** [Code and Formats](https://developer.mastercard.com/rpps-biller-maintenance-service/documentation/code-and-formats/index.md)
**Answer:** **Yes.** Call GET `/biller-request/{work_request_id}/status` to check the status of a submitted work request. You can also log in to the RPPS UI to view the status.

**Next step:** See [Work Request Status](https://developer.mastercard.com/rpps-biller-maintenance-service/documentation/use-cases/work-request-status/index.md) for the API call example and expected responses.
**Answer:** If you did not capture the Work Request ID from the API response, you can:

1. Look up the Biller in the RPPS UI by its Biller ID.
2. Capture and store the work request ID for every future API call, as Mastercard strongly recommends.

**Common causes:** The API response was not processed or logged correctly, or the Work Request ID was discarded.

**Next step:** For future submissions, store the returned `workRequestId` in your application database so you can reference it later.
**Answer:** When a biller fails business rule validation, you can:

1. Call the Work Request Status API to confirm the status of the work request.
2. Review the work request in the RPPS UI to find the rejection reason.
3. Correct the errors manually in the RPPS UI, or submit an Edit request through the API with the corrected fields.

**Common causes:** Duplicate biller entry, restricted business name, incomplete address, or invalid field values.

**Next step:** Correct the issues and resubmit them by following [Edit Biller](https://developer.mastercard.com/rpps-biller-maintenance-service/documentation/use-cases/edit-biller/index.md).

**Learn more:** [Code and Formats](https://developer.mastercard.com/rpps-biller-maintenance-service/documentation/code-and-formats/index.md) --- all error codes and resolution steps

### Support {#support}

**Answer:** Follow this escalation path:

1. **Contact** your assigned CIS Implementation Manager. Contact details are in your implementation project plan.
2. **If the issue is unresolved within 2 more business days**, escalate to your Product Delivery Manager.
3. **For general support** outside your assigned contacts, use the Get Help button below. Include your project name and the date configuration started.

**Common causes:** Resource constraints, holiday schedules, or incomplete information from the customer.

**Learn more:** [Quick Start Guide --- Escalation Path](https://developer.mastercard.com/rpps-biller-maintenance-service/documentation/getting-started/index.md#escalation-path)
**Answer:** Technical support is available through multiple channels:

1. **Assigned Implementation Manager**: onboarding and configuration issues, including urgent matters.
2. **Product Delivery Manager**: escalated issues.
3. **Get Help button** (below): general support inquiries and non-urgent issues.

**Learn more:** For error codes, see [Code and Formats](https://developer.mastercard.com/rpps-biller-maintenance-service/documentation/code-and-formats/index.md).

## Get Help {#get-help}

### Contact us for technical support. {#contact-us-for-technical-support}

## Next Steps {#next-steps}

* [Quick Start Guide](https://developer.mastercard.com/rpps-biller-maintenance-service/documentation/getting-started/index.md) --- get credentials and make your first call
* [API Reference](https://developer.mastercard.com/rpps-biller-maintenance-service/documentation/api-reference/index.md) --- full OpenAPI specification
* [Testing](https://developer.mastercard.com/rpps-biller-maintenance-service/documentation/testing/index.md) --- MTF test environments, methods, and scenarios