Testing Nium

▶ Run in Postman

Learn how to test Nium's different services and build your integration with confidence. Please note, for testing purposes this article details how to test Nium's services in the US.

See our Testing - Postman collection for a breakdown of the different testing scenarios available.

📌
IMPORTANT
Please note, this feature is currently in beta and only available for select clients. If you're interested, or have any questions please contact your Nium account manager or Nium Support.

Onboarding

Use the Simulate - Onboarding request to test the onboarding status for individual and corporate accounts.

Individual customers

To comprehensively test onboarding, use the following requests which also help you create the resources you'll manipulate to test onboarding.

Onboarding - Individual Customers

Request	Description
Step 1: Unified Add Customer	Add A customer. Include `PEP` in `firstName` to return an ACTION_REQUIRED status.
Step 2: Customer Details V2	After creating a `customer`, use the Customer Details V2 request to verify the `complianceStatus` of the `customer` is ACTION_REQUIRED.
Step 3: Simulate Customer Compliance Status	Set `nextStatus` to `RFI_REQUESTED` and specify `requestInfoFor` in the `IndividualCustomerRequest`object. . Repeat Step 2 to confirm the `complianceStatus` updates to `RFI_REQUESTED`.
Step 4: Fetch Individual Customer RFI Details	Fetch details about the Request for Information (RFI).
Step 5: Respond to RFI	Respond to the RFI.
Step 6: Simulate Customer Compliance Status	Set `nextStatus` to COMPLETED or REJECT. Repeat Step 2 to verify the COMPLETED final status. Please note, REJECT and COMPLETED are permanent states.

Corporate customers

Testing how to onboard customers follows a similar flow to individual customers, with some variations in API parameters. Simulation API requirements remain the same except for values accepted in requestInfoFor.

Onboarding - Corporate Customers

Request	Description
Step 1: Onboard Corporate Customer	Add A customer. Include `BusinessHit` in `businessName` to return an ACTION_REQUIRED status.
Step 2: Customer Details V2	After creating a `customer`, use the Customer Details V2 request to verify the `complianceStatus` of the `customer` is ACTION_REQUIRED.
Step 3: Simulate Customer Compliance Status	Set `nextStatus` to `RFI_REQUESTED` and specify `requestInfoFor` in the `CorporateCustomerRequest`object. Repeat Step 2 to confirm the `complianceStatus` updates to `RFI_REQUESTED`.
Step 4: Fetch Corporate Customer RFI Details	Fetch details about the Request for Information (RFI).
Step 5: Respond to RFI for Corporate Customer	Respond to the RFI.
Step 6: Simulate Customer Compliance Status	Set `nextStatus` to COMPLETED or REJECT. Repeat Step 2 to verify the COMPLETED final status. Please note, REJECT and COMPLETED are permanent states.

Payouts

To comprehensively test payouts, first use the following requests to create the resources you'll manipulate to test payouts. Please note:

Use the following endpoint - /api/v1/simulations/transactions/{systemReferenceNumber}/transition
nextStatus can accept the following values:
- EXPIRED
- RFI_REQUESTED
- COMPLIANCE_COMPLETED
- REJECTED
- PAID
- RETURN
- ERROR1
Use the following request body to test out the different nextStaus statuses:

{
    "nextStatus":"RFI_REQUESTED",
    "requestInfoFor": "creditor_salaryStatement"
}

Payouts - Prerequisites

Request	Description
Step 1: Onboard Corporate Customer	Use the Onboard Corporate Customer request to create a `customer`.
Step 2: Customer Details V2	After creating a `customer`, use the Customer Details V2 request to verify the `complianceStatus` of the `customer` is COMPLETED.
Step 3: Fund Wallet	Fund the wallet for the `customer` to make funds available to debit.
Step 4: Assign a Payment ID	Assign a a Payment ID to the `customer` wallet to define the funding source for transactions.

Requests for Information (RFIs)

For each scenario and detailed step, images and detailed instructions are provided for each stage in the testing process.

Payouts - Requests for Information (RFIs)

Request	Description
Step 1: Add Beneficiary V2	In the request body: Include TransactionCreditorHit in `beneficiaryName`. Set the beneficiary account number to 000987654322.
Step 2: Transfer Money	Transfer funds between payment sources.
Step 3: Fetch Remittance Life Cycle Status	Use the fetch remittance status and the `systemReferenceNumber` from the Transfer Money request and review the most recent `lastUpdatedAt#status` entry - confirm it returns ACTION_REQUIRED.
Step 4: Simulate Transaction Status	Set the next `status` as RFI_REQUESTED and set `requestInfoFor`.
Step 5: Fetch Remittance Life Cycle Status	Repeat Step 3 to confirm if the `status` has updated to RFI_REQUESTED.
Step 6: Respond to Transaction RFI	Respond to the RFI.
Step 7:Simulate Transaction Status	Set the `nextStatus` as `COMPLIANCE_COMPLETED`. Please note `REJECTED` is a permanent transaction `status`.
Step 8: Fetch Remittance Life Cycle Status	Repeat Step 3 to confirm if the `status` has updated to PAID.

Bank errors

Payouts - Bank Error

Request	Description
Step 1: Add Beneficiary V2	Set the beneficiary account number to 00098765991 to return a SENT_TO_BANK transaction status.
Step 2: Transfer Money	Create and process a `payout`.
Step 3: Fetch Remittance Life Cycle Status	Use the fetch remittance status and the `systemReferenceNumber` from the Transfer Money request and review the most recent `lastUpdatedAt#status` entry - confirm it returns SENT_TO_BANK.
Step 4: Simulate Transaction Status	Set the `nextStatus` as `PAID` or `ERROR`. Repeat Step 3 to verify if a new entry with the expected `status` .

System error

Payouts - System error

Request	Description
Step 1: Add Beneficiary V2	Set the beneficiary account number to 000712654321 to return an ERROR transaction status.
Step 2: Transfer Money	Create and process a `payout`.
Step 3: Fetch Remittance Life Cycle Status	Use the fetch remittance status and the `systemReferenceNumber` from the Transfer Money request and review the most recent `lastUpdatedAt#status` entry - confirm it returns ERROR.
Step 4: Simulate Transaction Status	Set the `nextStatus` as `PAID` or `ERROR`. Repeat Step 3 to verify if a new entry with the expected `status` .

Account owner returns

Payouts - Account owner Return

Request	Description
Step 1: Add Beneficiary V2	Set the beneficiary account number to 000987654322 to return a PAID transaction status.
Step 2: Transfer Money	Create and process a `payout`.
Step 3: Fetch Remittance Life Cycle Status	Use the fetch remittance status and the `systemReferenceNumber` from the Transfer Money request and review the most recent `lastUpdatedAt#status` entry - confirm it returns PAID.
Step 4: Simulate Transaction Status	Set the `nextStatus` as `RETURN`. Repeat Step 3 to verify if a new entry with the expected `status`

📌IMPORTANT

Onboarding

Individual customers

Corporate customers

Payouts

Requests for Information (RFIs)

Bank errors

System error

Account owner returns

📌
IMPORTANT