VerificationRequests

Submits the check rather than querying it: the receiving institution gets the outcome and acts on it. You get back a RequestId to reference the inquiry, plus a PASPRedirectionUrl where one applies.

It takes the same identity trio as the synchronous call, plus a Source and optional routing context.

Body — everything sits under a top-level Data object:

• Source (required) – which provider performs the check. The specification lists Saudi-Payment; ARB also works
• IBAN (required) – the IBAN being verified
• POIType (required) – the proof-of-identity type: NAT for a national ID, IQA for an iqama
• POINumber (required) – the ID number
• Meta (optional) – routing and context for the receiving institution. Meta itself is optional, so the minimal body is the four fields above:
  • FinancialInstitutionId (optional) – the target institution: RJHISARI, ALBISARI, INMASARI, BSFRSARI or SIBCSARI
  • PSUId (optional) – the Payment Service User identifier
  • UserLoginId (optional) – user login hint, for the decoupled authorisation profile
  • Purpose (optional) – array of strings
  • EchoList (optional) – name/value pairs returned back with the response, such as a channelRedirectionUrl

Headers:

curl -X POST 'https://test.api.neotek.sa/iban-verification-neotek/v1/verification-requests' \  -H 'Authorization: Bearer <ACCESS_TOKEN>' \  -H 'Content-Type: application/json' \  -d '{    "Data": {        "Source": "ARB",        "IBAN": "SA1080000012345678901001",        "POIType": "IQA",        "POINumber": "2345678901",        "Meta": {            "EchoList": [                {                    "Name": "channelRedirectionUrl",                    "Value": "https://www.example.com"                }            ]        }    }}'

Response

{    "Data": {        "RequestId": "8424"    }}

Errors