Sandbox testing tends to converge on the same shape: a complete application, a clean identity match, an approval, a green check, sign-off.

That path is worth confirming once. It is also the outcome that needs the least engineering, because it is the one where nothing goes wrong. The states that actually cost time in production are the ones below, and most of them are cheaper to exercise in a sandbox than to discover during a launch weekend.

Ambiguous, not just pass and fail

Identity resolution has a middle state, decisioning has a referral state, and both are where the real handling lives.

Exercise them explicitly:

  • An identity that resolves as inconclusive rather than matched or rejected. Does your UI have a screen for it? Does the queue receive enough context for a reviewer to act?
  • A decision that returns manual review rather than approve or decline. Who is notified? What does the applicant see in the meantime — and what do they see if the review takes two days?
  • A thin file. Not an error, just insufficient data. Systems that treat sparse data as a failure decline good applicants for a coverage problem.

If a state does not have a screen, it will get the generic error page. That is a product decision being made by default.

The states you cannot reach on purpose

Some conditions are difficult to trigger deliberately, which is exactly why they should be scripted rather than waited for.

Timeouts. Not an error response — no response. Does your request have a timeout at all? What does the consumer see at second twelve? If you retry, is the downstream operation idempotent, or did you just submit twice?

Partial success. The inquiry succeeded, the webhook dispatch failed. The application exists in your system and not in theirs, or the reverse. Somebody has to reconcile that, and the reconciliation path should exist before it is needed.

Duplicate submission. The consumer double-clicks, or refreshes during a slow response. Two applications, one person, and now two inquiries. Idempotency keys are the fix and they are much easier to add before launch.

Out-of-order events. Covered at length elsewhere, but worth a sandbox case: deliver a status event twice, and deliver an older one after a newer one.

Easy to overlook because the happy path never exercises them.

  • Consumer declines the disclosure. Does the flow end cleanly, and is the declination recorded as an event?
  • Consumer abandons between disclosure and submission. Is there an orphaned consent record with no inquiry attached, and is that acceptable?
  • Consumer returns later to a session that has expired. Is the earlier consent still valid for the new inquiry, and who decided that?

The third one is a policy question more than a technical one, which is why it is better raised during integration testing than during a review.

Volume, briefly

Full load testing against a sandbox is usually neither available nor representative. But two cheap checks are worth doing:

  • Concurrency. Fire a batch of simultaneous requests for the same applicant. Race conditions in your own application state are yours to find, and they surface immediately under this.
  • Sustained rate. Enough requests to see whether your error handling changes shape when responses slow down. Handlers that work at one request per second sometimes queue unboundedly at fifty.

Operational readiness, not just code

The last group is not about the integration at all.

  • Can your on-call tell the difference between a downstream degradation and a bug in your own code, from the alerts alone?
  • Does someone know what to do when the referral queue stops draining?
  • Is there a documented rollback, and has anyone performed it?
  • Do you alert on the absence of expected events, not only on failures?

A sandbox is the only environment where the answer to “has anyone performed it” can be yes without consequences.

A reasonable exit checklist

Before a production cutover:

  1. Every decision state has a screen, including the ambiguous ones.
  2. Every error state has a screen that is not the generic error page.
  3. Timeouts, retries, and duplicate submissions have been exercised deliberately.
  4. Webhook handling survives duplicate and out-of-order delivery.
  5. Consent decline and abandonment paths are recorded correctly.
  6. The referral queue has been worked end to end by someone who will actually work it.
  7. Alerting covers silence as well as failure.

Seven items. The first six are engineering; the seventh is the one that gets cut for time and is the one that pages you at 2am.

Sandbox availability, test data, and the specific states exercisable in your environment are confirmed during technical discovery. The scenarios above are illustrative of the integration patterns Revery Credit is designed to support.