Skip to main content

​
Overview

This guide outlines the mandatory test scenarios for integrating with Inventi’s Verification of Payee (VoP) solution. You must complete all test scenarios in the test environment before moving to production.
Once you complete all test cases, notify the Inventi VoP Product Manager to proceed with production deployment.

​
General Testing Guidelines

​
Idempotency Requirement

All POST and PUT requests must include an Idempotency-Key header. This ensures that duplicate submissions are safely ignored by the system and is required across all integration environments.
--header 'Idempotency-Key: b7f3f8a2-9e0c-4d1e-8a2f-1234567890ab'

​
Testing Requirements

  • All expected results must be verified
  • All test cases listed in this document must be fully completed
  • Contact the Inventi VoP Product Manager after completion

​
Test Scenarios

  • Requesting PSP Tests
  • Data Import TEST (for responding PSP side)

​
VoP API - Verification Tests

These test scenarios verify your VoP API integration, ensuring correct name and identifier matching and proper response handling.
Scenario: Verify exact name matchRequest Payload:
{
  "iban": "LT927300000000000001",
  "account_holder_name": "Lukas Johnson"
}
Expected Result:
{
  "match_result": "MATCH"
}
Scenario: Verify fuzzy name matchingRequest Payload:
{
  "iban": "LT657300000000000002",
  "account_holder_name": "L. Johnson"
}
Expected Result:
{
  "match_result": "CLOSE_MATCH",
  "real_name": "Lukas Johnson"
}
The real_name field contains the actual registered account holder name. Always display this to the user for confirmation.
Scenario: Verify name mismatch detectionRequest Payload:
{
  "iban": "LT387300000000000003",
  "account_holder_name": "Thomas Allen"
}
Expected Result:
{
  "match_result": "NO_MATCH"
}
Scenario: Verify organization identifier matching
Skip this test if you only send VoP checks using account holder names and not organization identifiers.
Request Payload:
{
  "iban": "LT117300000000000004",
  "organisation_identification": {
    "lei": "123456789012345678"
  }
}
Expected Result:
{
  "match_result": "MATCH"
}
Scenario: Verify organization identifier mismatch
Skip this test if you only send VoP checks using account holder names and not organization identifiers.
Request Payload:
{
  "iban": "LT817300000000000005",
  "organisation_identification": {
    "lei": "123456789012345678"
  }
}
Expected Result:
{
  "match_result": "NO_MATCH"
}
Scenario: Verify handling when verification cannot be performedRequest Payload:
{
  "iban": "LT547300000000000006",
  "account_holder_name": "Anna Robbins"
}
Expected Result:
{
  "match_result": "CANNOT_VERIFY"
}
Scenario: Verify proper validation error handlingRequest Payload:
{
  "iban": "LT277300000000000007",
  "account_holder_name": " "
}
Expected Result:
HTTP 400 Bad Request
{
  "message": "accountHolderName must not be blank if provided"
}
Or:
{
  "message": "One of account_holder_name or organisation_identification must be provided"
}

​
Organization Identifiers

Responding PSPs should include organization identifiers (e.g., LEI, VAT) for all legal entity accounts to ensure accurate VoP validation.

​
Why Organization Identifiers Matter

When a Requesting PSP initiates a payment using IBAN + identifier (instead of a legal name), Inventi matches this against your imported data. If the identifier is missing, the request may return a NO_MATCH result, which could lead to payment failures.
A full list of supported identifiers can be found in the VoP API Reference.

​
Best Practices

Handle CLOSE_MATCH Carefully

Always treat CLOSE_MATCH differently from MATCH. Display the real_name field to the payer for confirmation before proceeding with the payment.Example:
{
  "match_result": "CLOSE_MATCH",
  "real_name": "Lukas Johnson"
}
Show: “Did you mean: Lukas Johnson?”

Use Aliases for Legal Entities

Include alias values when importing legal entity data to improve name-matching accuracy.Example:
  • Full name: “International Business Machines”
  • Alias: “IBM”
This improves matching flexibility when users enter common abbreviations.

Implement Idempotency Keys

Always include unique Idempotency-Key headers to prevent duplicate submissions.Use UUIDs or other unique identifiers:
Idempotency-Key: b7f3f8a2-9e0c-4d1e-8a2f-1234567890ab

Verify All Test Cases

Complete all test scenarios before requesting production access. Keep a record of:
  • Test case number
  • Request sent
  • Response received
  • Pass/Fail status