Getting started

Sandbox & test data

This page is the catalogue for the transactional lending sandbox: test company numbers, the magic amounts that steer decisioning, test payment instruments for open-banking flows, and how to replay webhooks — everything you will need to exercise approve, refer and decline once the write plane ships.

Roadmap — the transactional sandbox is not yet live. The applications, decision, payments and events routes used throughout this page are part of the planned partner/v1 write plane and currently answer 503 Service Unavailable; the reserved companies, magic amounts and test instruments below are documented so you can design ahead. The live partner/v1 surface today is the OAuth token plane plus the authenticated read-only MCP tier — start with the Quickstart. We will announce the sandbox write plane on the changelog.

When it ships, the sandbox will be deterministic and fully isolated from live: separate credentials, no real money, no real Companies House or identity lookups. The same object shapes will apply — only the inputs are reserved test values that map to known results, so you can pin them in an automated test suite and trust that today's approved is tomorrow's approved.

Using the sandbox roadmap — 503

Once the write plane ships you will authenticate exactly as in Quickstart, then point requests at the sandbox host. The call below is the planned shape — today POST /partner/v1/applications returns 503.

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 roadmap — 503

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 a not_found error in sandbox.

Magic amounts roadmap — 503

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 — `validation_failed` (`amount_pence` below minimum £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 roadmap — 503

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 roadmap — 503

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 roadmap

When the transactional write plane ships, confirm you have driven each of these end to end in sandbox before requesting live access:

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.

To build against the surface that is live today — the OAuth token plane and the authenticated read-only MCP tier — follow the Quickstart. For write-plane timelines or to register a partner client, email developers@credicorp.co.uk.