Alerts And Decisioning

Testing

The Customer Testing Environment is a fully isolated, pre-production environment designed to let you validate your integration end-to-end before going live. It mirrors the production API contract exactly — the same endpoints, authentication flow, error codes, and response schemas —giving you a high-confidence test experience that behaves just like production.

The Customer Testing Environment connects to a completely separate database from production. Actions you take in this environment have no downstream effects: no real payments are processed, no funds are moved, and no compliance or fraud detection systems are triggered. All data returned and updated in the Customer Testing Environment is synthetic, with the exception of your onboarded account identifiers, which are real and used to associate generated holds with your accounts. You can send live API calls, receive holds via webhook, query and filter data, and submit decisions —everything you can do in production —without any operational risk.

Attention

Verify your target URL: You must ensure that your development environment is configured to point to the Customer Testing Environment URL — not the production URL. Accidentally connecting to production could result in unintended actions on real payments. Double-check your base URL configuration before initiating any test traffic.

Data generator

The Customer Testing Environment includes an automated Data Generator that maintains a steady supply of realistic Payment hold data for your integration testing. You do not need to request manual data setup or raise support tickets to populate your environment — test data is provisioned automatically when you are onboarded.

The Data generator works on a continuous cycle. As you consume holds by submitting decisions through the API, the system detects the resulting gap and replenishes your dataset with new holds, typically within approximately 15 minutes. Holds that expire naturally are also cleaned up and replaced automatically. This means you always have a working pool of data available, regardless of how actively you are testing.

Note

All generated data is generic. Beneficiaries, originators, and other banking entities will not reflect your actual customers or counterparties. However, generated Holds contain your real onboarded account identifiers. This ensures the system correctly associates Holds with your accounts. You can validate your integration logic for account-based routing and filtering against realistic conditions. All other fields are purely synthetic and intended for structural integration testing only.

Key characteristics of the generated data:

Baseline and automatic replenishment: Holds are available by default shortly after onboarding and are continuously refreshed as they are decisioned or expire. If all available holds are exhausted, new holds will generate within 15 minutes.
Account-linked data: All holds reference accounts you've onboarded; all other attributes are generic.
Historical access: Decisioned holds remain queryable for up to 7 days, supporting testing of historical query and reporting flows.

The Data Generator allows you to exercise the full integration lifecycle in a continuous loop: receive holds via webhook, persist them to your database, query and filter holds through the API, submit decisions, and then observe fresh holds appear as the cycle repeats.

Testing best practices

You should perform complete, end-to-end testing in the Customer Testing Environment before promoting your code through your internal release process and connecting to production. This includes validating your webhook receiver, query logic, decision submission, error handling, and any downstream processing your system performs when holds are received or updated. The Customer Testing Environment is purpose-built to support this — treat it as your primary integration validation gate.

Be aware, however, that the Customer Testing Environment enforces rate limiting. If you send a sustained high volume of requests, the environment will begin throttling your traffic. Design your test suites to operate within reasonable request rates, and account for throttled responses (HTTP 429) in your error-handling logic.