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

# Onboarding & Testing

> What to expect during onboarding and how to test your integration before going live.

# Go Live with Confidence

Every client goes through the same onboarding sequence: you integrate and test against the TEST environment together with the Inventi team, confirm all test scenarios pass, and only then move to production. This page describes the steps and the test scenarios you will run.

<Info>
  Throughout onboarding, the Inventi team assists you. Reach them via your shared Slack channel or via email.
</Info>

## Onboarding Steps

<Steps>
  <Step title="Exchange access details">
    You share the IP addresses from which you will access the Back office portal and the API. Inventi whitelists them and shares your credentials for both.
  </Step>

  <Step title="Verify access">
    Log in to the SEPA Gateway Dashboard and create your team's users with appropriate roles (see below). On the API side, obtain a token with your credentials and make a first test call - `GET /getTransactionStatuses` or `GET /getTransactionTypes` are good candidates.
  </Step>

  <Step title="Set up webhooks">
    Set up your [webhooks](/payments/integration-guide/webhooks-management) URL and implement [signature verification](/payments/webhooks/signature-verification). Webhooks are the primary signal for everything that follows - set them up before running payment scenarios.
  </Step>

  <Step title="Run the test scenarios">
    Work through the scenario checklist below for each payment scheme you are onboarding (SCT, Instant, Direct Debit, SWIFT). Scenarios marked **with support** require the Inventi team to trigger the counterparty side.
  </Step>

  <Step title="Confirm readiness">
    When all scenarios pass, you confirm readiness and production onboarding is scheduled. Any issues found during testing are highlighted/submitted via Slack or email with the testing scenario described.
  </Step>
</Steps>

## Dashboard User Roles

The first Dashboard user can create additional users with these roles:

| Role                 | Capabilities                                                        |
| -------------------- | ------------------------------------------------------------------- |
| **Administrator**    | All actions of the roles below                                      |
| **User Manager**     | Create users and manage their roles; no access to payments          |
| **Payments Manager** | Create payments, view payment lists and details; no user management |
| **Payments Signer**  | Review and sign existing payments only                              |
| **Payments Viewer**  | View payment lists and details only                                 |

## Test Data

Test counterparty details (IBANs, BICs, receiver names) for your clearing connection are provided by your onboarding manager at the start of testing. They include:

* A **working counterparty account** for successful payment scenarios
* A **non-existing/closed account** that produces a rejection
* An **IBAN whose BIC cannot be resolved**, for testing API validation errors

<Note>
  The TEST environment uses simulated funds. Test nostro balances can be topped up on request, and balances may behave differently than production (for example, they can go negative).
</Note>

## Test Scenarios

The tables below are the reference version of the test plan. At the start of testing, your onboarding manager shares a tracked copy of it - you and the Inventi team mark scenarios off together there, so both sides always see the same progress.

<Tabs>
  <Tab title="Outbound Payments">
    | Scenario                          | How                                                     | Expected result                                                                     |
    | --------------------------------- | ------------------------------------------------------- | ----------------------------------------------------------------------------------- |
    | Successful payment via Dashboard  | Create a payment in the UI to the test counterparty     | Status progresses to `Completed`; each transition delivered via webhook             |
    | Successful payment via API        | Create the same payment via the create-payment endpoint | Response returns the transaction ID; status progresses to `Completed` with webhooks |
    | Payment to a non-existing account | Send to the rejection test IBAN                         | Payment is rejected by the clearing system; status `Rejected` with webhook          |
    | Unresolvable BIC                  | Send to the BIC-test IBAN without providing a BIC       | API returns an error stating the bank BIC is required; no payment is created        |
  </Tab>

  <Tab title="Inbound Payments">
    | Scenario                                    | How                                                      | Expected result                                                                                                                                     |
    | ------------------------------------------- | -------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
    | Receive a payment **(with support)**        | Ask support to send a payment from the test counterparty | Webhook notifies you of the new transaction; status `Completed`; retrievable via `getTransaction` / `getTransactionsList`; visible in the Dashboard |
    | Return a received payment                   | Call the return endpoint on the received payment         | A linked payment return transaction is created and sent to clearing; webhook delivered; original payment unchanged                                  |
    | Receive a payment return **(with support)** | Ask support to return one of your outbound payments      | A linked inbound return transaction appears with status `Completed`, related to the original payment                                                |
  </Tab>

  <Tab title="Cancellations">
    | Scenario                                          | How                                                           | Expected result                                                                        |
    | ------------------------------------------------- | ------------------------------------------------------------- | -------------------------------------------------------------------------------------- |
    | Cancel an outbound payment (UI and API)           | Initiate cancellation of a completed test payment             | Cancellation request is created and linked to the original transaction                 |
    | Cancellation accepted **(with support)**          | Ask support to accept your cancellation request               | Funds come back as a linked return transaction; cancellation status `PAYMENT_RETURNED` |
    | Cancellation refused **(with support)**           | Ask support to refuse your cancellation request               | Cancellation status `CANCELLATION_REFUSED`; original payment stands                    |
    | Receive a cancellation request **(with support)** | Ask support to request cancellation of a payment you received | Webhook notifies you; request retrievable via `/v1/cancellation-requests`              |
    | Accept the received request                       | Call the accept endpoint                                      | Linked return transaction created and sent; webhook delivered                          |
    | Reject the received request                       | Call the reject endpoint                                      | Refusal sent; cancellation status `CANCELLATION_REFUSED`; funds stay                   |
  </Tab>

  <Tab title="Statements">
    | Scenario                 | How                                                             | Expected result                                       |
    | ------------------------ | --------------------------------------------------------------- | ----------------------------------------------------- |
    | Nostro balances visible  | Open Liquidity management in the Dashboard                      | Nostro accounts and balances are shown                |
    | Fetch statements via API | Query the nostro account statement endpoints for previous dates | Statement files are returned for your nostro accounts |
  </Tab>
</Tabs>

## Scheme and Connection Notes

* **SCT vs Instant**: the scenario list is the same for both schemes - run it once per scheme. Instant payments settle in seconds; if instant confirmation mode is enabled for your tenant, also test accepting and rejecting a `Pending confirmation` payment.
* **SEPA Direct Debit**: if you are onboarding SDD, an additional scenario set covers collections, rejections, returns, refunds and reversals - provided during onboarding.
* **Clearing connections (CENTROlink / EKS)**: the API, statuses, webhooks and scenarios are identical regardless of which clearing connection your tenant uses. Test counterparty data and statement details are connection-specific and are provided with your test credentials.

## What's Next?

<CardGroup cols={2}>
  <Card title="Authentication" icon="key" href="/payments/authentication">
    Set up API credentials and tokens
  </Card>

  <Card title="Send Payments" icon="paper-plane" href="/payments/outgoing-sepa-payment">
    Create your first outbound payment
  </Card>

  <Card title="Receive Payments" icon="arrow-down" href="/payments/integration-guide/incoming-sepa">
    Handle incoming payments via webhooks
  </Card>

  <Card title="Webhooks Management" icon="bell" href="/payments/integration-guide/webhooks-management">
    Configure and filter webhook notifications
  </Card>
</CardGroup>