> ## Documentation Index
> Fetch the complete documentation index at: https://docs.nordiska.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Test Cases

> Test companies, applicant identities and expected outcomes for the card onboarding test environment

The test environment accepts a fixed set of test companies and applicant identities. Each one drives
the onboarding down a known path, so you can reach every state your integration has to handle
without waiting on a real decision: approval, document upload, rejection, failure and dual signing.

## Forcing an outcome

Some applicant names force a decision regardless of the company. The environment matches on the
applicant's name, so the same identity works on consumer, business and corporate onboardings.

| First name | Last name | Date of birth | Outcome |
| - | - | - | - |
| `Kyc` | `Denial` | <span style={{whiteSpace:"nowrap"}}>`1985-01-01`</span> | `REJECTED` (`KYC_DENIAL`) |
| `Credit` | `Fail` | any | `REJECTED` (`CREDIT_SCORING_DENIAL`) |
| `Internal` | `Error` | any | `FAILED` (`INTERNAL_ERROR`) |

The environment decides these at submission, so the response to your `POST` already carries the
final status. There is nothing to poll for.

## Consumer

The credit decision on a consumer onboarding comes from the applicant, not a company, so the
applicant has to be an identity the environment knows. Use the identities above to force a rejection
or a failure — those three come back decided on the `POST`, which is why they show no `PROCESSING`.
The environment matches `Lena Probst` on both the name and the date of birth. A different date of
birth fails with `INTERNAL_ERROR`, and so does a different name on `1993-03-22`. The three forced
outcomes above go by name alone, except `Kyc Denial`, which also needs its date.

| Applicant | Date of birth | Flow |
| - | - | - |
| <span style={{whiteSpace:"nowrap"}}>`Lena Probst`</span> | <span style={{whiteSpace:"nowrap"}}>`1993-03-22`</span> | `PROCESSING` → `AWAITING_SIGNING` → sign → `AWAITING_CARD_CREATION` |
| <span style={{whiteSpace:"nowrap"}}>`Kyc Denial`</span> | <span style={{whiteSpace:"nowrap"}}>`1985-01-01`</span> | `REJECTED` (`KYC_DENIAL`) |
| <span style={{whiteSpace:"nowrap"}}>`Credit Fail`</span> | any | `REJECTED` (`CREDIT_SCORING_DENIAL`) |
| <span style={{whiteSpace:"nowrap"}}>`Internal Error`</span> | any | `FAILED` (`INTERNAL_ERROR`) |

## Business

On a business onboarding the applicant is personally liable for the company's debts, so the credit
decision follows the applicant rather than the company. That makes the applicant part of the test
data. Where the table names one, use that name and date of birth, because the environment only
scores identities it knows.

| Identifier | Legal form | Applicant | Date of birth | Flow |
| - | - | - | - | - |
| `HRA4123` | Registered merchant (e.K.) | <span style={{whiteSpace:"nowrap"}}>`Max Mustermann`</span> | <span style={{whiteSpace:"nowrap"}}>`1981-09-16`</span> | `PROCESSING` → `AWAITING_SIGNING` → sign → `AWAITING_CARD_CREATION` |
| `HRA361057` | KG | <span style={{whiteSpace:"nowrap"}}>`Paul Anthony Daly`</span> | <span style={{whiteSpace:"nowrap"}}>`1972-04-25`</span> | `PROCESSING` → `AWAITING_SIGNING` → sign → `AWAITING_CARD_CREATION` |
| `PR952` | PartG | <span style={{whiteSpace:"nowrap"}}>`Harald Hess`</span> | <span style={{whiteSpace:"nowrap"}}>`1969-03-06`</span> | `PROCESSING` → `AWAITING_SIGNING` → sign → `AWAITING_CARD_CREATION` |
| `1234567891234` | Freelancer (Freiberufler) | <span style={{whiteSpace:"nowrap"}}>`Anders Andersson`</span> | <span style={{whiteSpace:"nowrap"}}>`1990-11-10`</span> | `PROCESSING` → `AWAITING_DOCUMENTS` → upload → `AWAITING_DOCUMENT_REVIEW` → `AWAITING_SIGNING` → sign → `AWAITING_CARD_CREATION` |
| `1234567891234` | GbR | any, plus a co-signer | any | `PROCESSING` → `AWAITING_DOCUMENTS` → upload → `AWAITING_DOCUMENT_REVIEW` |
| `HRA12346` | Registered merchant (e.K.) | any | any | `PROCESSING` → `REJECTED` (`KYB_DENIAL`) |
| `PR1234` | PartG | any | any | `PROCESSING` → `REJECTED` (`KYB_DENIAL`) |
| `HRA30001` | Registered merchant (e.K.) | any | any | `PROCESSING` → `REJECTED` (`UNAUTHORIZED_SIGNATORY`) |

No register holds a freelancer or a GbR, so you identify both by tax number (`1234567891234`), and
both always trigger a document request. A GbR also needs a second partner named as co-signer.

## Corporate

The credit decision on a corporate onboarding comes from the company, and most companies pass
through a review step on the way to signing. Nothing scores the applicant here, so `any` in the
table below is literal. Name, date of birth, place of birth and address can be anything at all.
`HRB125567` is the one exception, matched on both the name and the date of birth. Either of its two
registered signatories works as the applicant, and the other becomes the co-signer.

| Identifier | Legal form | Applicant | Date of birth | Flow |
| - | - | - | - | - |
| `HRB23445` | GmbH | any | any | `PROCESSING` → `AWAITING_MANUAL_REVIEW` → `AWAITING_SIGNING` → sign → `AWAITING_CARD_CREATION` |
| `HRA777001` | GmbH & Co. KG | any | any | `PROCESSING` → `AWAITING_MANUAL_REVIEW` → `AWAITING_SIGNING` → sign → `AWAITING_CARD_CREATION` |
| `GnR700029` | Cooperative (eG) | any | any | `PROCESSING` → `AWAITING_MANUAL_REVIEW` → `AWAITING_SIGNING` → sign → `AWAITING_CARD_CREATION` |
| `HRB125567` | GmbH, two signatories | <span style={{whiteSpace:"nowrap"}}>`Erika Musterfrau`</span> | <span style={{whiteSpace:"nowrap"}}>`1980-02-02`</span> | `PROCESSING` → `AWAITING_MANUAL_REVIEW` → `AWAITING_SIGNING` → sign ×2 → `AWAITING_CARD_CREATION` |
| `HRB300001` | GmbH | any | any | `PROCESSING` → `AWAITING_DOCUMENTS` → upload → `AWAITING_DOCUMENT_REVIEW` → `AWAITING_SIGNING` → sign → `AWAITING_CARD_CREATION` |
| `HRB300005` | GmbH | any | any | `PROCESSING` → `AWAITING_DOCUMENTS` → upload → `AWAITING_DOCUMENT_REVIEW` (stays) |
| `HRB300003` | GmbH | any | any | `PROCESSING` → `AWAITING_DOCUMENTS` → upload → `AWAITING_DOCUMENT_REVIEW` → `REJECTED` (`INVALID_DOCUMENTS`) |
| `HRB300004` | GmbH | any | any | `PROCESSING` → `AWAITING_MANUAL_REVIEW` (stays) |
| `HRB206186` | GmbH | any | any | `PROCESSING` → `REJECTED` (`CREDIT_SCORING_DENIAL`) |
| `HRB300002` | GmbH | any | any | `PROCESSING` → `REJECTED` (`CREDIT_SCORING_DENIAL`) |
| `HRB99999999` | GmbH | any | any | `PROCESSING` → `AWAITING_DOCUMENTS` → upload → `AWAITING_DOCUMENT_REVIEW` |
| <span style={{whiteSpace:"nowrap"}}>`HRA 3774`</span> | GmbH & Co. KG | any | any | `PROCESSING` → `AWAITING_DOCUMENTS` → upload → `AWAITING_DOCUMENT_REVIEW` |

`HRB99999999` and `HRA 3774` are not register numbers the environment can resolve, so both prove
that an unrecognised company produces a document request rather than a rejection. `HRA 3774` is
written with a space because that is the form our own tests use — `HRA3774` behaves exactly the
same, so the space is not what makes it unresolvable.

### Reaching a parked review

`HRB300004` is the company to use when you need to see `AWAITING_MANUAL_REVIEW` and act on it. It
waits for a person rather than clearing on its own, so the status holds instead of passing through
in a few seconds.

`HRB300005` does the same for `AWAITING_DOCUMENT_REVIEW`. Its uploaded documents wait for a person,
while `HRB300001`'s are approved automatically about 10 seconds after upload. On the way, `HRB300001`
can briefly report `AWAITING_DOCUMENTS` again before it moves to `AWAITING_SIGNING`.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.