Getting started

Sandbox & test data

Sandbox is deterministic, so you can force every outcome on demand. This page is the catalogue: test company numbers, the magic amounts that steer decisioning, test payment instruments for open-banking flows, and how to replay webhooks — everything you need to exercise approve, refer and decline before a single live borrower arrives.

The sandbox lives at https://sandbox.credicorp.co.uk and is fully isolated from live: separate credentials, no real money, no real Companies House or identity lookups. The same SDKs and object shapes apply — only the inputs are reserved test values that map to known results. Because outcomes are reproducible, you can pin them in an automated test suite and trust that today's approved is tomorrow's approved.

Using the sandbox

Authenticate exactly as in Quickstart, using your cid_sbx_ credentials against the sandbox token URL. Then point every request at the sandbox host.

bash

export CC_BASE="https://sandbox.credicorp.co.uk"

curl -s "$CC_BASE/partner/v1/applications" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Idempotency-Key: test-approve-01" \
  -H "Content-Type: application/json" \
  -d '{ "business": { "company_number": "00000401" },
       "amount_pence": 2500000, "term_months": 12 }'

Sandbox decisioning runs in well under a second — no manual underwriting queue sits behind it. A referred result therefore resolves to its final outcome almost immediately, so you can test the referral path without waiting.

Test company numbers

Use these reserved Companies House numbers as business.company_number. Each maps to a fixed synthetic company — trading history, filings and directors — that steers the identity and affordability checks down a known route. Real numbers are rejected in sandbox.

Number	Synthetic company	Forces
`00000401`	Healthy Ltd — 6 yrs trading, clean filings	Identity & affordability pass.
`00000402`	Thin File Ltd — incorporated 4 months ago	Referral for manual underwriting.
`00000403`	Overdrawn Ltd — high existing gearing	Affordability fail → decline.
`00000404`	Dissolved Ltd — not active at Companies House	Eligibility fail (entity not borrowable).
`00000405`	PEP Director Ltd — director flagged on screening	Identity referral (sanctions/PEP hit).

For LLP borrowers, the equivalent reserved numbers are OC000401 through OC000405 and behave identically. Anything outside these ranges returns company_not_found in sandbox.

Magic amounts

When a test company on its own does not pin the result you want, the requested amount_pence takes over as the deciding input. These magic amounts override the company's default route, so you can drive any branch from a single healthy company.

amount_pence	Pounds	Decision outcome
`2500000`	£25,000	approved with a standard offer.
`1300000`	£13,000	referred — routed to manual underwriting.
`900000`	£9,000	approved with a counter-offer (lower amount / shorter term).
`400000`	£4,000	declined — `affordability_fail`.
`100`	£1	422 — `amount_below_minimum` (under £1,000).

The decision the engine returns for the approve case is fully populated, exactly as live, so your offer-rendering code is genuinely exercised:

json

{
  "id": "dec_5Qm2Kd9c",
  "object": "decision",
  "outcome": "approved",
  "offer": {
    "amount_pence": 2500000,
    "term_months": 12,
    "apr_bps": 1490,
    "repayment_pence": 225417
  },
  "reasons": ["affordability_pass", "identity_verified"]
}

Pair a magic amount with a test company to compose cases — for example 00000405 (PEP director) at £25,000 still routes to an identity referral, because identity is evaluated before affordability. Build a small fixture table covering each branch and assert against it in CI.

Test payment instruments

Disbursement and repayment run over open banking (PISP), so there are no card numbers. Instead, sandbox exposes reserved test bank accounts you attach when accepting an offer or setting up a repayment mandate. Each forces a known settlement behaviour without touching a real bank.

Sort code	Account number	Behaviour
`04-00-04`	`00000401`	Settles successfully → `payment.succeeded`.
`04-00-04`	`00000402`	Authorised but settles after a delay (tests pending state).
`04-00-04`	`00000403`	Insufficient funds → `payment.failed` (`insufficient_funds`).
`04-00-04`	`00000404`	Mandate revoked by the payer → `mandate.cancelled`.

Create a one-off test repayment against a funded sandbox account exactly as you would live:

bash

curl -s "$CC_BASE/partner/v1/payments" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Idempotency-Key: test-pay-01" \
  -H "Content-Type: application/json" \
  -d '{
    "account": "acc_7Qm2Kd9c",
    "amount_pence": 225417,
    "instrument": { "sort_code": "040004", "account_number": "00000403" }
  }'

The 00000403 instrument above returns a failed payment, letting you exercise your dunning and retry logic. See the Payments API for variable recurring payments, schedules and reconciliation.

Replaying webhooks

Every event delivered in sandbox is stored, so you can resend it to your endpoint as often as you like — ideal while you are still building the handler, or to reproduce a delivery your service missed during a deploy.

POST/partner/v1/events/{id}/replay

bash

# List recent events, then replay one to your endpoint
curl -s "$CC_BASE/partner/v1/events?type=decision.completed&limit=5" \
  -H "Authorization: Bearer $TOKEN"

curl -s "$CC_BASE/partner/v1/events/evt_9c2Kd5Qm/replay" \
  -H "Authorization: Bearer $TOKEN"

A replay re-delivers the original payload with a fresh delivery attempt and a new signature timestamp, so your signature-verification and idempotency code are both exercised. The event id stays the same — which is exactly why your handler must dedupe on it. You can also trigger a synthetic event from the dashboard if you want to test a handler before you have produced a real one.

If your endpoint is unreachable, sandbox retries with the same exponential back-off as live. Use a tunnel (such as a localhost forwarder) during development so deliveries actually reach your machine — a silently dropped webhook is the most common reason a flow “hangs” in testing.

Pre-launch checklist

Before requesting live access, confirm you have driven each of these end to end in sandbox:

An approved application that funds and produces an account.
A referred application, including the second decision.completed on resolution.
A declined application, with reasons surfaced to the user.
A successful repayment and a failed one, with your retry logic exercised.
A replayed webhook proving your handler is idempotent and verifies signatures.
A 422 validation error and a 429 rate-limit, handled gracefully.

When every box is ticked, switch the base URL to https://api.credicorp.co.uk, swap in your live credentials, and email [email protected] to enable production.