The following test cases have been implemented in the Testing Tool:
Response code validations.
Response schema validations.
Response data validations.
The tests below are a subset of a broader range of tests. New tests will be introduced gradually as the Ozone Testing Tool is updated and new versions of CBUAE Open Finance Standards are released.
1. Bank Data Test Cases
GET /accounts
...
Scenario
...
Response
...
Expected outcome
...
Valid accountIds are included as a query parameter, each with distinct SubTypes like CurrentAccount, Savings, and CreditCard for a retail user in Active status
...
200
The tests are in alignment with API Hub Documentation
Master Test Case List
| Expand |
|---|
| title | Click to view the test cases... |
|---|
|
|
Bank Data Sharing
GET /accounts
| Expand |
|---|
|
Test Scenario ID | Test ID | Dynamic Field | Test Name | Expected Response Code | Test Description |
|---|
ACC_010_001 Ensure that the API successfully retrieves account details for a valid accountId with the status 'Active', accountType 'Retail', and accountSubType 'CurrentAccount'. The test should confirm that the response includes the correct account information and returns a status code of 200, indicating successful retrieval. | AIS_A001 | accountToTest : Retail_CurrentAccount_Active | "Happy Path - Succeeds with status-Active, accountType-Retail and accountSubType-CurrentAccount fields are populated for valid accountId as query parameter (accountToTest : Retail_CurrentAccount_Active)" | 200 | "Returns a 200 if all headers are valid and returns a record for |
|
...
specified accountId including |
|
...
account type 'Retail' and account sub type 'CurrentAccount', for a retail user with status 'Active' |
|
...
" | AIS_A002 | accountToTest : Corporate_Savings_Inactive | "Happy Path - Succeeds with status-Inactive, accountType-Corporate and accountSubType-Savings fields are populated for |
|
...
Valid accountId which is in NotActive status
...
200
valid accountId as query parameter (accountToTest : Corporate_Savings_Inactive)" | 200 | "Returns a 200 if all headers are valid and |
|
...
Valid accountId which is in Dormant status
...
200
...
Returns a 200 if all headers are valid and the status of the account is Dormant
...
Valid accountId which is in Unclaimed status
...
200
returns a record for specified accountId including account type 'Corporate' and account sub type 'Savings', for a retail user with status 'Inactive'" | AIS_A003 | accountToTest : Corporate_CurrentAccount_Active | "Happy Path - Succeeds with status-Active, accountType-Corporate and accountSubType-CurrentAccount fields are populated for valid accountId as query parameter (accountToTest : Corporate_CurrentAccount_Active)" | 200 | "Returns a 200 if all headers are valid |
|
...
Valid accountId which is in Deceased status
...
200
...
Returns a 200 if all headers are valid and the status of the account is Deceased
...
Valid accountId which is in Suspended status
...
200
and returns a record for specified accountId including account type 'Corporate' and account sub type 'CurrentAccount', for a retail user with status 'Active'" | AIS_A004 | accountToTest : Retail_Savings_Inactive | "Happy Path - Succeeds with status-Inactive, accountType-Retail and accountSubType-Savings fields are populated for valid accountId as query parameter (accountToTest : Retail_Savings_Inactive)" | 200 | "Returns a 200 if all headers are valid and |
|
...
Valid accountId which is in Closed status
...
200
...
Returns a 200 if all headers are valid and the status of the account is Closed
...
returns a record for specified accountId including account type 'Retail' and account sub type 'Savings', for a retail user with status 'Inactive'" | AIS_A005 | accountToTest: Valid_Invalid_AccountIds | Happy Path - Succeeds with combination of valid and invalid accountIds (accountToTest: Valid_Invalid_AccountIds) | 200 | Returns a 200 if all headers are valid and returns a record for each valid accountId when both valid and invalid accountIds are specified |
|
...
No accounts found
...
200
...
Returns a 200 if all headers are valid no account information is found for the specified accountId
...
Missing accountIds query parameter
...
400
...
fails with 400 if accountIds query param is missing
...
(accountToTest : Valid_Invalid_AccountId) | AIS_A006 | accountToTest: Good_And_Badly_Formatted_AccountIds | Happy Path - Succeeds with mix of valid and invalid accountIds (accountToTest: Good_And_Badly_Formatted_AccountIds) | 200 | Returns a 200 if all headers are valid and |
|
...
returns a record for each valid accountId when |
|
...
both valid and invalid accountIds are specified |
|
...
(accountToTest : Good_And_Badly_Formatted_AccountIds) | AIS_A007 | accountToTest: AccountsWithNoCommas | Happy Path - Succeeds with non-comma-separated accountIds (accountToTest: AccountsWithNoCommas) | 200 | Returns a 200 |
|
...
GET /accounts/{accountId}
...
Scenario
...
Response
...
Expected outcome
...
Valid accountId has been provided: CurrentAccount for retail user in Active status
...
200
...
Returns a 200 status code when a valid current accountId is provided in the path parameter which should be present in the response body and the schema aligns with a CurrentAccount for Retail user in Active status
...
Valid accountId has been provided: CurrentAccount for SME user in Closed status
...
200
...
Returns a 200 status code when a valid current accountId is provided in the path parameter, and the schema aligns with a CurrentAccount for SME user in closed status
...
Valid accountId has been provided: CurrentAccount for Corporate user in Dormant status
...
200
...
Returns a 200 status code when a valid current accountId is provided in the path parameter, and the schema aligns with a CurrentAccount for Corporate user in Dormant status
...
Valid accountId has been provided :Savings for retail user in Suspended status
...
200
...
Returns a 200 status code when a valid current accountId is provided in the path parameter, and the schema aligns with a Savings account for retail user in Suspended status
...
Valid accountId has been provided :Savings for SME user in NotActive status
...
200
...
Returns a 200 status code when a valid current accountId is provided in the path parameter, and the schema aligns with a Savings account for SME user in NotActive status
...
Valid accountId has been provided :Savings for Corporate user
...
200
...
Returns a 200 status code when a valid current accountId is provided in the path parameter, and the schema aligns with a Savings account for Corporate user
...
Valid accountId has been provided: CreditCard for retail user
...
200
...
Returns a 200 status code when a valid current accountId is provided in the path parameter, and the schema aligns with a CreditCard account for retail user
...
Valid accountId has been provided: CreditCard for SME user
...
200
...
Returns a 200 status code when a valid current accountId is provided in the path parameter, and the schema aligns with a CreditCard account for SME user
...
Valid accountId has been provided: CreditCard for Corporate user
...
200
...
Returns a 200 status code when a valid current accountId is provided in the path parameter, and the schema aligns with a CreditCard account for Corporate user
...
A valid accountId has been provided: PrePaidCard for retail user
...
200
...
Returns a 200 status code when a valid current accountId is provided in the path parameter, and the schema aligns with a PrePaidCard account for retail user
...
A valid accountId has been provided: PrePaidCard for SME user
...
200
...
Returns a 200 status code when a valid current accountId is provided in the path parameter, and the schema aligns with a PrePaidCard account for SME user
...
A valid accountId has been provided: PrePaidCard for Corporate user
...
200
...
Returns a 200 status code when a valid current accountId is provided in the path parameter, and the schema aligns with a PrePaidCard account for Corporate user
...
Valid accountId has been provided: EMoney for retail user
...
200
...
Returns a 200 status code when a valid current accountId is provided in the path parameter, and the schema aligns with a EMoney account for retail user
...
Valid accountId has been provided: EMoney for SME user
...
200
...
Returns a 200 status code when a valid current accountId is provided in the path parameter, and the schema aligns with a EMoney account for SME user
...
Valid accountId has been provided: EMoney for Corporate user
...
200
...
Returns a 200 status code when a valid current accountId is provided in the path parameter, and the schema aligns with a EMoney account for Corporate user
...
Valid accountId has been provided: ChargeCard for SME user
...
200
...
Returns a 200 status code when a valid current accountId is provided in the path parameter, and the schema aligns with a ChargeCard account for SME user
...
Valid accountId has been provided: ChargeCard for Corporate user
...
200
...
Returns a 200 status code when a valid current accountId is provided in the path parameter, and the schema aligns with a ChargeCard account for Corporate user
...
Valid accountId has been provided: ChargeCard for Retail user
...
200
...
Returns a 200 status code when a valid current accountId is provided in the path parameter, and the schema aligns with a ChargeCard account for Retail user
...
Valid accountId has been provided: Other for Retail
...
200
...
Returns a 200 status code when a valid current accountId is provided in the path parameter, and the schema aligns with a Other account for Retail user
...
Valid accountId has been provided: Other for Corporate
...
200
...
Returns a 200 status code when a valid current accountId is provided in the path parameter, and the schema aligns with a Other account for Corporate user
...
Valid accountId has been provided: Other for SME
...
200
...
Returns a 200 status code when a valid current accountId is provided in the path parameter, and the schema aligns with a Other account for SME user
GET /accounts/{accountId}/balances
back t
Scenario
...
Response
...
Expected outcome
...
Valid accountId provided in the path parameter which has positive balance and credit line included
Note: Repeat the test for all eligible account types within the defined scope.
...
200
...
Returns a status code of 200 if all headers are valid and also retrieves the balances of the specified accountId , where the creditDebitIndicator value is 'credit', and the CreditLines are populated with relevant details.
...
Valid accountId provided in the path parameter which has negative balance and credit line not included
...
200
...
Returns a status code of 200 if all headers are valid and also retrieves the balances of the specified accountId, where the creditDebitIndicator value is 'debit', and the CreditLines object is not present.
Note: Add additional validations to check the schema of the amount especially for whole number to have the decimal formatting as required.
...
Valid accountId provided in the path parameter which has zero balance
...
200
...
Returns a 200 if all headers are valid and Returns balances of specified accountId with creditDebitIndicator value as ‘credit’
Note: A zero balance is considered to be a credit balance.
...
Valid accountId provided in the path parameter which holds international currency
...
200
...
Returns a 200 if all headers are valid and Returns balance in international currency of 3 character alphabetic code
...
Valid accountId provided in the path parameter which has more than one balanceType and balanceType query param is not supplied
...
200
...
Returns a status code of 200 if all headers are valid and provides the balances associated with the specified accountId, including all available balance types for that account.
...
Returns empty response when balanceType passed in the query param doesn’t fetch any response
...
200
...
Returns a 200 with empty array
...
Return balances when a specific ‘{balanceType}’ is passed in the request
...
200
...
Returns a 200 if all headers are valid and Returns only balance with type '{balanceType}'
...
Returns 400 response when balanceType is not valid
...
400
...
fails with 400 if balanceType is invalid
...
Invalid accountId
...
400
...
fails with 400 if accountId format is invalid
...
Missing accountId path parameter
...
401
...
fails with 401 if accountId path param is missing
GET /accounts/{accountId}/beneficiaries
...
Scenario
...
Response
...
Expected outcome
...
A valid accountId is provided in the path parameter, which contains payees categorised as 'Activated' and 'NotActivated' under the BeneficiaryType.
...
200
...
Returns a 200 if all headers are valid and Returns beneficiaries of specified accountId
...
A valid accountId is provided in the path parameter, which contains payees having AddressType as Business, Correspondence, DeliveryTo,MailTo,POBox,Postal,Residential,Statement
...
200
...
Returns a 200 with multiple payees in the response which has addressTypes as Business, Correspondence, DeliveryTo,MailTo,POBox,Postal,Residential,Statement
...
Valid accountId provided in the path parameter which has a empty payees
...
200
...
Returns a 200 with empty array if all headers are valid accountId Returns no payees
...
Missing accountId path parameter
...
400
...
fails with 400 if accountId is missing
...
Invalid accountId
...
400
...
fails with 400 if accountId format is invalid
GET /accounts/{accountId}/transactions
...
Scenario
...
Response
...
Expected outcome
...
Valid accountId provided in the path parameter which has a list of transactions
...
200
...
Returns a 200 if all headers are valid and Returns transactions of specified accountId
...
Filter the transactions based on fromBookingDateTime query param
...
200
...
Returns a 200 with list of transactions from
fromBookingDateTime until latest available transaction
...
Filter the transactions based on toBookingDateTime query param
...
200
...
Returns a 200 with list of transactions from
the earliest available transaction till toBookingDateTime
...
Filter the transactions based on fromBookingDateTime and toBookingDateTime query params
...
200
...
Returns a 200 with list of transactions within
fromBookingDateTime and toBookingDateTime query params
...
Valid accountId provided in the path parameter which has empty transactions
...
200
...
Returns a 200 with empty array if all headers are valid accountId Returns no transactions
...
Return error response when toBookingDateTime is before fromBookingDateTime
...
400
...
Returns 400 when toBookingDateTime is before fromBookingDateTime
...
Return error when fromBookingDateTime is invalid
...
400
...
Returns 400 when fromBookingDateTime is invalid
...
Return error when toBookingDateTime is invalid
...
400
...
Returns 400 when toBookingDateTime is invalid
...
Invalid accountId
...
400
...
fails with 400 if accountId format is invalid
GET /customer
...
id
...
Scenario
...
Response
...
Expected outcome
...
CUS-010-040
...
Valid o3-psu-identifier provided in the header which belongs to a retail user
...
200
...
Returns a 200 status code with details of a retail user in the response as per the schema
...
Valid o3-psu-identifier provided in the header which belongs to a corporate user
...
200
...
Returns a 200 status code with details of a corporate user in the response as per the schema
...
Valid o3-psu-identifier provided in the header which belongs to a SME user
...
200
...
Returns a 200 status code with details of a SME user in the response as per the schema
...
CUS-010-190
...
Valid o3-psu-identifier provided in the header which has no customer associated
...
200
...
Returns a 200 status code with empty data object
back to top
GET /accounts/{accountId}/customer
...
Scenario
...
Response
...
Expected outcome
...
A valid accountId is provided in the path parameter
...
200
...
Returns a 200 status code when all headers are valid and provides the associated customer details linked to the accountId provided in the request
Note: Make sure in the schema validations, fields required for the chosen customer type are returned by LFI correctly
...
Valid accountId provided in the path parameter which has no associated parties
...
200
...
Returns a 200 status code with empty data array
GET /accounts/{accountId}/direct-debits
...
Scenario
...
Response
...
Expected outcome
...
Valid accountId provided in the path parameter which has direct-debits in Active and Inactive status
...
200
...
Returns a 200 if all headers are valid and Returns direct-debits of specified accountId in descending/ascending order of which date?
...
Valid accountId provided in the path parameter which has direct-debits of frequencies Annual, Daily,Fortnightly, HalfYearly,Monthly,NotKnown,Quartely, Weekly
...
200
...
Returns a 200 if all headers are valid and Returns direct-debits of specified account which has direct-debits of frequencies Annual, Daily,Fortnightly, HalfYearly,Monthly,NotKnown,Quartely, Weekly
...
Valid accountId provided in the path parameter which has a empty direct debits
...
200
...
Returns a 200 with empty array if all headers are valid and accountId Returns no direct-debits
...
Missing accountId path parameter
...
400
...
fails with 400 if accountId is missing
...
Invalid accountId
...
400
...
fails with 400 if accountId format is invalid
GET /accounts/{accountId}/scheduled-payments
...
Scenario
...
Response
...
Expected outcome
...
Valid accountId provided in the path parameter which has scheduled-payments in “Arrival” and “Execution” states
...
200
...
Returns a 200 if all headers are valid and Returns scheduled-payments of specified accountId in descending/ascending order of which date?
...
Valid accountId provided in the path parameter which has creditorAccount schemeName as IBAN and AccountNumber
...
200
...
Returns a 200 if all headers are valid and Returns scheduled-payments of specified accountId with correct creditoraccountIdentification
...
Valid accountId provided in the path parameter which has a empty Schedule Payments
...
200
...
Returns a 200 with empty array if all headers are valid and accountId Returns no scheduled-payments
...
Missing accountId path parameter
...
400
...
fails with 400 if accountId is missing
...
Invalid accountId
...
400
...
fails with 400 if accountId format is invalid
GET /accounts/{accountId}/standing-orders
...
Scenario
...
Response
...
Expected outcome
...
Valid accountId provided in the path parameter which has standing-orders in Active and Inactive status
...
200
...
Returns a 200 if all headers are valid and Returns standing-orders of specified accountId
...
Valid accountId provided in the path parameter which has standing-orders of type BetweenMyAccounts, SameBankTransfer, LocalBankTransfer, InternationalTransfer, Charity
...
200
...
Returns a 200 if all headers are valid and Returns standing-orders of specified accountId which has different SOs like BetweenMyAccounts, SameBankTransfer, LocalBankTransfer, InternationalTransfer, Charity
...
Valid accountId provided in the path parameter which has a empty standing-orders
...
200
...
Returns a 200 with empty array if all headers are valid and accountId Returns no standing-orders
...
Missing accountId path parameter
...
401
...
fails with 401 if accountIdis missing
...
Invalid accountId
...
400
...
fails with 400 if accountId format is invalid
POST /customers/action/cop-query
...
Scenario
...
Response
...
Expected outcome
...
A valid request with schemeName as IBAN for retail user
...
200
...
Returns a 200 status code when all headers are valid and provides the associated customer details linked to the IBAN provided in the request for Retail user
...
A valid request with schemeName as IBAN for business user
...
200
...
Returns a 200 status code when all headers are valid and provides the associated customer details linked to the IBAN provided in the request for Business user
...
Negative Test - A request with invalid IBAN for a Retail user
...
200
...
Returns a 200 with empty data object
...
An invalid request with missing fields for retail user
...
400
...
Returns 400 error response
...
An invalid request with missing fields for business user
...
400
...
Returns 400 error response
...
A valid request with schemeName as IBAN for a Retail user and o3-psu-identifier and o3-consent-id are not provided as these fields are not mandatory
...
200
...
Returns a 200 status code when all headers are valid and o3-psu-identifier and o3-consent-id headers are not provided in the request
Common header validations for AIS and PIS endpoints:
...
Scenario
...
Response
...
Expected outcome
...
Fail if o3-psu-identifier header is missing
...
400
...
Fail if o3-psu-identifier header is missing with status 400 and correct schema
...
Fail if o3-api-uri header is missing
...
400
...
Fail if o3-api-uri header is missing with status 400 and correct schema
...
Fail if o3-api-operation header is missing
...
400
...
Fail if o3-api-operation header is missing with status 400 and correct schema
...
Fail if o3-aspsp-id header is missing
...
400
...
Fail if o3-aspsp-id header is missing with status 400 and correct schema
...
Fail if o3-ozone-interaction-id header is missing
...
400
if all headers are valid and returns an empty array when non-comma-separated accountIds are specified (accountToTest : AccountsWithNoCommas) | ACC_010_002 Ensure that the API correctly handles the scenario where the accountIds query parameter is missing/invalid returning an appropriate error response. | AIS_A008 | accountToTest : NoAccount | Negative Test - Fails if accountIds query parameter is missing (accountToTest : NoAccount) | 400 | "If accountIds path parameter is missing, the API must return a 400 and an error body" | AIS_A009 | accountToTest : Invalid_Single_AccountId | Negative Test - Fails if accountId format is invalid (accountToTest : Invalid_Single_AccountId) | 400 | "If the accountId format is invalid, the API must return a 400 and an error body" | ACC_010_003 Ensure that the API correctly validates mandatory headers. | AIS_A010 | accountToTest : NoAccount | Negative Test - Mandatory field validation - Fail if both accountId and o3-psu-identifier are missing (accountToTest : NoAccount) | 400 | The operation must fail with a status of 400 if both the accountId path parameter and the o3-psu-identifier header parameter are missing | AIS_A011 | accountToTest : SampleAccount | Negative Test - Mandatory header validation - Fail if o3-psu-identifier header is missing (accountToTest : SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-psu-identifier header is missing with accountId passed as query parameter | AIS_A012 | accountToTest : SampleAccount | Negative Test - Mandatory header validation - Fail if o3-api-uri header is missing (accountToTest : SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-api-uri header is missing with accountId passed as query parameter | AIS_A013 | accountToTest : SampleAccount | Negative Test - Mandatory header validation - Fail if o3-api-operation header is missing(accountToTest : SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-api-operation header is missing with accountId passed as query parameter | AIS_A014 | accountToTest : SampleAccount | Negative Test - Mandatory header validation - Fail if o3-aspsp-id header is missing(accountToTest : SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-aspsp-id header is missing with accountId passed as query parameter | AIS_A015 | accountToTest : SampleAccount | Negative Test - Mandatory header validation - Fail if o3-ozone-interaction-id header is missing(accountToTest : SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-ozone-interaction-id header is missing with accountId passed as query parameter | AIS_A016 | accountToTest : SampleAccount | Negative Test - Mandatory header validation - Fail if o3-provider-id header is missing(accountToTest : SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-provider-id header has an unexpected value with accountId passed as query parameter | AIS_A017 | accountToTest : SampleAccount | Negative Test - Mandatory header validation - Fail if o3-caller-org-id header is missing(accountToTest : SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-caller-org-id header is missing with accountId passed as query parameter | AIS_A018 | accountToTest : SampleAccount | Negative Test - Mandatory header validation - Fail if o3-caller-client-id header is missing(accountToTest : SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-caller-client-id header is missing with accountId passed as query parameter | AIS_A019 | accountToTest : SampleAccount | Negative Test - Mandatory header validation - Fail if o3-caller-software-statement-id header is missing(accountToTest : SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-caller-software-statement-id header is missing with accountId passed as query parameter | AIS_A020 | accountToTest : SampleAccount | Negative Test - Mandatory header validation - Fail if o3-consent-id header is missing (accountToTest : SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-consent-id header is missing with accountId passed as query parameter | AIS_A021 | accountToTest : SampleAccount | Negative Test - Fails if o3-aspsp-id has an invalid value(accountToTest : SampleAccount) | 400 | "If o3-aspsp-id has an invalid value with accountId passed as query parameter, the API must return a 400 and an error body" | AIS_A022 | accountToTest : SampleAccount | Negative Test - Fails if o3-psu-identifier is not b64 encoded(accountToTest : SampleAccount) | 400 | "If o3-psu-identifier is not b64 encoded with accountId passed as query parameter, the API must return a 400 and an error body" | AIS_A023 | accountToTest : SampleAccount | Negative Test - Fails if o3-psu-identifier does not evaluate to a json structure (accountToTest : SampleAccount) | 400 | "If o3-psu-identifier does not evaluate to a json structure with accountId passed as query parameter, the API must return a 400 and an error body" | AIS_A024 | accountToTest : SampleAccount | Negative Test - Fails if o3-psu-identifier does not contain userId (accountToTest : SampleAccount) | 400 | "If o3-psu-identifier does not contain userId with accountId passed as query parameter, the API must return a 400 and an error body" |
|
Back to top
GET /accounts/{accountId}
| Expand |
|---|
|
Test Scenario ID | Test ID | Dynamic Field | Test Name | Expected Response Code | Test Description |
|---|
ACC_020_001 Ensure the API effectively retrieves account details when a valid Account & Account Sub-Type combination that is in either Active or Inactive status when the accountId is supplied as a path parameter. The test should confirm that the response includes the correct account information and returns a status code of 200. | AIS_AA001 | accountToTest : SME_CurrentAccount_Active | Happy Path - Succeeds with valid CurrentAccount for SME user in Active status for valid accountId as path parameter (accountToTest : SME_CurrentAccount_Active) | 200 | "Returns a 200 if all headers are valid and returns a record for specified accountId including account type 'SME' and account sub type 'CurrentAccount', for a SME user with status 'Active'" | AIS_AA002 | accountToTest : Corporate_Savings_Inactive | Happy Path - Succeeds with valid Savings for corporate user in Inactive status for valid accountId as path parameter (accountToTest : Corporate_Savings_Inactive) | 200 | "Returns a 200 if all headers are valid and returns a record for specified accountId including account type 'Corporate' and account sub type 'Savings', for a corporate user with status 'Inactive'" | AIS_AA003 | accountToTest : Retail_CurrentAccount_Active | Happy Path - Succeeds with valid CurrentAccount for retail user in Active status for valid accountId as path parameter (accountToTest : Retail_CurrentAccount_Active) | 200 | "Returns a 200 if all headers are valid and returns a record for specified accountId including account type 'retail' and account sub type 'CurrentAccount', for a retail user with status 'Active'" | AIS_AA004 | accountToTest : Retail_Savings_Inactive | Happy Path - Succeeds with valid Savings for retail user in Inactive status for valid accountId as path parameter (accountToTest : Retail_Savings_Inactive) | 200 | "Returns a 200 if all headers are valid and returns a record for specified accountId including account type 'retail' and account sub type 'Savings', for a retail user with status 'Inactive'" | AIS_AA005 | accountToTest: Corporate_CurrentAccount_Active | Happy Path - Succeeds with valid CurrentAccount for Corporate user in Active status for valid accountId as path parameter (accountToTest: Corporate_CurrentAccount_Active) | 200 | "Returns a 200 if all headers are valid and returns a record for specified accountId including account type 'Corporate' and account sub type 'CurrentAccount', for a corporate user with status 'Active'" | ACC_020_002 Ensure that the API correctly handles the scenario where the accountId path parameter is missing returning an appropriate error response. | AIS_AA006 | accountToTest : NoAccount | Negative Test - Fails if accountId path parameter is missing (accountToTest : NoAccount) | 400 | "If accountIds path parameter is missing, the API must return a 401 and an error body" | ACC_020_003 Ensure that the API correctly validates mandatory headers. | AIS_AA007 | accountToTest : SampleAccount | Negative Test - Mandatory header validation - Fail if o3-psu-identifier header is missing (accountToTest : SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-psu-identifier header is missing with accountId passed as path parameter | AIS_AA008 | accountToTest : SampleAccount | Negative Test - Mandatory header validation - Fail if o3-api-uri header is missing (accountToTest : SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-api-uri header is missing with accountId passed as path parameter | AIS_AA009 | accountToTest : SampleAccount | Negative Test - Mandatory header validation - Fail if o3-api-operation header is missing (accountToTest : SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-api-operation header is missing with accountId passed as path parameter | AIS_AA010 | accountToTest : SampleAccount | Negative Test - Mandatory header validation - Fail if o3-aspsp-id header is missing (accountToTest : SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-aspsp-id header is missing with accountId passed as path parameter | AIS_AA011 | accountToTest : SampleAccount | Negative Test - Mandatory header validation - Fail if o3-ozone-interaction-id header is missing (accountToTest : SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-ozone-interaction-id header is missing with accountId passed as path parameter | AIS_AA012 | accountToTest : SampleAccount | Negative Test - Mandatory header validation - Fail if o3-provider-id header is missing (accountToTest : SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-provider-id header has an unexpected value with accountId passed as path parameter | AIS_AA013 | accountToTest : SampleAccount | Negative Test - Mandatory header validation - Fail if o3-caller-org-id header is missing (accountToTest : SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-caller-org-id header is missing with accountId passed as path parameter | AIS_AA014 | accountToTest : SampleAccount | Negative Test - Mandatory header validation - Fail if o3-caller-client-id header is missing (accountToTest : SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-caller-client-id header is missing with accountId passed as path parameter | AIS_AA015 | accountToTest : SampleAccount | Negative Test - Mandatory header validation - Fail if o3-caller-software-statement-id header is missing (accountToTest : SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-caller-software-statement-id header is missing with accountId passed as path parameter | AIS_AA016 | accountToTest : SampleAccount | Negative Test - Mandatory header validation - Fail if o3-consent-id header is missing (accountToTest : SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-consent-id header is missing with accountId passed as path parameter | AIS_AA017 | accountToTest : SampleAccount | Negative Test - Fails if o3-aspsp-id has an invalid value (accountToTest : SampleAccount) | 400 | "If o3-aspsp-id has an invalid value with accountId passed as path parameter, the API must return a 400 and an error body" | AIS_AA018 | accountToTest : SampleAccount | Negative Test - Fails if o3-psu-identifier is not b64 encoded (accountToTest : SampleAccount) | 400 | "If o3-psu-identifier is not b64 encoded with accountId passed as path parameter, the API must return a 400 and an error body" | AIS_AA019 | accountToTest : SampleAccount | Negative Test - Fails if o3-psu-identifier does not evaluate to a json structure (accountToTest : SampleAccount) | 400 | "If o3-psu-identifier does not evaluate to a json structure with accountId passed as path parameter, the API must return a 400 and an error body" | AIS_AA020 | accountToTest : SampleAccount | Negative Test - Fails if o3-psu-identifier does not contain userId (accountToTest : SampleAccount) | 400 | "If o3-psu-identifier does not contain userId with accountId passed as path parameter, the API must return a 400 and an error body" | AIS_AA021 | accountToTest: SampleAccount | "Negative Test - Fails if o3-psu-identifier header is invalid - the decoded value is valid JSON, but userId is null, empty or undefined (accountToTest: SampleAccount)" | 400 | "If o3-psu-identifier header is invalid - the decoded value is valid JSON, but userId is null, empty or undefined , the API must return a 400 and an error body" | AIS_AA022 | accountToTest: SampleAccount | "Negative Test - Fails if o3-psu-identifier header is invalid - the decoded value is valid JSON, but userId is not a string (accountToTest: SampleAccount)" | 400 | "If o3-psu-identifier header is invalid - the decoded value is valid JSON, but userId is not a string and , the API must return a 400 and an error body" |
|
Back to top
GET /accounts/{accountId}/balances
| Expand |
|---|
|
Test Scenario ID | Test ID | Dynamic Field | Test Name | Expected Response Code | Test Description |
|---|
BAL_010_001 Ensure that valid accountId returns balance details. | AIS_BA001 | accountToTest: Valid_Accounts_List | Happy path - Succeeds if valid accountId in path parameter returns balances (accountToTest: Valid_Accounts_List) | 200 | Valid accountId provided in the path parameter should return a 200 and the accountId must be present in the response with balance details | AIS_BA002 | accountToTest: AccountIdWithCreditIndicator | Happy path - Succeeds if valid accountId in path parameter returns balances with positive balance and credit line included (accountToTest: AccountIdWithCreditIndicator) | 200 | Valid accountId provided in the path parameter should return a 200 and the accountId must be present in the response with balance detail where the creditDebitIndicator value is Credit and the CreditLines are populated with relevant details | AIS_BA003 | accountToTest: AccountIdWithZeroCreditIndicator | Happy path - Succeeds if valid accountId in path parameter returns zero balance with creditDebitIndicator value as 'credit' (accountToTest: AccountIdWithZeroCreditIndicator) | 200 | Valid accountId provided in the path parameter which has zero balance should return a 200 and the accountId must be present in the response with balance detail where the creditDebitIndicator value is Credit | BAL_010_002 Ensure that the API correctly handles missing accountIds path parameter. | AIS_BA004 | accountToTest: NoAccount | Negative Test - Fails if accountIds path parameter is missing (accountToTest: NoAccount) | 400 | "If accountIds path parameter is missing, the API must return a 400 and an error body" | AIS_BA005 | accountToTest: Invalid_Single_AccountId | Negative Test - Fails if accountId format is invalid (accountToTest: Invalid_Single_AccountId) | 400 | "If the accountId format is invalid , the API must return a 400 and an error body" | BAL_010_003 Ensure that the API correctly validates mandatory headers. | AIS_BA006 | accountToTest: NoAccount | Negative Test - Mandatory field validation - Fail if both accountId and o3-psu-identifier are missing (accountToTest: NoAccount) | 400 | The operation must fail with a status of 400 if both the accountId path parameter and the o3-psu-identifier header parameter are missing | AIS_BA007 | accountToTest: SampleSingleAccount | Negative Test - Mandatory header validation - Fail if o3-psu-identifier header is missing (accountToTest: SampleSingleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-psu-identifier header is missing | AIS_BA008 | accountToTest: SampleSingleAccount | Negative Test - Mandatory header validation - Fail if o3-api-uri header is missing (accountToTest: SampleSingleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-api-uri header is missing | AIS_BA009 | accountToTest: SampleSingleAccount | Negative Test - Mandatory header validation - Fail if o3-api-operation header is missing (accountToTest: SampleSingleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-api-operation header is missing | AIS_BA010 | accountToTest: SampleSingleAccount | Negative Test - Mandatory header validation - Fail if o3-aspsp-id header is missing (accountToTest: SampleSingleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-aspsp-id header is missing | AIS_BA011 | accountToTest: SampleSingleAccount | Negative Test - Mandatory header validation - Fail if o3-ozone-interaction-id header is missing (accountToTest: SampleSingleAccount) | 400 | The operation must fail with a status code 400 and |
|
...
...
ozone-interaction-id header is missing |
|
...
400
| AIS_BA012 | accountToTest: SampleSingleAccount | Negative Test - Mandatory header validation - Fail if o3-provider-id header is missing (accountToTest: SampleSingleAccount) | 400 | The operation must fail with a status code 400 and |
|
...
...
...
400
has an unexpected value | AIS_BA013 | accountToTest: SampleSingleAccount | Negative Test - Mandatory header validation - Fail if o3-caller-org-id header is missing (accountToTest: SampleSingleAccount) | 400 | The operation must fail with a status code 400 and |
|
...
error body if the o3-caller- |
|
...
...
400
AIS_BA014 | accountToTest: SampleSingleAccount | Negative Test - Mandatory header validation - Fail if o3-caller-client-id header is missing (accountToTest: SampleSingleAccount) | 400 | The operation must fail with a status code 400 and |
|
...
error body if the o3-caller- |
|
...
client-id header is missing |
|
...
400
AIS_BA015 | accountToTest: SampleSingleAccount | Negative Test - Mandatory header validation - Fail if o3-caller-software-statement-id header is missing (accountToTest: SampleSingleAccount) | 400 | The operation must fail with a status code 400 and |
|
...
error body if the o3-caller-software-statement-id header is missing |
|
...
400
...
AIS_BA016 | accountToTest: SampleSingleAccount | Negative Test - Mandatory header validation - Fail if o3-consent-id header is missing (accountToTest: SampleSingleAccount) | 400 | The operation must fail with a status code 400 and |
|
...
error body if the o3-consent-id header is |
|
...
400
...
Fail if o3-consent-id header is having invalid value with status 400 and correct schema
...
Fail if o3-caller-software-statement-id header is having invalid value
...
400
...
Fail if o3-caller-software-statement-id header is having invalid value with status 400 and correct schema
...
Fail if o3-caller-client-id header is having invalid value
...
400
...
Fail if o3-caller-client-id header is having invalid value with status 400 and correct schema
...
Fail if o3-caller-org-id header is having invalid value
...
400
...
Fail if o3-caller-org-id header is having invalid value with status 400 and correct schema
...
Fail if o3-provider-id header is having invalid value
...
400
...
Fail if o3-provider-id header is having invalid value with status 400 and correct schema
missing | AIS_BA017 | accountToTest: SampleSingleAccount | Negative Test - Fails if o3-psu-identifier is not b64 encoded (accountToTest: SampleSingleAccount) | 400 | "If o3-psu-identifier is not b64 encoded, the API must return a 400 and an error body" | AIS_BA018 | accountToTest: SampleSingleAccount | Negative Test - Fails if o3-psu-identifier does not evaluate to a json structure (accountToTest: SampleSingleAccount) | 400 | "If o3-psu-identifier does not evaluate to a json structure, the API must return a 400 and an error body" | AIS_BA019 | accountToTest: SampleSingleAccount | Negative Test - Fails if o3-psu-identifier does not contain userId (accountToTest: SampleSingleAccount) | 400 | "If o3-psu-identifier does not contain userId, the API must return a 400 and an error body" | AIS_BA020 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-ozone-interaction-id header is having invalid value (accountToTest: SampleAccount) | 400 |
|
...
The operation must fail with a status code 400 and error body if the o3-ozone-interaction-id header is having invalid value |
|
...
| AIS_BA021 | accountToTest: SampleAccount | "Negative Test - Fails if o3- |
|
...
...
...
invalid - the decoded value is valid JSON, but userId is null, empty or undefined (accountToTest: SampleAccount)" | 400 |
|
...
...
...
...
...
Fail if o3-api-operation header is having invalid value
...
400
...
Fail if o3-api-operation header is having invalid value with status 400 and correct schema
...
Fail if o3-api-uri header is having invalid value
...
400
...
Fail if o3-api-uri header is having invalid value with status 400 and correct schema
...
Fail if o3-psu-identifier header is having invalid value
...
400
...
Fail if o3-psu-identifier header is having invalid value with status 400 and correct schema
...
Fails if o3-psu-identifier is not b64 encoded
...
400
...
Fails if o3-psu-identifier is not b64 encoded with status 400 and correct schema
...
Fails if o3-psu-identifier does not evaluate to a json structure
...
400
...
Fails if o3-psu-identifier does not evaluate to a json structure, with status 400 and correct schema
...
Fails if o3-psu-identifier does not contain userId
...
400
...
Fails if o3-psu-identifier does not contain userId, with status 400 and correct schema
...
Fails if o3-psu-identifier header is invalid - the decoded value is valid JSON, but userId is null, empty or undefined
...
400
...
Fails if o3-psu-identifier header is invalid - the decoded value is valid JSON, but userId is null, empty or undefined, with status 400 and correct schema
...
Fails if o3-psu-identifier header is invalid - the decoded value is valid JSON, but userId is not a string
...
400
...
Fails if o3-psu-identifier header is invalid - the decoded value is valid JSON, but userId is not a string, with status 400 and correct schema
2. Bank Service Test Cases
Single Payments
...
Scenario
...
Response
...
Expected outcome
...
POST /payments
Domestic single payment Consumer to Consumer:Successful response from LFI when the request is valid
Note: Test cases for different account types like SME, Retail and Corporate have been added. The intention of these tests is to make sure that different users are able to make payments to different types of creditors as applicable.
...
201
...
Returns a 201 status code with paymentId in the response body for a domestic payment from consumer to consumer
...
Get payments
Inquire a 'Pending' Single Immediate domestic payment
Note: When conducting the tests as described above, the main goal is to verify that all payments in different statuses can be accessed with the accurate schema and data structure.
...
200 with payment details in the response
...
Returns a 200 with status 'Pending'
Get /payments
...
Note: As a pre-requisite need to post a payment which triggers business rules to get rejected and inquire that in Get endpoint
...
200
...
Returns a 200 with status 'Rejected' and with reason object populated with details
...
Negative Test - Fail if paymentType field in the request body is missing
...
400
...
Error response
...
Negative Test - Fail if PersonalIdentifiableInformation field in the request body is missing.
...
400
...
Error response
...
Negative Test - Fail if PaymentPurposeCode field in the request body is missing
...
400
...
Error response
...
Negative Test - Fail if ConsentId field in the request body is missing
...
400
...
Error response
...
Negative Test - Fail if payment amount is above the available balance
...
400
...
Error response
...
POST /payments
Domestic Future Dated payment:Successful response when the request is valid
Note: the tests are repeated for different users like SME, Corporate and Retail
...
201
Returns a 201 status code with paymentId in the response body for a domestic payment when executionDate in the payload is a future date
...
Get /payments/{paymentId}
Inquire a 'Pending' Future dated payment
Note: When conducting the tests as described above, the main goal is to verify that all payments in different statuses can be accessed with the accurate schema and data structure.
...
200 with payment details in the response
...
Returns a 200 with status 'Pending'
...
The below status’s might not be feasible to validate , but GET /payment should supports these different status’s
Inquire a 'AcceptedSettlementInProcess' Single Immediate Domestic payment
...
200
...
Returns a 200 with status 'AcceptedSettlementInProcess'
...
Inquire a 'AcceptedSettlementCompleted' Single Immediate Domestic payment
...
200
...
Returns a 200 with status 'AcceptedSettlementCompleted'
...
Inquire a 'AcceptedWithoutPosting' Single Immediate Domestic payment
...
200
...
Returns a 200 with status 'AcceptedWithoutPosting'
...
Inquire a 'AcceptedWithoutPosting' Single Immediate Domestic payment
...
200
...
Returns a 200 with status 'AcceptedWithoutPosting' and data initially used to post the payment
Multi Payments
The below endpoints support multi-payment functionality and tests are added across these endpoints to facilitate different variations of multi-payments
POST consent/action/augment
POST consent/action/validate
POST /consent/event/{operation}
POST /payments
GET /payments/{paymentId}
...
Scenario
...
Response
...
Expected outcome
FixedDefinedSchedule
...
201
...
Successful payment for a consent set-up for FixedDefinedSchedule
...
VariableDefinedSchedule
...
201
...
Successful payment for a consent set-up for VariableDefinedSchedule
...
FixedPeriodicSchedule
...
201
...
Successful payment for a consent set-up for FixedPeriodicSchedule
...
VariablePeriodicSchedule
...
201
...
Successful payment for a consent set-up for VariablePeriodicSchedule
...
FixedOnDemand
...
201
...
Successful payment for a consent set-up for FixedOnDemand
...
VariableOnDemand
...
201
...
Successful payment for a consent set-up for VariableOnDemand
Combined Payments
The below endpoints support combined-payment functionality and tests are added across these endpoints to facilitate different variations of combined payments
POST consent/action/augment
POST consent/action/validate
POST /consent/event/{operation}
POST /payments
GET /payments/{paymentId}
...
Scenario
...
Response
...
Expected outcome
Single Immediate Payment (SIP) + FixedDefinedSchedule
...
201
...
Successful payment as part of the consent set-up for a combined payment
...
SIP + VariableDefinedSchedule
...
201
...
Successful payment as part of the consent set-up for a combined payment
...
SIP + FixedPeriodicSchedule
...
201
...
Successful payment as part of the consent set-up for a combined payment
...
SIP + VariablePeriodicSchedule
...
201
...
Successful payment as part of the consent set-up for a combined payment
...
SIP + FixedOnDemand
...
201
...
Successful payment as part of the consent set-up for a combined payment
...
SIP + VariableOnDemand
...
201
...
Successful payment as part of the consent set-up for a combined payment
Future Dated Payment (FDP) + FixedDefinedSchedule
...
201
...
Successful payment as part of the consent set-up for a combined payment
...
FDP + VariableDefinedSchedule
...
201
...
Successful payment as part of the consent set-up for a combined payment
...
FDP + FixedPeriodicSchedule
...
201
...
Successful payment as part of the consent set-up for a combined payment
...
FDP + VariablePeriodicSchedule
...
201
...
Successful payment as part of the consent set-up for a combined payment
...
FDP + FixedOnDemand
...
201
...
Successful payment as part of the consent set-up for a combined payment
...
FDP + VariableOnDemand
...
201
...
Successful payment as part of the consent set-up for a combined payment
GET payments/{report-file}
...
Scenario
...
Response
...
Expected outcome
...
Succeeds if valid paymentId in path parameter returns file name
...
200
...
Return a 200 status with correct schema and file name in response
...
Invalid paymentId in path parameter
...
400
...
Invalid paymentId provided in the path parameter should return a 400 status code and correct schema
...
Fail if paymentId in path parameter is missing
...
400
...
The paymentId in the path parameter is missing, should return a 400 status code and correct schema
3. Insurance Test Cases
<TODO>
4. Health Check Test Cases
...
- the decoded value is valid JSON, but userId is null, empty or undefined, the API mus t return a 400 and an error body" | AIS_BA022 | accountToTest: SampleAccount | "Negative Test - Fails if o3-psu-identifier header is invalid - the decoded value is valid JSON, but userId is not a string (accountToTest: SampleAccount)" | 400 | "If o3-psu-identifier header is invalid - the decoded value is valid JSON, but userId is not a string, the API must return a 400 and an error body" |
|
Back to top
GET /accounts/{accountId}/beneficiaries
| Expand |
|---|
|
| Test ID | Dynamic Field | Test Name | Expected Response Code | Test Description |
|---|
BEN_010_001 Ensure that valid accountId returns beneficiaries with Activated/NotActivate status. | AIS_BE001 | accountToTest: AccountIdWithActivatedBeneficiaryType | Happy path - Succeeds if valid accountId in path parameter returns beneficiaries with beneficiaries category Activated in response body (accountToTest: AccountIdWithActivatedBeneficiaryType) | 200 | Valid accountId provided in the path parameter should return a 200 and the accountId must be present in the response with a details of beneficiaries and status Activated | AIS_BE002 | accountToTest: AccountIdWithNotActivatedBeneficiaryType | Happy path - Succeeds if valid accountId in path parameter returns beneficiaries with beneficiaries category NotActivated in response body (accountToTest: AccountIdWithNotActivatedBeneficiaryType) | 200 | Valid accountId provided in the path parameter should return a 200 and the accountId must be present in the response with a details of beneficiaries and status NotActivated | AIS_BE003 | accountToTest: Valid_Beneficiaries_Accounts_List | Happy path - Succeeds with the specified number of accounts in each page and the meta information about the pagination (accountToTest: Valid_Beneficiaries_Accounts_List) | 200 | Returns a 200 status code with the specified number of accounts in each page and the meta information about the pagination | AIS_BE004 | accountToTest: AccountIdWithNoBeneficiaries | Happy path - Succeeds if valid accountId in path parameter returns no beneficiaries (accountToTest: AccountIdWithNoBeneficiaries) | 200 | Valid accountId provided in the path parameter should return a 200 with an empty array if there are no beneficiaries | AIS_BE005 | accountToTest: AccountIdWithActivatedAndNotActivatedBeneficiaryType | Happy path - Succeeds if valid accountId in path parameter returns beneficiaries with beneficiaries category Activated and NotActivated in response body (accountToTest: AccountIdWithActivatedAndNotActivatedBeneficiaryType) | 200 | Valid accountId provided in the path parameter should return a 200 and the accountId must be present in the response with a details of beneficiaries and status Activated and NotActivated | BEN_010_002 Ensure that the API correctly handles missing/invalid accountId path parameter. | AIS_BE006 | | Negative Test - Fails if accountIds path parameter is missing | 400 | "If accountIds path parameter is missing, the API must return a 400 and an error body" | AIS_BE007 | accountToTest: Invalid_Single_AccountId | Negative Test - Fails if accountId format is invalid (accountToTest: Invalid_Single_AccountId) | 400 | "If the accountId format is invalid , the API must return a 400 and an error body" | BEN_010_003 Ensure that the API correctly validates mandatory headers. | AIS_BE008 | accountToTest: NoAccount | Negative Test - Mandatory field validation - Fail if both accountId and o3-psu-identifier are missing (accountToTest: NoAccount) | 400 | The operation must fail with a status of 400 if both the accountId path parameter and the o3-psu-identifier header parameter are missing | AIS_BE009 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-psu-identifier header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-psu-identifier header is missing | AIS_BE010 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-api-uri header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-api-uri header is missing | AIS_BE011 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-api-operation header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-api-operation header is missing | AIS_BE012 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-aspsp-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-aspsp-id header is missing | AIS_BE013 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-ozone-interaction-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-ozone-interaction-id header is missing | AIS_BE014 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-provider-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-provider-id header has an unexpected value | AIS_BE015 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-caller-org-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-caller-org-id header is missing | AIS_BE016 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-caller-client-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-caller-client-id header is missing | AIS_BE017 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-caller-software-statement-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-caller-software-statement-id header is missing | AIS_BE018 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-consent-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-consent-id header is missing | AIS_BE019 | accountToTest: SampleAccount | Negative Test - Fails if o3-psu-identifier is not b64 encoded (accountToTest: SampleAccount) | 400 | "If o3-psu-identifier is not b64 encoded, the API must return a 400 and an error body" | AIS_BE020 | accountToTest: SampleAccount | Negative Test - Fails if o3-psu-identifier does not evaluate to a json structure (accountToTest: SampleAccount) | 400 | "If o3-psu-identifier does not evaluate to a json structure, the API must return a 400 and an error body" | AIS_BE021 | accountToTest: SampleAccount | Negative Test - Fails if o3-psu-identifier does not contain userId (accountToTest: SampleAccount) | 400 | "If o3-psu-identifier does not contain userId, the API must return a 400 and an error body" | AIS_BE022 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-provider-id header is having invalid value (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-provider-id header is having invalid value | AIS_BE023 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-ozone-interaction-id header is having invalid value (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-ozone-interaction-id header is having invalid value | AIS_BE024 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-api-operation header is having invalid value (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-api-operation header is having invalid value | AIS_BE025 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-api-uri header is having invalid value (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-api-uri header is having invalid value | AIS_BE026 | accountToTest: SampleAccount | "Negative Test - Fails if o3-psu-identifier header is invalid - the decoded value is valid JSON, but userId is null, empty or undefined (accountToTest: SampleAccount)" | 400 | "If o3-psu-identifier header is invalid - the decoded value is valid JSON, but userId is null, empty or undefined, the API must return a 400 and an error body" | AIS_BE027 | accountToTest: SampleAccount | "Negative Test - Fails if o3-psu-identifier header is invalid - the decoded value is valid JSON, but userId is not a string (accountToTest: SampleAccount)" | 400 | "If o3-psu-identifier header is invalid - the decoded value is valid JSON, but userId is not a string, the API must return a 400 and an error body" |
|
Back to top
GET /customer
| Expand |
|---|
|
Test Scenario ID | Test ID | Dynamic Field | Test Name | Expected Response Code | Test Description |
|---|
CUS_010_001 Ensure that the API returns the customer details for the user id identified by the o3-psu-identifier header. | AIS_C001 | customerType: Delegate_CustomerType | Happy path - Succeeds if customer for PSU identified by o3-psu-identifier header (customerType: Delegate_CustomerType) | 200 | The API must return the customer for the PSU identified by the o3-psu-identifier header | AIS_C002 | | Happy path - Succeeds when no customer is found | 200 | The API must return a success status code 200 with an empty data object if no customer is found | AIS_C003 | customerType : Retail_CustomerType | Happy path - Succeeds when valid o3-psu-identifier provided in the header which belongs to a retail user (customerType : Retail_CustomerType) | 200 | Returns a 200 status code with details of a retail user in the response as per the schema | AIS_C004 | customerType : Corporate_CustomerType | Happy path - Succeeds when valid o3-psu-identifier provided in the header which belongs to a corporate user (customerType : Corporate_CustomerType) | 200 | Returns a 200 status code with details of a corporate user in the response as per the schema | AIS_C005 | customerType : SME_CustomerType | Happy path - Succeeds when valid o3-psu-identifier provided in the header which belongs to a SME user (customerType : SME_CustomerType) | 200 | Returns a 200 status code with details of a SME user in the response as per the schema | CUS_010_002 Ensure that the API correctly validates mandatory headers. | AIS_C006 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-psu-identifier header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-psu-identifier header is missing | AIS_C007 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-api-uri header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-api-uri header is missing | AIS_C008 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-api-operation header is missing (accountToTest: SampleAccount) | 400 | TThe operation must fail with a status code 400 and error body if the o3-api-operation header is missing | AIS_C009 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-aspsp-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-aspsp-id header is missing | AIS_C010 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-ozone-interaction-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-ozone-interaction-id header is missing | AIS_C011 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-provider-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-provider-id header has an unexpected value | AIS_C012 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-caller-org-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-caller-org-id header is missing | AIS_C013 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-caller-client-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-caller-client-id header is missing | AIS_C014 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-caller-software-statement-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-caller-software-statement-id header is missing | AIS_C015 | accountToTest: SampleAccount | Negative Test - Fails if o3-psu-identifier is not b64 encoded (accountToTest: SampleAccount) | 400 | "If o3-psu-identifier is not b64 encoded, the API must return a 400 and an error body" | AIS_C016 | accountToTest: SampleAccount | Negative Test - Fails if o3-psu-identifier does not evaluate to a json structure (accountToTest: SampleAccount) | 400 | "If o3-psu-identifier does not evaluate to a json structure, the API must return a 400 and an error body" | AIS_C017 | accountToTest: SampleAccount | Negative Test - Fails if o3-psu-identifier does not contain userId (accountToTest: SampleAccount) | 400 | "If o3-psu-identifier does not contain userId, the API must return a 400 and an error body" |
|
Back to top
GET /accounts/{accountId}/customer
| Expand |
|---|
|
Test Scenario ID | Test ID | Dynamic Field | Test Name | Expected Response Code | Test Description |
|---|
CUS_020_001 Ensure that the API provides associated customer details linked to the accountId. | AIS_CC001 | accountToTest: Delegate_CustomerType | Happy path - Succeeds when all headers are valid and provides the associated customer details linked to the accountId provided in the request (accountToTest: Delegate_CustomerType) | 200 | Returns a 200 status code when all headers are valid and provides the associated customer details linked to the accountId provided in the request | CUS_020_002 Ensure that the API correctly handles missing/invalid accountId path parameter. | AIS_CC002 | accountToTest: SampleAccount | Negative Test - Fails if accountId path parameter is missing (accountToTest: SampleAccount) | 400 | "If accountIds path parameter is missing, the API must return a 400 and an error body" | AIS_CC003 | accountToTest: Invalid_Single_AccountId | Negative Test - Fails if accountId format is invalid (accountToTest: Invalid_Single_AccountId) | 400 | "If the accountId format is invalid , the API must return a 400 and an error body" | CUS_020_003 Ensure that the API correctly validates mandatory headers. | AIS_CC004 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-psu-identifier header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-psu-identifier header is missing | AIS_CC005 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-api-uri header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-api-uri header is missing | AIS_CC006 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-api-operation header is missing (accountToTest: SampleAccount) | 400 | TThe operation must fail with a status code 400 and error body if the o3-api-operation header is missing | AIS_CC007 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-aspsp-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-aspsp-id header is missing | AIS_CC008 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-ozone-interaction-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-ozone-interaction-id header is missing | AIS_CC009 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-provider-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-provider-id header has an unexpected value | AIS_CC010 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-caller-org-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-caller-org-id header is missing | AIS_CC011 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-caller-client-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-caller-client-id header is missing | AIS_CC012 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-caller-software-statement-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-caller-software-statement-id header is missing | AIS_CC013 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-consent-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-consent-id header is missing | AIS_CC014 | accountToTest: SampleAccount | "Negative Test - Fails if o3-psu-identifier header is invalid - the decoded value is valid JSON, but userId is null, empty or undefined (accountToTest: SampleAccount)" | 400 | "If o3-psu-identifier header is invalid - the decoded value is valid JSON, but userId is null, empty or undefined, the API must return a 400 and an error body" | AIS_CC015 | accountToTest: SampleAccount | "Negative Test - Fails if o3-psu-identifier header is invalid - the decoded value is valid JSON, but userId is not a string (accountToTest: SampleAccount)" | 400 | "If o3-psu-identifier header is invalid - the decoded value is valid JSON, but userId is not a string, the API must return a 400 and an error body" |
|
Back to top
POST /customers/action/cop-query
| Expand |
|---|
|
| Test ID | Dynamic Field | Test Name | Expected Response Code | Test Description |
|---|
COP_010_001 Ensure that a valid request with schemeName as IBAN for retail user succeeds. | AIS_COPQ001 | accountToTest: confirmation-of-payee-query-retail-user | Happy Path - A valid request with schemeName as IBAN for retail user (accountToTest: confirmation-of-payee-query-retail-user) | 200 | Returns a 200 status code when all headers are valid and provides the associated customer details linked to the IBAN provided in the request for Retail user | AIS_COPQ002 | accountToTest: confirmation-of-payee-query-business-user | Happy Path - A valid request with schemeName as IBAN for business user (accountToTest: confirmation-of-payee-query-business-user) | 200 | Returns a 200 status code when all headers are valid and provides the associated customer details linked to the IBAN provided in the request for business user | AIS_COPQ003 | accountToTest: confirmation-of-payee-query-retail-user | Happy Path - A valid request with schemeName as IBAN for a Retail user and o3-psu-identifier and o3-consent-id are not provided as these fields are not mandatory (accountToTest: confirmation-of-payee-query-retail-user) | 200 | Returns a 200 status code when all headers are valid and o3-psu-identifier and o3-consent-id headers are not provided in the request | AIS_COPQ004 | accountToTest: confirmation-of-payee-invalid-iban | Negative Test - A request with invalid IBAN for a Retail user (accountToTest: confirmation-of-payee-invalid-iban) | 200 | Returns a 200 with empty data array | COP_010_002 Ensure that the API correctly handles the scenario where mandatory fields are missing in the request. The API should return 400 with correct error message | AIS_COPQ005 | accountToTest: missing-firstname-confirmation-of-payee-query-retail-user | Negative Test - A request missing the firstName field for a retail user (accountToTest: missing-firstname-confirmation-of-payee-query-retail-user) | 400 | "Returns a 400 status code when all headers are valid, but the request body is missing the firstName field" | AIS_COPQ006 | accountToTest: missing-lastname-confirmation-of-payee-query-retail-user | Negative Test - A request missing the lastName field for a retail user (accountToTest: missing-lastname-confirmation-of-payee-query-retail-user) | 400 | "Returns a 400 status code when all headers are valid, but the request body is missing the lastName field" | AIS_COPQ007 | accountToTest: missing-businessName-confirmation-of-payee-query-business-user | Negative Test - A request missing the businessName field for a retail user (accountToTest: missing-businessName-confirmation-of-payee-query-business-user) | 400 | "Returns a 400 status code when all headers are valid, but the request body is missing the businessName field" | AIS_COPQ008 | | Negative Test - A request with missing mandatory page and page-size query parameter for a retail user | 400 | Returns a 400 status code when mandatory query parameters page and page-size are missing | COP_010_003 Ensure that the API correctly validates mandatory headers. | AIS_COPQ009 | accountToTest: confirmation-of-payee-query-retail-user | Negative Test - Mandatory header validation - Fail if o3-provider-id header is missing (accountToTest: confirmation-of-payee-query-retail-user) | 400 | Returns a 400 status code when mandatory headers o3-provider-id is missing | AIS_COPQ010 | accountToTest: confirmation-of-payee-query-retail-user | Negative Test - Mandatory header validation - Fail if o3-aspsp-id header is missing (accountToTest: confirmation-of-payee-query-retail-user) | 400 | Returns a 400 status code when mandatory headers o3-aspsp-id is missing | AIS_COPQ011 | accountToTest: confirmation-of-payee-query-retail-user | Negative Test - Mandatory header validation - Fail if o3-caller-org-id header is missing (accountToTest: confirmation-of-payee-query-retail-user) | 400 | Returns a 400 status code when mandatory headers o3-caller-org-id is missing | AIS_COPQ012 | accountToTest: confirmation-of-payee-query-retail-user | Negative Test - Mandatory header validation - Fail if o3-caller-client-id header is missing (accountToTest: confirmation-of-payee-query-retail-user) | 400 | Returns a 400 status code when mandatory headers o3-caller-client-id is missing | AIS_COPQ013 | accountToTest: confirmation-of-payee-query-retail-user | Negative Test - Mandatory header validation - Fail if o3-caller-software-statement-id header is missing (accountToTest: confirmation-of-payee-query-retail-user) | 400 | Returns a 400 status code when mandatory headers o3-caller-software-statement-id is missing | AIS_COPQ014 | accountToTest: confirmation-of-payee-query-retail-user | Negative Test - Mandatory header validation - Fail if o3-api-uri header is missing (accountToTest: confirmation-of-payee-query-retail-user) | 400 | Returns a 400 status code when mandatory headers o3-api-uri is missing | AIS_COPQ015 | accountToTest: confirmation-of-payee-query-retail-user | Negative Test - Mandatory header validation - Fail if o3-api-operation header is missing (accountToTest: confirmation-of-payee-query-retail-user) | 400 | Returns a 400 status code when mandatory headers o3-api-operation is missing | AIS_COPQ016 | accountToTest: confirmation-of-payee-query-retail-user | Negative Test - Mandatory header validation - Fail if o3-caller-interaction-id header is missing (accountToTest: confirmation-of-payee-query-retail-user) | 400 | Returns a 400 status code when mandatory headers o3-caller-interaction-id is missing | AIS_COPQ017 | accountToTest: confirmation-of-payee-query-retail-user | Negative Test - Mandatory header validation - Fail if o3-ozone-interaction-id header is missing (accountToTest: confirmation-of-payee-query-retail-user) | 400 | Returns a 400 status code when mandatory headers o3-ozone-interaction-id is missing |
|
Back to top
GET /accounts/{accountId}/direct-debits
| Expand |
|---|
|
| Test ID | Dynamic Field | Test Name | Expected Response Code | Test Description |
|---|
DD_010_001 Ensure that valid accountId returns direct-debits.Various tests, such as retrieving direct debits with different statuses and frequencies, have been incorporated. | AIS_DD001 | accountToTest: AccountIdWithDirectDebitActiveStatus | Happy path - Succeeds if valid accountId in path parameter returns direct-debits with status Active in response body (accountToTest: AccountIdWithDirectDebitActiveStatus) | 200 | Valid accountId provided in the path parameter should return a 200 and the accountId must be present in the response with a details of direct-debits and status Active | AIS_DD002 | accountToTest: AccountIdWithDirectDebitInActiveStatus | Happy path - Succeeds if valid accountId in path parameter returns direct-debits with status Inactive in response body (accountToTest: AccountIdWithDirectDebitInActiveStatus) | 200 | Valid accountId provided in the path parameter should return a 200 and the accountId must be present in the response with a details of direct-debits and status Inactive | AIS_DD003 | accountToTest: Valid_DirectDebits_Accounts_List | Happy path - Validate the meta information about the pagination (accountToTest: Valid_DirectDebits_Accounts_List) | 200 | Returns a 200 status code with the specified number of accounts in each page and the meta information about the pagination | AIS_DD004 | accountToTest: AccountIdWithDirectDebitAnnualFrequency | Happy path - Succeeds if valid accountId in path parameter returns direct-debits with Annual frequency in response body (accountToTest: AccountIdWithDirectDebitAnnualFrequency) | 200 | Valid accountId provided in the path parameter should return a 200 and the accountId must be present in the response with direct-debits of Annual frequencies | AIS_DD005 | accountToTest: AccountIdWithDirectDebitDailyFrequency | Happy path - Succeeds if valid accountId in path parameter returns direct-debits with Daily frequency in response body (accountToTest: AccountIdWithDirectDebitDailyFrequency) | 200 | Valid accountId provided in the path parameter should return a 200 and the accountId must be present in the response with direct-debits of Daily frequencies | AIS_DD006 | accountToTest: AccountIdWithDirectDebitFortnightlyFrequency | Happy path - Succeeds if valid accountId in path parameter returns direct-debits with Fortnightly frequency in response body (accountToTest: AccountIdWithDirectDebitFortnightlyFrequency) | 200 | Valid accountId provided in the path parameter should return a 200 and the accountId must be present in the response with direct-debits of Fortnightly frequencies | AIS_DD007 | accountToTest: AccountIdWithDirectDebitHalfYearlyFrequency | Happy path - Succeeds if valid accountId in path parameter returns direct-debits with HalfYearly frequency in response body (accountToTest: AccountIdWithDirectDebitHalfYearlyFrequency) | 200 | Valid accountId provided in the path parameter should return a 200 and the accountId must be present in the response with direct-debits of HalfYearly frequencies | AIS_DD008 | accountToTest: AccountIdWithDirectDebitMonthlyFrequency | Happy path - Succeeds if valid accountId in path parameter returns direct-debits with Monthly frequency in response body (accountToTest: AccountIdWithDirectDebitMonthlyFrequency) | 200 | Valid accountId provided in the path parameter should return a 200 and the accountId must be present in the response with direct-debits of Monthly frequencies | AIS_DD009 | accountToTest: AccountIdWithEmptyDirectDebits | Happy path - Succeeds if valid accountId provided in the path parameter which has a empty direct debits (accountToTest: AccountIdWithEmptyDirectDebits) | 200 | Valid accountId provided in the path parameter should return a 200 with an empty array if there are no direct-debits | DD_010_002 Ensure that the API correctly handles missing/invalid accountId path parameter. | AIS_DD010 | accountToTest: Missing_AccountId | Negative Test - Fails if accountToTest path parameter is missing (accountToTest: Missing_AccountId) | 400 | "If accountToTest path parameter is missing, the API must return a 400 and an error body" | AIS_DD011 | accountToTest: Invalid_Single_AccountId | Negative Test - Fails if accountId format is invalid (accountToTest: Invalid_Single_AccountId) | 400 | "If the accountId format is invalid , the API must return a 400 and an error body" | DD_010_003 Ensure that the API correctly validates mandatory headers. | AIS_DD012 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-psu-identifier header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-psu-identifier header is missing | AIS_DD013 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-api-uri header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-api-uri header is missing | AIS_DD014 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-api-operation header is missing (accountToTest: SampleAccount) | 400 | TThe operation must fail with a status code 400 and error body if the o3-api-operation header is missing | AIS_DD015 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-aspsp-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-aspsp-id header is missing | AIS_DD016 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-ozone-interaction-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-ozone-interaction-id header is missing | AIS_DD017 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-provider-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-provider-id header has an unexpected value | AIS_DD018 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-caller-org-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-caller-org-id header is missing | AIS_DD019 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-caller-client-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-caller-client-id header is missing | AIS_DD020 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-caller-software-statement-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-caller-software-statement-id header is missing | AIS_DD021 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-consent-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-consent-id header is missing | AIS_DD022 | accountToTest: SampleAccount | Negative Test - Fails if o3-aspsp-id has an invalid value (accountToTest: SampleAccount) | 400 | "If o3-aspsp-id has an invalid value, the API must return a 400 and an error body" | AIS_DD023 | accountToTest: SampleAccount | Negative Test - Fails if o3-psu-identifier is not b64 encoded (accountToTest: SampleAccount) | 400 | "If o3-psu-identifier is not b64 encoded, the API must return a 400 and an error body" | AIS_DD024 | accountToTest: SampleAccount | Negative Test - Fails if o3-psu-identifier does not evaluate to a json structure (accountToTest: SampleAccount) | 400 | "If o3-psu-identifier does not evaluate to a json structure, the API must return a 400 and an error body" | AIS_DD025 | accountToTest: SampleAccount | Negative Test - Fails if o3-psu-identifier does not contain userId (accountToTest: SampleAccount) | 400 | "If o3-psu-identifier does not contain userId, the API must return a 400 and an error body" | AIS_DD026 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-consent-id header is having invalid value (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-consent-id header is having invalid value | AIS_DD027 | accountToTest: SampleAccount | "Negative Test - Fails if o3-psu-identifier header is invalid - the decoded value is valid JSON, but userId is null, empty or undefined (accountToTest: SampleAccount)" | 400 | "If o3-psu-identifier header is invalid - the decoded value is valid JSON, but userId is null, empty or undefined, the API must return a 400 and an error body" | AIS_DD028 | accountToTest: SampleAccount | "Negative Test - Fails if o3-psu-identifier header is invalid - the decoded value is valid JSON, but userId is not a string (accountToTest: SampleAccount)" | 400 | "If o3-psu-identifier header is invalid - the decoded value is valid JSON, but userId is not a string, the API must return a 400 and an error body" |
|
Back to top
GET /accounts/{accountId}/products
| Expand |
|---|
|
Test Scenario ID | Test ID | Dynamic Field | Test Name | Expected Response Code | Test Description |
|---|
PRD_010_001 Ensure that valid accountId returns product details. | AIS_P001 | accountToTest: Products_SampleAccount | Happy path - Succeeds if valid accountId provided in the path parameter which has products (accountToTest: Products_SampleAccount) | 200 | The operation must return a status code 200 and the products of the valid accountId | AIS_P002 | accountToTest: AccountIdWithEmptyProducts | Happy path - Succeeds valid accountId provided in the path parameter which has an empty products (accountToTest: AccountIdWithEmptyProducts) | 200 | The operation must return a status code 200 and an empty array if the accountId has no products | PRD_010_002 Ensure that the API correctly handles missing/invalid accountId path parameter. | AIS_P003 | accountToTest: NoAccount | Negative Test - Fails if accountIds path parameter is missing (accountToTest: NoAccount) | 400 | "If accountIds path parameter is missing, the API must return a 400 and an error body" | AIS_P004 | accountToTest: Invalid_Single_AccountId | Negative Test - Fails if accountId format is invalid (accountToTest: Invalid_Single_AccountId) (accountToTest: Invalid_Single_AccountId) | 400 | "If the accountId format is invalid , the API must return a 400 and an error body" | PRD_010_003 Ensure that the API correctly validates mandatory headers. | AIS_P005 | accountToTest: NoAccount | Negative Test - Mandatory field validation - Fail if both accountId and o3-psu-identifier are missing (accountToTest: NoAccount) | 400 | The operation must fail with a status of 400 if both the accountId path parameter and the o3-psu-identifier header parameter are missing | AIS_P006 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-psu-identifier header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-psu-identifier header is missing | AIS_P007 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-api-uri header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-api-uri header is missing | AIS_P008 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-api-operation header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-api-operation header is missing | AIS_P009 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-aspsp-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-aspsp-id header is missing | AIS_P010 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-ozone-interaction-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-ozone-interaction-id header is missing | AIS_P011 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-provider-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-provider-id header has an unexpected value | AIS_P012 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-caller-org-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-caller-org-id header is missing | AIS_P013 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-caller-client-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-caller-client-id header is missing | AIS_P014 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-caller-software-statement-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-caller-software-statement-id header is missing | AIS_P015 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-consent-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-consent-id header is missing | AIS_P016 | accountToTest: SampleAccount | Negative Test - Fails if o3-aspsp-id has an invalid value (accountToTest: SampleAccount) | 400 | "If o3-aspsp-id has an invalid value, the API must return a 400 and an error body" | AIS_P017 | accountToTest: SampleAccount | Negative Test - Fails if o3-psu-identifier is not b64 encoded (accountToTest: SampleAccount) | 400 | "If o3-psu-identifier is not b64 encoded, the API must return a 400 and an error body" | AIS_P018 | accountToTest: SampleAccount | Negative Test - Fails if o3-psu-identifier does not evaluate to a json structure (accountToTest: SampleAccount) | 400 | "If o3-psu-identifier does not evaluate to a json structure, the API must return a 400 and an error body" | AIS_P019 | accountToTest: SampleAccount | Negative Test - Fails if o3-psu-identifier does not contain userId (accountToTest: SampleAccount) | 400 | "If o3-psu-identifier does not contain userId, the API must return a 400 and an error body" | AIS_P020 | accountToTest: SampleAccount | "Negative Test - Fails if o3-psu-identifier header is invalid - the decoded value is valid JSON, but userId is null, empty or undefined (accountToTest: SampleAccount)" | 400 | "If o3-psu-identifier header is invalid - the decoded value is valid JSON, but userId is null, empty or undefined, the API must return a 400 and an error body" | AIS_P021 | accountToTest: SampleAccount | "Negative Test - Fails if o3-psu-identifier header is invalid - the decoded value is valid JSON, but userId is not a string (accountToTest: SampleAccount)" | 400 | "If o3-psu-identifier header is invalid - the decoded value is valid JSON, but userId is not a string, the API must return a 400 and an error body" |
|
Back to top
GET /accounts/{accountId}/standing-orders
| Expand |
|---|
|
Test Scenario ID | Test ID | Dynamic Field | Test Name | Expected Response Code | Test Description |
|---|
STO_010_001 Ensure that valid accountId returns standing-orders with active/inactive status and various types | AIS_SO001 | accountToTest: Active_StandingOrdersStatusCode | Happy path - Succeeds if valid accountId in path parameter returns standing-orders with Active status in response body (accountToTest: Active_StandingOrdersStatusCode) | 200 | Valid accountId provided in the path parameter should return a 200 and the accountId must be present in the response with a details of standing-orders having status Active | AIS_SO002 | accountToTest: Inactive_StandingOrdersStatusCode | Happy path - Succeeds if valid accountId in path parameter returns standing-orders with Inactive status in response body (accountToTest: Inactive_StandingOrdersStatusCode) | 200 | Valid accountId provided in the path parameter should return a 200 and the accountId must be present in the response with a details of standing-orders having status Inactive | AIS_SO003 | accountToTest: Valid_StandingOrders_Accounts_List | Happy path - Validate the meta information about pagination (accountToTest: Valid_StandingOrders_Accounts_List) | 200 | Returns a 200 status code with the specified number of accounts in each page and the meta information about the pagination | AIS_SO004 | accountToTest: BetweenMyAccounts_StandingOrder | Happy path - Succeeds if valid accountId in path parameter returns standing-orders of BetweenMyAccounts type (accountToTest: BetweenMyAccounts_StandingOrder) | 200 | Valid accountId provided in the path parameter should return a 200 and the standing-orders must have the correct standing-orders type BetweenMyAccounts in the response body | AIS_SO005 | accountToTest: SameBankTransfer_StandingOrder | Happy path - Succeeds if valid accountId in path parameter returns standing-orders of SameBankTransfer type (accountToTest: SameBankTransfer_StandingOrder) | 200 | Valid accountId provided in the path parameter should return a 200 and the standing-orders must have the correct standing-orders type SameBankTransfer in the response body | AIS_SO006 | accountToTest: LocalBankTransfer_StandingOrder | Happy path - Succeeds if valid accountId in path parameter returns standing-orders of LocalBankTransfer type (accountToTest: LocalBankTransfer_StandingOrder) | 200 | Valid accountId provided in the path parameter should return a 200 and the standing-orders must have the correct standing-orders type LocalBankTransfer in the response body | AIS_SO007 | accountToTest: AccountIdWithEmptyStandingOrders | Happy path - Succeeds if valid accountId in path parameter returns no standing-orders (accountToTest: AccountIdWithEmptyStandingOrders) | 200 | Valid accountId provided in the path parameter should return a 200 with an empty array if there are no standing-orders | STO_010_002 Ensure that the API correctly handles missing/invalid accountId path parameter. | AIS_SO008 | | Negative Test - Fails if accountIds path parameter is missing | 400 | "If accountIds path parameter is missing, the API must return a 400 and an error body" | AIS_SO009 | accountToTest: Invalid_Single_AccountId | Negative Test - Fails if accountId format is invalid (accountToTest: Invalid_Single_AccountId) | 400 | "If the accountId format is invalid , the API must return a 400 and an error body" | STO_010_003 Ensure that the API correctly validates mandatory headers. | AIS_SO010 | accountToTest: NoAccount | Negative Test - Mandatory field validation - Fail if both accountId and o3-psu-identifier are missing (accountToTest: NoAccount) | 400 | The operation must fail with a status of 400 if both the accountId path parameter and the o3-psu-identifier header parameter are missing | AIS_SO011 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-psu-identifier header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-psu-identifier header is missing | AIS_SO012 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-api-uri header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-api-uri header is missing | AIS_SO013 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-api-operation header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-api-operation header is missing | AIS_SO014 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-aspsp-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-aspsp-id header is missing | AIS_SO015 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-ozone-interaction-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-ozone-interaction-id header is missing | AIS_SO016 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-provider-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-provider-id header has an unexpected value | AIS_SO017 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-caller-org-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-caller-org-id header is missing | AIS_SO018 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-caller-client-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-caller-client-id header is missing | AIS_SO019 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-caller-software-statement-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-caller-software-statement-id header is missing | AIS_SO020 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-consent-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-consent-id header is missing | AIS_SO021 | accountToTest: SampleAccount | Negative Test - Fails if o3-psu-identifier is not b64 encoded (accountToTest: SampleAccount) | 400 | "If o3-psu-identifier is not b64 encoded, the API must return a 400 and an error body" | AIS_SO022 | accountToTest: SampleAccount | Negative Test - Fails if o3-psu-identifier does not evaluate to a json structure (accountToTest: SampleAccount) | 400 | "If o3-psu-identifier does not evaluate to a json structure, the API must return a 400 and an error body" | AIS_SO023 | accountToTest: SampleAccount | Negative Test - Fails if o3-psu-identifier does not contain userId (accountToTest: SampleAccount) | 400 | "If o3-psu-identifier does not contain userId, the API must return a 400 and an error body" | AIS_SO024 | accountToTest: SampleAccount | "Negative Test - Fails if o3-psu-identifier header is invalid - the decoded value is valid JSON, but userId is null, empty or undefined (accountToTest: SampleAccount)" | 400 | "If o3-psu-identifier header is invalid - the decoded value is valid JSON, but userId is null, empty or undefined, the API must return a 400 and an error body" | AIS_SO025 | (accountToTest:: SampleAccount | "Negative Test - Fails if o3-psu-identifier header is invalid - the decoded value is valid JSON, but userId is not a string ((accountToTest:: SampleAccount)" | 400 | "If o3-psu-identifier header is invalid - the decoded value is valid JSON, but userId is not a string, the API must return a 400 and an error body" |
|
Back to top
GET /accounts/{accountId}/transactions
| Expand |
|---|
|
Test Scenario ID | Test ID | Dynamic Field | Test Name | Expected Response Code | Test Description |
|---|
TXN_010_001 Ensure that valid accountId returns transaction details. | AIS_T001 | accountToTest: Transactions_SampleAccount | Happy Path - Succeeds if valid accountId in path parameter returns transactions (accountToTest: Transactions_SampleAccount) | 200 | Valid accountId provided in the path parameter should return a 200 and the accountId must be present in the response with a list of transactions | AIS_T002 | accountToTest: AccountIdWithEmptyTransactions | Happy path - Succeeds if valid accountId in path parameter returns no transactions (accountToTest: AccountIdWithEmptyTransactions) | 200 | Valid accountId provided in the path parameter should return a 200 with an empty array if there are no transactions | AIS_T003 | accountToTest: Valid_Transactions_Accounts_List | Happy path - Succeeds with the specified number of accounts in each page and the meta information about the pagination (accountToTest: Valid_Transactions_Accounts_List) | 200 | Returns a 200 status code with the specified number of accounts in each page and the meta information about the pagination | AIS_T004 | accountToTest: Transactions_SampleAccount | Happy Path - Filter transactions based on fromBookingDateTime query param (accountToTest: Transactions_SampleAccount) | 200 | Returns a 200 with list of transactions from fromBookingDateTime until latest available transaction | AIS_T005 | accountToTest: Transactions_SampleAccount | Happy Path - Filter transactions based on toBookingDateTime query param (accountToTest: Transactions_SampleAccount) | 200 | Returns a 200 with list of transactions from the earliest available transaction till toBookingDateTime | AIS_T006 | accountToTest: Transactions_SampleAccount | Happy Path - Filter transactions based on fromBookingDateTime and toBookingDateTime query params (accountToTest: Transactions_SampleAccount) | 200 | Returns a 200 with list of transactions within fromBookingDateTime and toBookingDateTime query params | TXN_010_002 Ensure API returns error from date query params are not valid | AIS_T007 | accountToTest: SampleAccount | Negative Test - Fails if toBookingDateTime is before fromBookingDateTime (accountToTest: SampleAccount) | 400 | "If toBookingDateTime is before fromBookingDateTime, the API must return a 400 and an error body" | TXN_010_003 Ensure that the API correctly handles missing/invalid accountId path parameter. | AIS_T008 | accountToTest: SampleAccount | Negative Test - Fails if accountIds path parameter is missing (accountToTest: SampleAccount) | 400 | "If accountIds path parameter is missing, the API must return a 400 and an error body" | AIS_T009 | accountToTest: Invalid_Single_AccountId | Negative Test - Fails if accountId format is invalid (accountToTest: Invalid_Single_AccountId) | 400 | "If the accountId format is invalid , the API must return a 400 and an error body" | TXN_010_004 Ensure that the API correctly validates mandatory headers. | AIS_T010 | accountToTest: NoAccount | Negative Test - Mandatory field validation - Fail if both accountId and o3-psu-identifier are missing (accountToTest: NoAccount) | 400 | The operation must fail with a status of 400 if both the accountId path parameter and the o3-psu-identifier header parameter are missing | AIS_T011 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-psu-identifier header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-psu-identifier header is missing | AIS_T012 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-api-uri header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-api-uri header is missing | AIS_T013 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-api-operation header is missing (accountToTest: SampleAccount) | 400 | TThe operation must fail with a status code 400 and error body if the o3-api-operation header is missing | AIS_T014 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-aspsp-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-aspsp-id header is missing | AIS_T015 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-ozone-interaction-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-ozone-interaction-id header is missing | AIS_T016 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-provider-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-provider-id header has an unexpected value | AIS_T017 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-caller-org-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-caller-org-id header is missing | AIS_T018 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-caller-client-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-caller-client-id header is missing | AIS_T019 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-caller-software-statement-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-caller-software-statement-id header is missing | AIS_T020 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-consent-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-consent-id header is missing | AIS_T021 | accountToTest: SampleAccount | Negative Test - Fails if o3-psu-identifier is not b64 encoded (accountToTest: SampleAccount) | 400 | "If o3-psu-identifier is not b64 encoded, the API must return a 400 and an error body" | AIS_T022 | accountToTest: SampleAccount | Negative Test - Fails if o3-psu-identifier does not evaluate to a json structure (accountToTest: SampleAccount) | 400 | "If o3-psu-identifier does not evaluate to a json structure, the API must return a 400 and an error body" | AIS_T023 | accountToTest: SampleAccount | Negative Test - Fails if o3-psu-identifier does not contain userId (accountToTest: SampleAccount) | 400 | "If o3-psu-identifier does not contain userId, the API must return a 400 and an error body" | AIS_T024 | accountToTest: SampleAccount | "Negative Test - Fails if o3-psu-identifier header is invalid - the decoded value is valid JSON, but userId is null, empty or undefined (accountToTest: SampleAccount)" | 400 | "If o3-psu-identifier header is invalid - the decoded value is valid JSON, but userId is null, empty or undefined, the API must return a 400 and an error body" | AIS_T025 | accountToTest: SampleAccount | "Negative Test - Fails if o3-psu-identifier header is invalid - the decoded value is valid JSON, but userId is not a string (accountToTest: SampleAccount)" | 400 | "If o3-psu-identifier header is invalid - the decoded value is valid JSON, but userId is not a string, the API must return a 400 and an error body" |
|
Back to top
GET /accounts/{accountId}/scheduled-payments
| Expand |
|---|
|
| Test ID | Dynamic Field | Test Name | Expected Response Code | Test Description |
|---|
SCP_010_001 Ensure that valid accountId returns scheduled-payments. Multiple tests are included to cover various types and handle the scenario to run empty response when no SPs are found. | AIS_SP001 | accountToTest: Arrival_ScheduledPaymentType | Happy path - Succeeds if valid accountId in path parameter returns scheduled-payments with scheduled type Arrival in response body (accountToTest: Arrival_ScheduledPaymentType) | 200 | Valid accountId provided in the path parameter should return a 200 and the accountId must be present in the response with a details of scheduled-payments having scheduled type is Arrival | AIS_SP002 | accountToTest: Execution_ScheduledPaymentType | Happy path - Succeeds if valid accountId in path parameter returns scheduled-payments with scheduled type Execution in response body (accountToTest: Execution_ScheduledPaymentType) | 200 | Valid accountId provided in the path parameter should return a 200 and the accountId must be present in the response with a details of scheduled-payments having scheduled type is Execution | AIS_SP003 | accountToTest: Valid_ScheduledPayments_Accounts_List | Happy path - Validate the meta information about the pagination (accountToTest: Valid_ScheduledPayments_Accounts_List) | 200 | Returns a 200 status code with the specified number of accounts in each page and the meta information about the pagination | AIS_SP004 | accountToTest: IBAN_Identifications_ScheduledPayment | Happy path - Succeeds if valid accountId in path parameter returns scheduled-payments with correct creditor account identification IBAN (accountToTest: IBAN_Identifications_ScheduledPayment) | 200 | Valid accountId provided in the path parameter should return a 200 and the scheduled-payments must have the correct creditor account identification IBAN | AIS_SP005 | accountToTest: AccountNumber_Identifications_ScheduledPayment | Happy path - Succeeds if valid accountId in path parameter returns scheduled-payments with correct creditor account identification AccountNumber (accountToTest: AccountNumber_Identifications_ScheduledPayment) | 200 | Valid accountId provided in the path parameter should return a 200 and the scheduled-payments must have the correct creditor account identification AccountNumber | AIS_SP006 | accountToTest: AccountIdWithEmptyScheduledPayments | Happy path - Succeeds if valid accountId in path parameter returns no scheduled-payments (accountToTest: AccountIdWithEmptyScheduledPayments) | 200 | Valid accountId provided in the path parameter should return a 200 with an empty array if there are no scheduled-payments | SCP_010_002 Ensure that the API correctly handles missing/invalid accountId path parameter. | AIS_SP007 | accountToTest: NoAccount | Negative Test - Fails if accountIds path parameter is missing (accountToTest: NoAccount) | 400 | "If accountIds path parameter is missing, the API must return a 400 and an error body" | AIS_SP008 | accountToTest: Invalid_Single_AccountId | Negative Test - Fails if accountId format is invalid (accountToTest: Invalid_Single_AccountId) | 400 | "If the accountId format is invalid , the API must return a 400 and an error body" | SCP_010_003 Ensure that the API correctly validates mandatory headers. | AIS_SP009 | accountToTest: NoAccount | Negative Test - Mandatory field validation - Fail if both accountId and o3-psu-identifier are missing (accountToTest: NoAccount) | 400 | The operation must fail with a status of 400 if both the accountId path parameter and the o3-psu-identifier header parameter are missing | AIS_SP010 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-psu-identifier header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-psu-identifier header is missing | AIS_SP011 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-api-uri header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-api-uri header is missing | AIS_SP012 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-api-operation header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-api-operation header is missing | AIS_SP013 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-aspsp-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-aspsp-id header is missing | AIS_SP014 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-ozone-interaction-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-ozone-interaction-id header is missing | AIS_SP015 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-provider-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-provider-id header has an unexpected value | AIS_SP016 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-caller-org-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-caller-org-id header is missing | AIS_SP017 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-caller-client-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-caller-client-id header is missing | AIS_SP018 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-caller-software-statement-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-caller-software-statement-id header is missing | AIS_SP019 | accountToTest: SampleAccount | Negative Test - Mandatory header validation - Fail if o3-consent-id header is missing (accountToTest: SampleAccount) | 400 | The operation must fail with a status code 400 and error body if the o3-consent-id header is missing | AIS_SP020 | accountToTest: SampleAccount | Negative Test - Fails if o3-psu-identifier is not b64 encoded (accountToTest: SampleAccount) | 400 | "If o3-psu-identifier is not b64 encoded, the API must return a 400 and an error body" | AIS_SP021 | accountToTest: SampleAccount | Negative Test - Fails if o3-psu-identifier does not evaluate to a json structure (accountToTest: SampleAccount) | 400 | "If o3-psu-identifier does not evaluate to a json structure, the API must return a 400 and an error body" | AIS_SP022 | accountToTest: SampleAccount | Negative Test - Fails if o3-psu-identifier does not contain userId (accountToTest: SampleAccount) | 400 | "If o3-psu-identifier does not contain userId, the API must return a 400 and an error body" | AIS_SP023 | accountToTest: SampleAccount | "Negative Test - Fails if o3-psu-identifier header is invalid - the decoded value is valid JSON, but userId is null, empty or undefined (accountToTest: SampleAccount)" | 400 | "If o3-psu-identifier header is invalid - the decoded value is valid JSON, but userId is null, empty or undefined, the API must return a 400 and an error body" | AIS_SP024 | accountToTest: SampleAccount | "Negative Test - Fails if o3-psu-identifier header is invalid - the decoded value is valid JSON, but userId is not a string (accountToTest: SampleAccount)" | 400 | "If o3-psu-identifier header is invalid - the decoded value is valid JSON, but userId is not a string, the API must return a 400 and an error body" |
|
Back to top
Bank Service Initiation
SingleImmediatePayments
| Expand |
|---|
|
Test Scenario ID | Test Case ID | Field to be updated in the config.yaml | Test Name | Expected Response Code | Test Description |
|---|
SIP_010_001 Ensure future dated payment is successfully processed and inquired for a retail user | PIS_SIP001 | paymentToTest : single-instant-payment-for-retail | POST : Happy Path - Single instant payments (paymentToTest : single-instant-payment-for-retail) | 201 | The operartion must succeed with a status code 201 if the payment is successfully created | PIS_SIP002 | paymentToTest : single-instant-payment-for-retail | GET : Happy Path - Succeeds if valid paymentId in path parameter returns payments (paymentToTest : single-instant-payment-for-retail) | 200 | Valid paymentId provided in the path parameter should return a 200 and the paymentId must be present in the response | SIP_010_002 Ensure future dated payment is successfully processed and inquired for a SME user | PIS_SIP003 | paymentToTest : single-instant-payment-for-SME | POST : Happy Path - Single instant payments (paymentToTest : single-instant-payment-for-SME) | 201 | The operartion must succeed with a status code 201 if the payment is successfully created | PIS_SIP004 | paymentToTest : single-instant-payment-for-SME | GET : Succeeds if valid paymentId in path parameter returns payments (paymentToTest : single-instant-payment-for-SME) | 200 | Valid paymentId provided in the path parameter should return a 200 and the paymentId must be present in the response | SIP_010_003 Ensure future dated payment is successfully processed and inquired for a Corporate user | PIS_SIP005 | paymentToTest : single-instant-payment-for-corporate | POST : Happy Path - Single instant payments (paymentToTest : single-instant-payment-for-corporate) | 201 | The operartion must succeed with a status code 201 if the payment is successfully created | PIS_SIP006 | paymentToTest : single-instant-payment-for-corporate | GET : Happy Path - Succeeds if valid paymentId in path parameter returns payments (paymentToTest : single-instant-payment-for-corporate) | 200 | Valid paymentId provided in the path parameter should return a 200 and the paymentId must be present in the response | SIP_010_004 Ensure GET /payments endpoint supports inquiring payments of different statuses | PIS_SIP007 | paymentToTest : Sample_SIP_Valid_PaymentIds_AcceptedSettlementCompleted | GET : Happy Path - Succeeds if valid paymentId in path parameter returns payments with status AcceptedSettlementCompleted (paymentToTest : Sample_SIP_Valid_PaymentIds_AcceptedSettlementCompleted) | 200 | Valid paymentId provided in the path parameter should returns a 200 with status 'AcceptedSettlementCompleted' in response | PIS_SIP008 | paymentToTest : Sample_SIP_Valid_PaymentIds_AcceptedCreditSettlementCompleted | GET : Happy Path - Succeeds if valid paymentId in path parameter returns payments with status AcceptedCreditSettlementCompleted (paymentToTest : Sample_SIP_Valid_PaymentIds_AcceptedCreditSettlementCompleted) | 200 | Valid paymentId provided in the path parameter should returns a 200 with status 'AcceptedSettlementCompleted' in response | PIS_SIP009 | paymentToTest : Sample_SIP_Valid_PaymentIds_AcceptedWithoutPosting | GET : Happy Path - Succeeds if valid paymentId in path parameter returns payments with status AcceptedWithoutPosting (paymentToTest : Sample_SIP_Valid_PaymentIds_AcceptedWithoutPosting) | 200 | Valid paymentId provided in the path parameter should returns a 200 with status 'AcceptedSettlementCompleted' in response | PIS_SIP010 | paymentToTest : Sample_SIP_Valid_PaymentIds_Rejected | GET : Happy Path - Succeeds if valid paymentId in path parameter returns payments with status Rejected (paymentToTest : Sample_SIP_Valid_PaymentIds_Rejected) | 200 | Valid paymentId provided in the path parameter should returns a 200 with status 'AcceptedSettlementCompleted' in response | SIP_010_005 Ensure Post /payments endpoint returns error when mandatory fields are missing. | PIS_SIP011 | paymentToTest : MissingBodyField_paymentType | POST : Negative Test - Fail if payment type field in the request body is missing (paymentToTest : MissingBodyField_paymentType) | 400 | The operation must fail with a status code 400 if the payment type field is missing in the request body | PIS_SIP012 | paymentToTest : MissingBodyField_PersonalIdentifiableInformation | POST : Negative Test - Fail if Personal Identifiable Information field in the request body is missing (paymentToTest : MissingBodyField_PersonalIdentifiableInformation) | 400 | The operation must fail with a status code 400 if the Personal Identifiable Information field is missing in the request body | PIS_SIP013 | paymentToTest : MissingBodyField_PaymentPurposeCode | POST : Negative Test - Fail if Payment Purpose Code field in the request body is missing (paymentToTest : MissingBodyField_PaymentPurposeCode) | 400 | The operation must fail with a status code 400 if the Payment Purpose Code field is missing in the request body | PIS_SIP014 | paymentToTest : MissingBodyField_ConsentId | POST : Negative Test - Fail if consent id field in the request body is missing (paymentToTest : MissingBodyField_ConsentId) | 400 | The operation must fail with a status code 400 if the consent id field is missing in the request body | SIP_010_006 Ensure payment is rejected when amount is greater than available funds | PIS_SIP015 | accountToTest: AccountIdWithValidBalanceType | Happy path - Succeeds if valid accountId in path parameter returns balances (accountToTest: AccountIdWithValidBalanceType) | 200 | Valid accountId provided in the path parameter should return a 200 and the accountId must be present in the response with balance details | PIS_SIP016 | paymentToTest: single-instant-payment-for-retail | POST /payment : Negative Test : Verify that a payment cannot be processed via the POST /payment endpoint if the amount exceeds the available balance (paymentToTest: single-instant-payment-for-retail) | 400 | The operation must fail with a status code 400 if the payment amount exceeds the available balance. |
|
Back to top
FutureDatedPayments
| Expand |
|---|
|
Test Scenario ID | Test Case ID | Field to be updated in the config.yaml | Test Name | Expected Response Code | Test Description |
|---|
FDP_010_001 Ensure future dated payment is successfully processed and inquired for a retail user | PIS_FDP001 | paymentToTest: future-dated-payment-for-retail | POST : Happy Path - Future dated payments for retail user(paymentToTest: future-dated-payment-for-retail) | 201 | The operartion must succeed with a status code 201 if the payment is successfully created | PIS_FDP002 | paymentToTest: future-dated-payment-for-retail | GET : Happy Path - Succeeds if valid paymentId in path parameter returns payments (paymentToTest: future-dated-payment-for-retail) | 200 | Valid paymentId provided in the path parameter should return a 200 and the paymentId must be present in the response | FDP_010_002 Ensure future dated payment is successfully processed and inquired for a SME user | PIS_FDP003 | paymentToTest : future-dated-payment-for-SME | POST : Happy Path - Future Dated payments (paymentToTest : future-dated-payment-for-SME) | 201 | The operartion must succeed with a status code 201 if the payment is successfully created | PIS_FDP004 | paymentToTest : future-dated-payment-for-SME | GET : Happy Path - Succeeds if valid paymentId in path parameter returns payments (paymentToTest : future-dated-payment-for-SME) | 200 | Valid paymentId provided in the path parameter should return a 200 and the paymentId must be present in the response | FDP_010_003 Ensure future dated payment is successfully processed and inquired for a corporate user | PIS_FDP005 | paymentToTest: future-dated-payment-for-corporate | POST : Happy Path - Future dated payments for coporate user (paymentToTest: future-dated-payment-for-corporate) | 201 | The operartion must succeed with a status code 201 if the payment is successfully created | PIS_FDP006 | paymentToTest: future-dated-payment-for-corporate | GET : Happy Path - Succeeds if valid paymentId in path parameter returns payments (paymentToTest: future-dated-payment-for-corporate) | 200 | Valid paymentId provided in the path parameter should return a 200 and the paymentId must be present in the response | FDP_010_004 Ensure GET /payments endpoint supports inquiring payments of different statuses | PIS_FDP007 | paymentToTest : Sample_FDP_Valid_PaymentIds_AcceptedSettlementCompleted | GET : Happy Path - Succeeds if valid paymentId in path parameter returns payments with status AcceptedSettlementCompleted (paymentToTest : Sample_FDP_Valid_PaymentIds_AcceptedSettlementCompleted) | 201 | Valid paymentId provided in the path parameter should returns a 200 with status 'AcceptedSettlementCompleted' in response | PIS_FDP008 | paymentToTest : Sample_FDP_Valid_PaymentIds_AcceptedCreditSettlementCompleted | GET : Happy Path - Succeeds if valid paymentId in path parameter returns payments with status AcceptedCreditSettlementCompleted (paymentToTest : Sample_FDP_Valid_PaymentIds_AcceptedCreditSettlementCompleted) | 200 | Valid paymentId provided in the path parameter should returns a 200 with status 'AcceptedSettlementCompleted' in response | PIS_FDP009 | paymentToTest : Sample_FDP_Valid_PaymentIds_AcceptedWithoutPosting | GET : Happy Path - Succeeds if valid paymentId in path parameter returns payments with status AcceptedWithoutPosting (paymentToTest : Sample_FDP_Valid_PaymentIds_AcceptedWithoutPosting) | 201 | Valid paymentId provided in the path parameter should returns a 200 with status 'AcceptedSettlementCompleted' in response | PIS_FDP010 | paymentToTest : Sample_FDP_Valid_PaymentIds_Rejected | GET : Happy Path - Succeeds if valid paymentId in path parameter returns payments with status Rejected (paymentToTest : Sample_FDP_Valid_PaymentIds_Rejected) | 200 | Valid paymentId provided in the path parameter should returns a 200 with status 'AcceptedSettlementCompleted' in response |
|
Back to top
MultiPayments-FixedDefinedSchedule
| Expand |
|---|
|
Test Scenario ID | Test Case ID | Field to be updated in the config.yaml | Test Name | Expected Response Code | Test Description |
|---|
MP_010_001 Ensure that FixedDefinedSchedule requests are successfully handled by consent event & action / payments endpoints | Before_FDS001 | paymentToTest: event-AwaitingAuthorization-for-fixed-defined-schedule-retail-user | POST /event/post: Happy Path - Verify all mandatory request body fields with consent status AwaitingAuthorization for Fixed Defined Schedule (paymentToTest: event-AwaitingAuthorization-for-fixed-defined-schedule-retail-user) | 200 | Ozone will be sending an consent in an AwaitingAuthorization state to the LFI after the consent/event/post endpoint is hit. | Before_FDS002 | paymentToTest: event-Authorized-for-fixed-defined-schedule-retail-user | POST event/patch : Happy Path : Verify the successful creation of an event when the consentStatus is set to Authorized for a predefined Fixed Defined Schedule (paymentToTest: event-Authorized-for-fixed-defined-schedule-retail-user) | 200 | Ozone will be sending an consent in an Authorized state to the LFI after the consent/event/patch is hit. | PIS_FDS003 | paymentToTest: fixed-defined-schedule-for-retail-user | POST /payment: Happy Path - Verify all mandatory and optional request body fields for Fixed Defined Schedule (paymentToTest: fixed-defined-schedule-for-retail-user) | 201 | The operartion must succeed with a status code 201 if the payment is successfully created | After_FDS004 | paymentToTest: event-Consumed-for-fixed-defined-schedule-retail-user | POST event/patch : Happy Path : Verify all mandatory request body fields with consent status Consumed for Fixed Defined Schedule (paymentToTest: event-Consumed-for-fixed-defined-schedule-retail-user) | 204 | Ozone will be sending an consent in a Consumed state to the LFI after the consent/event/patch is hit. | PIS_FDS005 | paymentToTest: fixed-defined-schedule-for-retail-user | GET /payment: Happy Path - Verify that a valid paymentId in the path parameter returns the correct payment for Fixed Defined Schedule (paymentToTest: fixed-defined-schedule-for-retail-user) | 200 | A valid paymentId provided in the path parameter should return a status code 200, and the paymentId must be included in the response | PIS_FDS006 | paymentToTest: fixed-Defined-Schedule | POST /event/patch: Negative Test - Verify that the endpoint throws error when mandatory fields are missing for Fixed Defined Schedule (paymentToTest: fixed-Defined-Schedule) | 204 | The operation must fail with a status code 400 when the request body contains only optional fields. |
|
Back to top
MultiPayments-FixedOnDemand
| Expand |
|---|
|
Test Scenario ID | Test Case ID | Field to be updated in the config.yaml | Test Name | Expected Response Code | Test Description |
|---|
MP_020_001 Ensure that FixedOnDemand requests are successfully handled by consent event & action / payments endpoints | Before_FOD001 | paymentToTest: event-AwaitingAuthorization-for-fixed-on-demand-retail-user | POST /event/post: Happy Path - Verify all mandatory request body fields with consent status AwaitingAuthorization for Fixed On Demand (paymentToTest: event-AwaitingAuthorization-for-fixed-on-demand-retail-user) | 204 | Ozone will be sending an consent in an AwaitingAuthorization state to the LFI after the consent/event/post endpoint is hit. | Before_FOD002 | paymentToTest: event-Authorized-for-fixed-on-demand-retail-user | POST event/patch : Happy Path : Verify the successful creation of an event when the consentStatus is set to Authorized for a predefined Fixed On Demand (paymentToTest: event-Authorized-for-fixed-on-demand-retail-user) | 204 | Ozone will be sending an consent in an Authorized state to the LFI after the consent/event/patch is hit. | PIS_FOD003 | paymentToTest: fixed-on-demand-for-retail-user | POST /payment: Happy Path - Verify all mandatory and optional request body fields for Fixed On Demand (paymentToTest: fixed-on-demand-for-retail-user) | 201 | The operartion must succeed with a status code 201 if the payment is successfully created | After_FOD004 | paymentToTest: event-Consumed-for-fixed-on-demand-retail-user | POST event/patch : Happy Path : Verify all mandatory request body fields with consent status consumed for Fixed On Demand (paymentToTest: event-Consumed-for-fixed-on-demand-retail-user) | 204 | Ozone will send a consent in a Consumed state to the LFI after the consent/event/patch endpoint is hit. | PIS_FOD005 | paymentToTest: fixed-on-demand-for-retail-user | GET /payement: Happy Path - Verify for valid paymentId in path parameter returns payments for fixed on demand (paymentToTest: fixed-on-demand-for-retail-user) | 200 | A valid paymentId provided in the path parameter should return a status code 200, and the paymentId must be present in the response | PIS_FOD006 | paymentToTest: fixed-on-demand | POST /event/patch: Negative Test - Verify that the endpoint throws error when mandatory fields are missing for Fixed On Demand (paymentToTest: fixed-on-demand) | 400 | The operation must fail with a status code 400 when the request body contains only optional fields. |
|
Back to top
MultiPayments-FixedPeriodicSchedule
| Expand |
|---|
|
Test Scenario ID | Test Case ID | Field to be updated in the config.yaml | Test Name | Expected Response Code | Test Description |
|---|
MP_030_001 Ensure that FixedPeriodicSchedule requests are successfully handled by consent event & action / payments endpoints | Before_FPS001 | paymentToTest: event-AwaitingAuthorisation-for-fixed-periodic-schedule-retail-user | POST /event/post: Happy Path - Verify all mandatory request body fields with consent status AwaitingAuthorization for Fixed Periodic Schedule (paymentToTest: event-AwaitingAuthorisation-for-fixed-periodic-schedule-retail-user) | 204 | Ozone will send a consent in an AwaitingAuthorization state to the LFI after the consent/event/post endpoint is hit.. | Before_FPS002 | paymentToTest: event-Authorized-for-fixed-periodic-schedule-retail-user | POST /event/patch: Happy Path - Verify the successful creation of an event when the consentStatus is set to Authorized for a predefined Fixed Periodic Schedule (paymentToTest: event-Authorized-for-fixed-periodic-schedule-retail-user) | 204 | Ozone will send a consent in an Authorized state to the LFI after the consent/event/patch endpoint is hit | PIS_FPS003 | paymentToTest: fixed-periodic-schedule-for-retail-user | POST /payment: Happy Path - Verify all mandatory and optional request body fields for Fixed Periodic Schedule (paymentToTest: fixed-periodic-schedule-for-retail-user) | 201 | The operation must succeed with a status code 201 if the payment is successfully created | After_FPS004 | paymentToTest: event-Consumed-for-fixed-periodic-schedule-retail-user | POST /event/patch: Happy Path - Verify all mandatory request body fields with consent status Consumed for Fixed Periodic Schedule (paymentToTest: event-Consumed-for-fixed-periodic-schedule-retail-user) | 204 | Ozone will send a consent in a Consumed state to the LFI after the consent/event/patch endpoint is hit | PIS_FPS005 | paymentToTest: fixed-periodic-schedule-for-retail-user | GET /payment: Happy Path - Verify that a valid paymentId in the path parameter returns payments for a Fixed Periodic Schedule (paymentToTest: fixed-periodic-schedule-for-retail-user) | 200 | A valid paymentId provided in the path parameter should return a status code 200, and the paymentId must be present in the response. | PIS_FPS006 | paymentToTest: fixed-periodic-schedule | POST /event/patch: Negative Test - Verify that the endpoint throws error when mandatory fields are missing for Fixed Periodic Schedule (paymentToTest: fixed-periodic-schedule) | 400 | The operation must fail with a status code 400 when the request body contains only optional fields |
|
Back to top
MultiPayments-VariableDefinedSchedule
| Expand |
|---|
|
Test Scenario ID | Test Case ID | Field to be updated in the config.yaml | Test Name | Expected Response Code | Test Description |
|---|
MP_040_001 Ensure that VariableDefinedSchedule requests are successfully handled by consent event & action / payments endpoints | Before_VDS001 | paymentToTest: event-AwaitingAuthorisation-for-variable-defined-schedule-retail-user | POST /event/post: Happy Path - Verify all mandatory request body fields with consent status AwaitingAuthorization for Variable Defined Schedule (paymentToTest: event-AwaitingAuthorisation-for-variable-defined-schedule-retail-user) | 204 | Ozone will send a consent in the AwaitingAuthorization state to the LFI after the consent/event/post endpoint is hit. | Before_VDS002 | paymentToTest: event-Authorized-for-variable-defined-schedule-retail-user | POST /event/patch: Happy Path - Verify the successful creation of an event when the consentStatus is set to Authorized for a predefined Variable Defined Schedule (paymentToTest: event-Authorized-for-variable-defined-schedule-retail-user) | 204 | Ozone will be sending an consent in an Authorized state to the LFI after the consent/event/patch is hit. | PIS_VDS003 | paymentToTest: variable-defined-schedule-for-retail-user | POST /payment: Happy Path - Verify all mandatory and optional request body fields for Variable Defined Schedule (paymentToTest: variable-defined-schedule-for-retail-user) | 201 | The operation must succeed with a status code 201 if the payment is created successfully | After_VDS004 | paymentToTest: event-Consumed-for-variable-defined-schedule-retail-user | POST /event/patch: Happy Path - Verify all mandatory request body fields with consent status Consumed for Variable Defined Schedule (paymentToTest: event-Consumed-for-variable-defined-schedule-retail-user) | 204 | Ozone will send a consent in a Consumed state to the LFI after the consent/event/patch is hit | PIS_VDS005 | paymentToTest: variable-defined-schedule-for-retail-user | GET /payment: Happy Path - Verify that a valid paymentId in the path parameter returns payments for Variable Defined Schedule (paymentToTest: variable-defined-schedule-for-retail-user) | 200 | A valid paymentId provided in the path parameter should return a status code of 200, and the paymentId must be present in the response | PIS_VDS006 | paymentToTest: variable-Defined-Schedule | PPOST /event/patch: Negative Test - Verify that the endpoint throws error when mandatory fields are missing for Variable Defined Schedule (paymentToTest: variable-Defined-Schedule) | 400 | The operation must fail with a status code 400 when the request body contains only optional fields |
|
Back to top
MultiPayments-VariableOnDemand
| Expand |
|---|
|
Test Scenario ID | Test Case ID | Field to be updated in the config.yaml | Test Name | Expected Response Code | Test Description |
|---|
MP_050_001 Ensure that VariableOnDemand requests are successfully handled by consent event & action / payments endpoints | Before_VOD001 | paymentToTest: event-AwaitingAuthorisation-for-variable-on-demand-retail-user | POST /event/post - Happy Path: Verify all mandatory request body fields with consent status AwaitingAuthorization for Variable On Demand (paymentToTest: event-AwaitingAuthorisation-for-variable-on-demand-retail-user) | 204 | Ozone will send a consent in the AwaitingAuthorization state to the LFI after the consent/event/post endpoint is hit | Before_VOD002 | paymentToTest: event-Authorized-for-variable-on-demand-retail-user | POST /event/patch: Happy Path - Verify the successful creation of an event when the consentStatus is set to Authorized for a predefined Variable On Demand (paymentToTest: event-Authorized-for-variable-on-demand-retail-user) | 204 | Ozone will send a consent in an Authorized state to the LFI after the consent/event/patch endpoint is hit. | PIS_VOD003 | paymentToTest: variable-on-demand-for-retail-user | POST /payment: Happy Path - Verify all mandatory and optional request body fields for Variable On Demand (paymentToTest: variable-on-demand-for-retail-user) | 201 | The operation must succeed with a status code 201 if the payment is created successfully. | After_VOD004 | paymentToTest: event-Consumed-for-variable-on-demand-retail-user | POST /event/patch: Happy Path - Verify all mandatory request body fields with consent status 'Consumed' for Variable On Demand (paymentToTest: event-Consumed-for-variable-on-demand-retail-user) | 204 | Ozone will send a consent in a Consumed state to the LFI after the consent/event/patch endpoint is hit. | PIS_VOD005 | paymentToTest: variable-on-demand-for-retail-user | GET /payment: Happy Path - Verify that a valid paymentId in the path parameter returns payments for Variable On Demand (paymentToTest: variable-on-demand-for-retail-user) | 200 | A valid paymentId provided in the path parameter should return a status code 200, and the paymentId must be present in the response | PIS_VOD006 | paymentToTest: variable-on-demand | POST event/patch: Negative Test - Verify that the endpoint throws error when mandatory fields are missing for Variable On Demand (paymentToTest: variable-on-demand) | 400 | The operation must fail with a status code 400 if the request body contains only optional fields |
|
Back to top
MultiPayments-VariablePeriodicSchedule
| Expand |
|---|
|
Test Scenario ID | Test Case ID | Field to be updated in the config.yaml | Test Name | Expected Response Code | Test Description |
|---|
MP_060_001 Ensure that VariablePeriodicSchedule requests are successfully handled by consent event & action / payments endpoints | Before_VPS001 | paymentToTest: event-AwaitingAuthorisation-for-variable-periodic-schedule-retail-user | POST /event/post - Happy Path: Verify all mandatory request body fields with consent status AwaitingAuthorization for a Variable Periodic Schedule (paymentToTest: event-AwaitingAuthorisation-for-variable-periodic-schedule-retail-user) | 204 | Ozone will send a consent in the AwaitingAuthorization state to the LFI after the consent/event/post endpoint is hit | Before_VPS002 | paymentToTest: event-Authorized-for-variable-periodic-schedule-retail-user | POST /event/patch - Happy Path: Verify the successful creation of an event when the consentStatus is set to Authorized for a predefined variable periodic schedule (paymentToTest: event-Authorized-for-variable-periodic-schedule-retail-user) | 204 | Ozone will send a consent in an Authorized state to the LFI after the consent/event/patch endpoint is hit. | PIS_VPS003 | paymentToTest: variable-periodic-schedule-for-retail-user | POST /payment - Happy Path: Verify all mandatory request body fields for a variable periodic schedule (paymentToTest: variable-periodic-schedule-for-retail-user) | 201 | The operation must succeed with a status code 201 if the payment is created successfully. | After_VPS004 | paymentToTest: event-Consumed-for-variable-periodic-schedule-retail-user | POST /event/patch - Happy Path: Verify all mandatory request body fields with consent status Consumed for a variable periodic schedule (paymentToTest: event-Consumed-for-variable-periodic-schedule-retail-user) | 204 | Ozone will send a consent in a Consumed state to the LFI after the consent/event/patch endpoint is hit | PIS_VPS005 | paymentToTest: variable-periodic-schedule-for-retail-user | GET /payment - Happy Path: Verify that providing a valid paymentId in the path parameter returns the payment for a variable periodic schedule. (paymentToTest: variable-periodic-schedule-for-retail-user) | 200 | A valid paymentId provided in the path parameter should return a status code 200, and the paymentId must be present in the response | PIS_VPS006 | paymentToTest: variable-periodic-schedule | POST /event/patch - Negative Test: Verify that the endpoint throws error when mandatory fields are missing for a variable periodic schedule (paymentToTest: variable-periodic-schedule) | 400 | The operation must fail with a status code 400 if the request body contains only optional fields |
|
Back to top
MultiPayments-combinedFDPWithFixedDefinedSchedule
| Expand |
|---|
|
Test Scenario ID | Test Case ID | Field to be updated in the config.yaml | Test Name | Expected Response Code | Test Description |
|---|
MP_070_001 Ensure that combinedFDPWithFixedDefinedSchedule requests are successfully handled by consent event & action / payments endpoints | PIS_Before_FDPFDS001 | paymentToTest: event-AwaitingAuthorisation-for-CombinedFDP-fixed-defined-schedule-retail-user | POST /event/post: Happy Path - Combined Future Dated Payment with a Fixed Defined Schedule for consent status AwaitingAuthorisation (paymentToTest: event-AwaitingAuthorisation-for-CombinedFDP-fixed-defined-schedule-retail-user) | 204 | Ensure that Ozone sends a consent in an 'AwaitingAuthorisation' state to the LFI after calling the /event/post endpoint, resulting in a status code 204. | PIS_Before_FDPFDS002 | paymentToTest: event-Authorized-for-CombinedFDP-fixed-defined-schedule-retail-user | POST /event/patch: Happy Path - Verify the successful creation of an event when the consentStatus is set to Authorized for a predefined combined FDP with fixed defined schedule (paymentToTest: event-Authorized-for-CombinedFDP-fixed-defined-schedule-retail-user) | 204 | Ensure that Ozone sends a consent in an 'Authorized' state to the LFI after calling the /event/post endpoint, resulting in a status code 204. | PIS_FDPFDS003 | paymentToTest: CombinedFDP-fixed-defined-schedule-for-retail-user | POST /payment: Happy Path - Verify all mandatory and optional fields in the request body for a Combined Future Dated Payment with a Fixed Defined Schedule (paymentToTest: CombinedFDP-fixed-defined-schedule-for-retail-user) | 201 | The payment must be successfully created with a status code 201 upon successful operation. | PIS_After_FDPFDS004 | paymentToTest: event-Consumed-for-CombinedFDP-fixed-defined-schedule-retail-user | POST /event/patch: Happy Path - Combined Future Dated Payment with a Fixed Defined Schedule for consent status Consumed (paymentToTest: event-Consumed-for-CombinedFDP-fixed-defined-schedule-retail-user) | 204 | Ensure that Ozone sends a consent in a 'Consumed' state to the LFI after calling the /event/patch endpoint, resulting in a status code 204. | PIS_FDPFDS005 | paymentToTest: CombinedFDP-fixed-defined-schedule-for-retail-user | GET /payment: Happy Path - Verify retrieval for a valid paymentId in the path parameter for Combined Future Dated Payment with a Fixed Defined Schedule (paymentToTest: CombinedFDP-fixed-defined-schedule-for-retail-user) | 200 | A valid paymentId in the path parameter should return a status code 200, with the paymentId present in the response. | PIS_FDPFDS006 | paymentToTest: fixed-Defined-schedule | POST /event/patch: Negative Test - Verify that the endpoint throws error when mandatory fields are missing for Combined Future Dated Payment with a Fixed Defined Schedule (paymentToTest: fixed-Defined-schedule) | 400 | The operation must fail with a status code 400 due to missing mandatory fields. |
|
Back to top
MultiPayments-combinedFDPWithFixedOnDemand
| Expand |
|---|
|
Test Scenario ID | Test Case ID | Field to be updated in the config.yaml | Test Name | Expected Response Code | Test Description |
|---|
MP_080_001 Ensure that combinedFDPWithFixedOnDemand requests are successfully handled by consent event & action / payments endpoints | PIS_Before_FDPFOD001 | paymentToTest: event-AwaitingAuthorisation-for-CombinedFDP-fixed-on-demand-retail-user | POST /event/post: Happy Path - Combined Future Dated Payment with Fixed On Demand for consent status 'AwaitingAuthorisation' (paymentToTest: event-AwaitingAuthorisation-for-CombinedFDP-fixed-on-demand-retail-user) | 204 | Verify that Ozone sends a consent in the 'AwaitingAuthorisation' state to the LFI after hitting the POST /event/post endpoint. The operation must succeed with a status code 204. | PIS_Before_FDPFOD002 | paymentToTest: event-Authorized-for-CombinedFDP-fixed-on-demand-retail-user | POST /event/patch: Happy Path - Verify the successful creation of an event when the consentStatus is set to Authorized for predefined combined FDP with fixed on demand (paymentToTest: event-Authorized-for-CombinedFDP-fixed-on-demand-retail-user) | 204 | Verify that Ozone sends a consent in the 'Authorized' state to the LFI after hitting the POST /event/post endpoint. The operation must succeed with a status code 204. | PIS_FDPFOD003 | paymentToTest: CombinedFDP-fixed-on-demand-for-retail-user | POST /payment: Happy Path - Verify all mandatory and optional request body fields for Combined Future Dated Payment with Fixed On Demand (paymentToTest: CombinedFDP-fixed-on-demand-for-retail-user) | 201 | Verify that the operation succeeds with a status code 201 when the payment is successfully created. | PIS_After_FDPFOD004 | paymentToTest: event-Consumed-for-CombinedFDP-fixed-on-demand-retail-user | POST /event/patch: Happy Path - Combined Future Dated Payment with Fixed On Demand for consent status 'Consumed' (paymentToTest: event-Consumed-for-CombinedFDP-fixed-on-demand-retail-user) | 204 | Verify that Ozone sends a consent in the 'Consumed' state to the LFI after hitting the POST /event/patch endpoint. The operation must succeed with a status code 204. | PIS_FDPFOD005 | paymentToTest: CombinedFDP-fixed-on-demand-for-retail-user | GET /payment: Happy Path - Verify response for a valid paymentId with Combined Future Dated Payment and Fixed On Demand (paymentToTest: CombinedFDP-fixed-on-demand-for-retail-user) | 200 | Verify that providing a valid paymentId in the path parameter returns a status code 200 and includes the paymentId in the response. | PIS_FDPFOD006 | paymentToTest: fixed-on-demand | POST /event/patch: Negative Test - Verify that the endpoint throws error when mandatory fields are missing for Combined Future Dated Payment with Fixed On Demand (paymentToTest: fixed-on-demand) | 400 | Verify that the operation fails with a status code 400 when only optional request fields are provided in the request body. |
|
Back to top
MultiPayments-combinedFDPWithFixedPeriodicSchedule
| Expand |
|---|
|
Test Scenario ID | Test Case ID | Field to be updated in the config.yaml | Test Name | Expected Response Code | Test Description |
|---|
MP_090_001 Ensure that combinedFDPWithFixedPeriodicSchedule requests are successfully handled by consent event & action / payments endpoints | PIS_Before_FDPFPS001 | paymentToTest: event-AwaitingAuthorisation-for-CombinedFDP-fixed-periodic-schedule-retail-user | POST /event/post: Happy Path - Combined Future Dated Payment with Fixed Periodic Schedule for Consent Status AwaitingAuthorisation (paymentToTest: event-AwaitingAuthorisation-for-CombinedFDP-fixed-periodic-schedule-retail-user) | 204 | Ensure the LFI receives a consent in an AwaitingAuthorisation state after invoking the /event/post endpoint. The operation must succeed with a status code 204. | PIS_Before_FDPFPS002 | paymentToTest: event-Authorized-for-CombinedFDP-fixed-periodic-schedule-retail-user | POST /event/patch: Happy Path - Verify the successful creation of an event when the consentStatus is set to Authorized for predefined combined FDP with fixed periodic schedule (paymentToTest: event-Authorized-for-CombinedFDP-fixed-periodic-schedule-retail-user) | 204 | Ensure the LFI receives a consent in an Authorized state after invoking the /event/post endpoint. The operation must succeed with a status code 204. | PIS_FDPFPS003 | paymentToTest: CombinedFDP-fixed-periodic-schedule-for-retail-user | POST /payment: Happy Path - Verify All Mandatory and Optional Fields for Combined Future Dated Payment with Fixed Periodic Schedule (paymentToTest: CombinedFDP-fixed-periodic-schedule-for-retail-user) | 201 | Ensure the payment is successfully created using all mandatory and optional fields in the request body. The operation must succeed with a status code 201. | PIS_After_FDPFPS004 | paymentToTest: event-Consumed-for-CombinedFDP-fixed-periodic-schedule-retail-user | POST /event/patch: Happy Path - Combined Future Dated Payment with Fixed Periodic Schedule for consent status 'Consumed' (paymentToTest: event-Consumed-for-CombinedFDP-fixed-periodic-schedule-retail-user) | 204 | Ensure the LFI receives a consent in a Consumed state after invoking the /event/patch endpoint. The operation must succeed with a status code 204. | PIS_FDPFPS005 | paymentToTest: CombinedFDP-fixed-periodic-schedule-for-retail-user | GET /payment: Happy Path - Verify Valid paymentId for Combined Future Dated Payment with Fixed Periodic Schedule (paymentToTest: CombinedFDP-fixed-periodic-schedule-for-retail-user) | 200 | Ensure that providing a valid paymentId in the path parameter returns status code 200, with the paymentId present in the response. | PIS_FDPFPS006 | paymentToTest: fixed-periodic-schedule | POST /event/patch: Negative Test - Verify that the endpoint throws error when mandatory fields are missing for Combined Future Dated Payment with Fixed Periodic Schedule (paymentToTest: fixed-periodic-schedule) | 400 | Verify the operation fails with a status code 400 when only optional request fields are provided. |
|
Back to top
MultiPayments-combinedFDPWithVariableDefinedSchedule
| Expand |
|---|
|
Test Scenario ID | Test Case ID | Field to be updated in the config.yaml | Test Name | Expected Response Code | Test Description |
|---|
MP_100_001 Ensure that combinedFDPWithVariableDefinedSchedule requests are successfully handled by consent event & action / payments endpoints | PIS_Before_FDPVDS001 | paymentToTest: event-AwaitingAuthorisation-for-CombinedFDP-variable-defined-schedule-retail-user | POST /event/post: Happy Path - Combined Future Dated Payment with Variable Defined Schedule for Consent Status AwaitingAuthorisation (paymentToTest: event-AwaitingAuthorisation-for-CombinedFDP-variable-defined-schedule-retail-user) | 204 | Ensure a consent in the AwaitingAuthorisation state is sent to the LFI after invoking the /event/post endpoint. The operation must succeed with a status code 204. | PIS_Before_FDPVDS002 | paymentToTest: event-Authorized-for-CombinedFDP-variable-defined-schedule-retail-user | POST /event/patch: Happy Path - Verify the successful creation of an event when the consentStatus is set to Authorized for a predefined combined FDP with variable defined schedule (paymentToTest: event-Authorized-for-CombinedFDP-variable-defined-schedule-retail-user) | 204 | Ensure a consent in the Authorized state is sent to the LFI after invoking the /event/patch endpoint. The operation must succeed with a status code 204. | PIS_FDPVDS003 | paymentToTest: CombinedFDP-variable-defined-schedule-for-retail-user | POST /payment: Happy Path - Verify All Mandatory and Optional Fields for Combined Future Dated Payment with Variable Defined Schedule (paymentToTest: CombinedFDP-variable-defined-schedule-for-retail-user) | 201 | Ensure the payment is successfully created using all mandatory and optional fields in the request body. The operation must succeed with a status code 201. | PIS_After_FDPVDS004 | paymentToTest: event-Consumed-for-CombinedFDP-variable-defined-schedule-retail-user | POST /event/patch: Happy Path - Combined Future Dated Payment with Variable Defined Schedule for Consent Status Consumed (paymentToTest: event-Consumed-for-CombinedFDP-variable-defined-schedule-retail-user) | 204 | Ensure a consent in the Consumed state is sent to the LFI after invoking the /event/patch endpoint. The operation must succeed with a status code 204. | PIS_FDPVDS005 | paymentToTest: CombinedFDP-variable-defined-schedule-for-retail-user | GET /payment: Happy Path - Validate Payment Retrieval for Combined Future Dated Payment with Variable Defined Schedule including the paymentId in the response. (paymentToTest: CombinedFDP-variable-defined-schedule-for-retail-user) | 200 | Ensure that providing a valid paymentId in the path parameter returns status code 200, with the paymentId present in the response. | PIS_FDPVDS006 | paymentToTest: variable-Defined-Schedule | POST /event/patch: Negative Test - Verify that the endpoint throws error when mandatory fields are missing for Combined Future Dated Payment with Variable Defined Schedule (paymentToTest: variable-Defined-Schedule) | 400 | Verify that the operation returns a status code 400 when the request body contains only optional fields, ensuring proper validation for Combined Future Dated Payment with a Variable Defined Schedule. |
|
Back to top
MultiPayments-combinedFDPWithVariableOnDemand
| Expand |
|---|
|
Test Scenario ID | Test Case ID | Field to be updated in the config.yaml | Test Name | Expected Response Code | Test Description |
|---|
MP_110_001 Ensure that combinedFDPWithVariableOnDemand requests are successfully handled by consent event & action / payments endpoints | PIS_Before_FDPVOD001 | paymentToTest: event-AwaitingAuthorisation-for-CombinedFDP-variable-on-demand-retail-user | POST /event/post: Happy Path - Combined Future Dated Payment with Fixed On Demand for Consent Status AwaitingAuthorisation (paymentToTest: event-AwaitingAuthorisation-for-CombinedFDP-variable-on-demand-retail-user) | 204 | Ensure that a consent in the AwaitingAuthorisation state is sent to the LFI after invoking the /event/post endpoint. The operation should succeed with a status code 204. | PIS_Before_FDPVOD002 | paymentToTest: event-Authorized-for-CombinedFDP-variable-on-demand-retail-user | POST /event/patch: Happy Path - Verify the successful creation of an event when the consentStatus is set to Authorized for a predefined combined FDP with variable on demand (paymentToTest: event-Authorized-for-CombinedFDP-variable-on-demand-retail-user) | 204 | Ensure that a consent in the Authorized state is sent to the LFI after invoking the /event/post endpoint. The operation should succeed with a status code 204. | PIS_FDPVOD003 | paymentToTest: CombinedFDP-variable-on-demand-for-retail-user | POST /payment: Happy Path - Verify All Mandatory and Optional Fields for Combined Future Dated Payment with Fixed On Demand (paymentToTest: CombinedFDP-variable-on-demand-for-retail-user) | 201 | Ensure the payment is successfully created with all mandatory and optional fields. The operation should return a status code 201 upon successful creation. | PIS_After_FDPVOD004 | paymentToTest: event-Consumed-for-CombinedFDP-variable-on-demand-retail-user | POST /event/patch: Happy Path - Combined Future Dated Payment with Fixed On Demand for Consent Status Consumed (paymentToTest: event-Consumed-for-CombinedFDP-variable-on-demand-retail-user) | 204 | Ensure that a consent in the Consumed state is sent to the LFI after invoking the /event/patch endpoint. The operation should succeed with a status code 204. | PIS_FDPVOD005 | paymentToTest: CombinedFDP-variable-on-demand-for-retail-user | GET /payment: Happy Path - Validate Payment Retrieval for Combined Future Dated Payment with Variable on demand including the paymentId in the response. (paymentToTest: CombinedFDP-variable-on-demand-for-retail-user) | 200 | Ensure that providing a valid paymentId in the path parameter returns a status code 200 and the paymentId is included in the response. | PIS_FDPVOD006 | paymentToTest: variable-on-demand | POST /event/patch: Negative Test - Verify that the endpoint throws error when mandatory fields are missing for Combined Future Dated Payment with Fixed On Demand (paymentToTest: variable-on-demand) | 400 | Ensure that the operation fails with a status code 400 when only optional fields are provided in the request body. |
|
Back to top
MultiPayments-combinedFDPWithVariablePeriodicSchedule
| Expand |
|---|
|
Test Scenario ID | Test Case ID | Field to be updated in the config.yaml | Test Name | Expected Response Code | Test Description |
|---|
MP_120_001 Ensure that combinedFDPWithVariablePeriodicSchedule requests are successfully handled by consent event & action / payments endpoints | PIS_Before_FDPVPS001 | paymentToTest: event-AwaitingAuthorisation-for-CombinedFDP-variable-periodic-schedule-retail-user | POST /event/post: Happy Path - Combined future dated payment with variable Periodic Schedule for Consent Status AwaitingAuthorisation (paymentToTest: event-AwaitingAuthorisation-for-CombinedFDP-variable-periodic-schedule-retail-user) | 204 | Ozone sends a consent in an AwaitingAuthorisation state to the LFI after the consent/event/post endpoint is invoked. The operation should succeed with a status code 204. | PIS_Before_FDPVPS002 | paymentToTest: event-Authorized-for-CombinedFDP-variable-periodic-schedule-retail-user | POST /event/patch: Happy Path - Verify the successful creation of an event when the consentStatus is set to Authorized for a predefined combined FDP with variable periodic schedule (paymentToTest: event-Authorized-for-CombinedFDP-variable-periodic-schedule-retail-user) | 204 | Ozone sends a consent in an Authorized state to the LFI after the consent/event/post endpoint is invoked. The operation should succeed with a status code 204. | PIS_FDPVPS003 | paymentToTest:CombinedFDP-variable-periodic-schedule-for-retail-user | POST /payment: Happy Path - Verify with All Mandatory and Optional Request Body Fields for Combined future dated payment with variable Periodic Schedule (paymentToTest:CombinedFDP-variable-periodic-schedule-for-retail-user) (Mandatory+Optional) | 201 | The operation should succeed with a status code 201 if the payment is successfully created. | PIS_After_FDPVPS004 | paymentToTest: event-Consumed-for-CombinedFDP-variable-periodic-schedule-retail-user | POST /event/patch: Happy Path - Combined future dated payment with variable Periodic Schedule for Consent Status Consumed (paymentToTest: event-Consumed-for-CombinedFDP-variable-periodic-schedule-retail-user) | 204 | Ozone sends a consent in a Consumed state to the LFI after the consent/event/patch endpoint is invoked. The operation should succeed with a status code 204. | PIS_FDPVPS005 | paymentToTest:CombinedFDP-variable-periodic-schedule-for-retail-user | GET /payment: Happy Path - Verify for Valid paymentId in Path Parameter Returning Payments for Combined future dated payment with variable Periodic Schedule (paymentToTest:CombinedFDP-variable-periodic-schedule-for-retail-user) | 200 | A valid paymentId provided in the path parameter should return a status code 200, and the paymentId must be present in the response. | PIS_FDPVPS006 | Optional | POST /event/patch: Negative Test - Verify that the endpoint throws error when mandatory fields are missing for Combined future dated payment with variable Periodic Schedule (Optional) (paymentToTest: variable-periodic-schedule) | 400 | Ensure that the operation fails with a status code 400 when only optional fields are provided in the request body. |
|
Back to top
MultiPayments-combinedSIPWithFixedDefinedSchedule
| Expand |
|---|
|
Test Scenario ID | Test Case ID | Field to be updated in the config.yaml | Test Name | Expected Response Code | Test Description |
|---|
MP_130_001 Ensure that combinedSIPWithFixedDefinedSchedule requests are successfully handled by consent event & action / payments endpoints | PIS_Before_SIPFDS001 | paymentToTest: event-AwaitingAuthorisation-for-CombinedSIP-fixed-defined-schedule-retail-user | POST /event/post : Happy Path : Combined Single Instant Payment with Fixed Defined Schedule for consent status AwaitingAuthorisation (paymentToTest: event-AwaitingAuthorisation-for-CombinedSIP-fixed-defined-schedule-retail-user) | 204 | Ozone will send a consent in an AwaitingAuthorisation state to the LFI after the consent/event/post endpoint is hit. The operation must succeed with a status code 204. | PIS_Before_SIPFDS002 | paymentToTest: event-Authorized-for-CombinedSIP-fixed-defined-schedule-retail-user | POST /event/patch : Happy Path : Verify the successful creation of an event when the consentStatus is set to Authorized for a predefined combined SIP with fixed defined schedule (paymentToTest: event-Authorized-for-CombinedSIP-fixed-defined-schedule-retail-user) | 204 | Ozone will send a consent in an Authorized state to the LFI after the consent/event/post endpoint is hit. The operation must succeed with a status code 204. | PIS_SIPFDS003 | paymentToTest: CombinedSIP-fixed-defined-schedule-for-retail-user | POST /payment: Happy Path - Verify All Mandatory and Optional Request Body Fields for Combined Single Instant Payment with Fixed Defined Schedule (paymentToTest: CombinedSIP-fixed-defined-schedule-for-retail-user) | 201 | Ensure that the payment is successfully created when all mandatory and optional fields are provided for a combined single instant payment with a fixed defined schedule. The operation should return a status code 201 upon successful creation | PIS_After_SIPFDS004 | paymentToTest: event-Consumed-for-CombinedSIP-fixed-defined-schedule-retail-user | POST event/patch : Happy Path : Combined Single Instant Payment with Fixed Defined Schedule for consent status Consumed (paymentToTest: event-Consumed-for-CombinedSIP-fixed-defined-schedule-retail-user) | 204 | Ozone will send a consent in a Consumed state to the LFI after the consent/event/patch is hit. The operation must succeed with a status code 204. | PIS_SIPFDS005 | paymentToTest: CombinedSIP-fixed-defined-schedule-for-retail-user | GET /payment: Happy Path - Verify Valid paymentId in Path Parameter Returns Payment for Combined Single Instant Payment with Fixed Defined Schedule (paymentToTest: CombinedSIP-fixed-defined-schedule-for-retail-user) | 200 | Valid paymentId provided in the path parameter should return a status code 200, and the paymentId must be present in the response. | PIS_SIPFDS006 | paymentToTest: fixed-Defined-schedule | POST /event/patch: Negative Test - Verify that the endpoint throws error when mandatory fields are missing for Combined Single Instant Payment with Fixed Defined Schedule (paymentToTest: fixed-Defined-schedule) | 400 | The operation should fail with a status code 400 when the request body contains only optional fields. |
|
Back to top
MultiPayments-combinedSIPWithFixedOnDemand
| Expand |
|---|
|
Test Scenario ID | Test Case ID | Field to be updated in the config.yaml | Test Name | Expected Response Code | Test Description |
|---|
MP_140_001 Ensure that combinedSIPWithFixedOnDemand requests are successfully handled by consent event & action / payments endpoints | PIS_Before_SIPFOD001 | paymentToTest: event-AwaitingAuthorisation-for-CombinedSIP-fixed-on-demand-retail-user | POST /event/post: Happy Path - Combined Single Instant Payment with Fixed On Demand and Consent Status AwaitingAuthorisation (paymentToTest: event-AwaitingAuthorisation-for-CombinedSIP-fixed-on-demand-retail-user) | 204 | Ozone will send a consent in the AwaitingAuthorisation state to the LFI after hitting the consent/event/post endpoint. The operation should succeed with a status code 204. | PIS_Before_SIPFOD002 | paymentToTest: event-Authorized-for-CombinedSIP-fixed-on-demand-retail-user | POST /event/patch: Happy Path - Verify the successful creation of an event when the consentStatus is set to Authorized for predefined combined SIP with fixed on demand (paymentToTest: event-Authorized-for-CombinedSIP-fixed-on-demand-retail-user) | 204 | Ozone will send a consent in the Authorized state to the LFI after hitting the consent/event/post endpoint. The operation should succeed with a status code 204. | PIS_SIPFOD003 | paymentToTest: CombinedSIP-fixed-on-demand-for-retail-user | POST /payment: Happy Path - Verify the inclusion of all mandatory and optional request body fields for Combined Single Instant Payment with Fixed On Demand (paymentToTest: CombinedSIP-fixed-on-demand-for-retail-user) | 201 | The operation should succeed with a status code 201 if the payment is successfully created with all mandatory and optional fields. | PIS_After_SIPFOD004 | paymentToTest: event-Consumed-for-CombinedSIP-fixed-on-demand-retail-user | POST /event/patch: Happy Path - Combined Single Instant Payment with Fixed On Demand and Consent Status Consumed (paymentToTest: event-Consumed-for-CombinedSIP-fixed-on-demand-retail-user) | 204 | Ozone will send a consent in the Consumed state to the LFI after hitting the consent/event/patch endpoint. The operation should succeed with a status code 204. | PIS_SIPFOD005 | paymentToTest: CombinedSIP-fixed-on-demand-for-retail-user | GET /payment: Happy Path - Verify that a valid paymentId in the path parameter returns payments for Combined Single Instant Payment with Fixed On Demand (paymentToTest: CombinedSIP-fixed-on-demand-for-retail-user) | 200 | A valid paymentId in the path parameter should return a status code 200, and the paymentId must be included in the response. | PIS_SIPFOD006 | paymentToTest: fixed-on-demand | POST /event/patch: Negative Test - Verify that the endpoint throws error when mandatory fields are missing for Combined Single Instant Payment with Fixed On Demand (paymentToTest: fixed-on-demand) | 400 | The operation should fail with a status code 400 when the request body contains only optional fields and no mandatory fields. |
|
Back to top
MultiPayments-combinedSIPWithFixedPeriodicSchedule
| Expand |
|---|
|
Test Scenario ID | Test Case ID | Field to be updated in the config.yaml | Test Name | Expected Response Code | Test Description |
|---|
MP_150_001 Ensure that combinedSIPWithFixedPeriodicSchedule requests are successfully handled by consent event & action / payments endpoints | PIS_Before_SIPFPS001 | paymentToTest: event-AwaitingAuthorisation-for-CombinedSIP-fixed-periodic-schedule-retail-user | POST /event/post: Happy Path - Combined Single Instant Payment with Fixed Periodic Schedule for Consent Status AwaitingAuthorisation (paymentToTest: event-AwaitingAuthorisation-for-CombinedSIP-fixed-periodic-schedule-retail-user) | 204 | Ozone sends a consent in an AwaitingAuthorisation state to the LFI after the consent/event/post endpoint is invoked. The operation should succeed with a status code 204. | PIS_Before_SIPFPS002 | paymentToTest: event-Authorized-for-CombinedSIP-fixed-periodic-schedule-retail-user | POST /event/patch: Happy Path - Verify the successful creation of an event when the consentStatus is set to Authorized for a predefined combined SIP with fixed periodic schedule (paymentToTest: event-Authorized-for-CombinedSIP-fixed-periodic-schedule-retail-user) | 204 | Ozone sends a consent in an Authorized state to the LFI after the consent/event/post endpoint is invoked. The operation should succeed with a status code 204. | PIS_SIPFPS003 | paymentToTest: CombinedSIP-fixed-periodic-schedule-for-retail-user | POST /payment: Happy Path - Verify All Mandatory and Optional Request Body Fields for Combined Single Instant Payment with Fixed Periodic Schedule (paymentToTest: CombinedSIP-fixed-periodic-schedule-for-retail-user) | 201 | The operation should succeed with a status code 201 if the payment is created successfully. | PIS_After_SIPFPS004 | paymentToTest: event-Consumed-for-CombinedSIP-fixed-periodic-schedule-retail-user | POST /event/patch: Happy Path - Combined Single Instant Payment with Fixed Periodic Schedule for Consent Status Consumed (paymentToTest: event-Consumed-for-CombinedSIP-fixed-periodic-schedule-retail-user) | 204 | Ozone sends a consent in a Consumed state to the LFI after the consent/event/patch endpoint is invoked. The operation should succeed with a status code 204. | PIS_SIPFPS005 | paymentToTest: CombinedSIP-fixed-periodic-schedule-for-retail-user | GET /payment: Happy Path - Verify that a valid paymentId in the path parameter returns payments for a combined single instant payment with a fixed periodic schedule (paymentToTest: CombinedSIP-fixed-periodic-schedule-for-retail-user) | 200 | A valid paymentId provided in the path parameter should return a status code of 200, and the paymentId must be included in the response | PIS_SIPFPS006 | paymentToTest: fixed-periodic-schedule | POST /event/patch: Negative Test - Verify that the endpoint throws error when mandatory fields are missing for Combined Single Instant Payment with Fixed Periodic Schedule (paymentToTest: fixed-periodic-schedule) | 400 | The operation should return a status code of 400 when only optional request fields are included. |
|
Back to top
MultiPayments-combinedSIPWithVariableDefinedSchedule
| Expand |
|---|
|
Test Scenario ID | Test Case ID | Field to be updated in the config.yaml | Test Name | Expected Response Code | Test Description |
|---|
MP_160_001 Ensure that combinedSIPWithVariableDefinedSchedule requests are successfully handled by consent event & action / payments endpoints | PIS_Before_SIPVDS001 | paymentToTest: event-AwaitingAuthorisation-for-CombinedSIP-variable-defined-schedule-retail-user | POST /event/post: Happy Path - Combined Single Instant Payment with Fixed Defined Schedule for Consent Status AwaitingAuthorisation (paymentToTest: event-AwaitingAuthorisation-for-CombinedSIP-variable-defined-schedule-retail-user) | 204 | Ozone will send a consent with an AwaitingAuthorisation status to the LFI after hitting the consent/event/post endpoint. The operation should succeed with a status code 204. | PIS_Before_SIPVDS002 | paymentToTest: event-Authorized-for-CombinedSIP-variable-defined-schedule-retail-user | POST /event/patch: Happy Path - Verify the successful creation of an event when the consentStatus is set to Authorized for a predefined combined SIP with variable defined schedule (paymentToTest: event-Authorized-for-CombinedSIP-variable-defined-schedule-retail-user) | 204 | Ozone will send a consent with an Authorized status to the LFI after hitting the consent/event/patch endpoint. The operation should succeed with a status code 204. | PIS_SIPVDS003 | paymentToTest: CombinedSIP-variable-defined-schedule-for-retail-user | POST /payment: Happy Path - Validate All Mandatory and Optional Request Body Fields for Combined Single Instant Payment with Fixed Defined Schedule (paymentToTest: CombinedSIP-variable-defined-schedule-for-retail-user) | 201 | The operation should succeed with a status code 201 if the payment is created successfully. | PIS_After_SIPVDS004 | paymentToTest: event-Consumed-for-CombinedSIP-variable-defined-schedule-retail-user | POST /event/patch: Happy Path - Combined Single Instant Payment with Fixed Defined Schedule for Consent Status Consumed (paymentToTest: event-Consumed-for-CombinedSIP-variable-defined-schedule-retail-user) | 204 | Ozone will send a consent with a Consumed status to the LFI after hitting the consent/event/patch endpoint. The operation should succeed with a status code 204. | PIS_SIPVDS005 | paymentToTest: CombinedSIP-variable-defined-schedule-for-retail-user | GET /payment: Happy Path - Verify that a Valid paymentId in the Path Parameter Returns the Correct Payment for Combined Single Instant Payment with a Fixed Defined Schedule (paymentToTest: CombinedSIP-variable-defined-schedule-for-retail-user) | 200 | Providing a valid paymentId in the path parameter should return a status code 200, and the paymentId must be present in the response. | PIS_SIPVDS006 | paymentToTest: variable-Defined-Schedule | POST /event/patch: Negative Test - Verify that the endpoint throws error when mandatory fields are missing for Combined Single Instant Payment with Fixed Defined Schedule (paymentToTest: variable-Defined-Schedule) | 400 | The operation must fail with a status code 400 when the request body contains only optional fields. |
|
Back to top
MultiPayments-combinedSIPWithVariableOnDemand
| Expand |
|---|
|
Test Scenario ID | Test Case ID | Field to be updated in the config.yaml | Test Name | Expected Response Code | Test Description |
|---|
MP_170_001 Ensure that combinedSIPWithVariableOnDemand requests are successfully handled by consent event & action / payments endpoints | PIS_Before_SIPVOD001 | paymentToTest: event-AwaitingAuthorisation-for-CombinedSIP-variable-on-demand-retail-user | POST /event/post : Happy Path : Combined Single Instant Payment with Variable On Demand for consent status AwaitingAuthorisation (paymentToTest: event-AwaitingAuthorisation-for-CombinedSIP-variable-on-demand-retail-user) | 204 | Ozone will send a consent in an AwaitingAuthorisation state to the LFI after the consent/event/post endpoint is hit. The operation must succeed with a status code 204. | PIS_Before_SIPVOD002 | paymentToTest: event-Authorized-for-CombinedSIP-variable-on-demand-retail-user | POST /event/patch : Happy Path : Verify the successful creation of an event when the consentStatus is set to Authorized for predefined combined SIP with variable on demand (paymentToTest: event-Authorized-for-CombinedSIP-variable-on-demand-retail-user) | 204 | Ozone will send a consent in an Authorized state to the LFI after the consent/event/post endpoint is hit. The operation must succeed with a status code 204. | PIS_SIPVOD003 | paymentToTest: CombinedSIP-variable-on-demand-for-retail-user | POST /payment: Happy Path - Verify All Mandatory and Optional Request Body Fields for Combined Single Instant Payment with Variable On Demand (paymentToTest: CombinedSIP-variable-on-demand-for-retail-user) | 201 | The operation must succeed with a status code 201 if the payment is successfully created. | PIS_After_SIPVOD004 | paymentToTest: event-Consumed-for-CombinedSIP-variable-on-demand-retail-user | POST event/patch : Happy Path : Combined Single Instant Payment with Variable On Demand for consent status Consumed (paymentToTest: event-Consumed-for-CombinedSIP-variable-on-demand-retail-user) | 204 | Ozone will send a consent in a Consumed state to the LFI after the consent/event/patch is hit. The operation must succeed with a status code 204. | PIS_SIPVOD005 | paymentToTest: CombinedSIP-variable-on-demand-for-retail-user | GET /payment: Happy Path - Verify that a valid paymentId in the path parameter returns the payment details for Combined Single Instant Payment with Variable On Demand (paymentToTest: CombinedSIP-variable-on-demand-for-retail-user) | 200 | Valid paymentId provided in the path parameter should return a status code 200, and the paymentId must be present in the response. | PIS_SIPVOD006 | paymentToTest: variable-on-demand | POST /event/patch: Negative Test - Verify that the endpoint throws error when mandatory fields are missing for Combined Single Instant Payment with Variable On Demand (paymentToTest: variable-on-demand) | 400 | The operation must fail with a status code 400 when only optional request fields are provided. |
|
Back to top
MultiPayments-combinedSIPWithVariablePeriodicSchedule
| Expand |
|---|
|
Test Scenario ID | Test Case ID | Field to be updated in the config.yaml | Test Name | Expected Response Code | Test Description |
|---|
MP_180_001 Ensure that combinedSIPWithVariablePeriodicSchedule requests are successfully handled by consent event & action / payments endpoints | PIS_Before_SIPVPS001 | paymentToTest: event-AwaitingAuthorisation-for-CombinedSIP-variable-periodic-schedule-retail-user | POST /event/post: Happy Path - Combined Single Instant Payment with variable Periodic Schedule for Consent Status AwaitingAuthorisation (paymentToTest: event-AwaitingAuthorisation-for-CombinedSIP-variable-periodic-schedule-retail-user) | 204 | Ozone sends a consent in an AwaitingAuthorisation state to the LFI after the consent/event/post endpoint is invoked. The operation should succeed with a status code 204. | PIS_Before_SIPVPS002 | paymentToTest: event-Authorized-for-CombinedSIP-variable-periodic-schedule-retail-user | POST /event/patch: Happy Path - Verify the successful creation of an event when the consentStatus is set to Authorized for a predefined combined SIP with variable periodic schedule (paymentToTest: event-Authorized-for-CombinedSIP-variable-periodic-schedule-retail-user) | 204 | Ozone sends a consent in an Authorized state to the LFI after the consent/event/post endpoint is invoked. The operation should succeed with a status code 204. | PIS_SIPVPS003 | paymentToTest: CombinedSIP-variable-periodic-schedule-for-retail-user | POST /payment: Happy Path - Verify All Mandatory and Optional Request Body Fields for Combined Single Instant Payment with Variable Periodic Schedule (paymentToTest: CombinedSIP-variable-periodic-schedule-for-retail-user) | 201 | The operation should succeed with a status code 201 if the payment is successfully created. | PIS_After_SIPVPS004 | paymentToTest: event-Consumed-for-CombinedSIP-variable-periodic-schedule-retail-user | POST /event/patch: Happy Path - VCombined Single Instant Payment with variable Periodic Schedule for Consent Status Consumed (paymentToTest: event-Consumed-for-CombinedSIP-variable-periodic-schedule-retail-user) | 204 | Ozone sends a consent in a Consumed state to the LFI after the consent/event/patch endpoint is invoked. The operation should succeed with a status code 204. | PIS_SIPVPS005 | paymentToTest: CombinedSIP-variable-periodic-schedule-for-retail-user | GET /payment: Happy Path - Verify Valid paymentId in Path Parameter Returns Payments for Combined Single Instant Payment with Variable Periodic Schedule (paymentToTest: CombinedSIP-variable-periodic-schedule-for-retail-user) | 200 | A valid paymentId provided in the path parameter should return a status code 200, and the paymentId must be present in the response. | PIS_SIPVPS006 | paymentToTest: variable-periodic-schedule | POST /event/patch: Negative Test - Verify that the endpoint throws error when mandatory fields are missing for Combined Single Instant Payment with Variable Periodic Schedule (paymentToTest: variable-periodic-schedule) | 400 | The operation should fail with a status code 400 when only optional request fields are provided. |
|
Back to top
International Payments
| Expand |
|---|
|
Test Scenario ID | Test ID | Dynamic Field | Test Name | Expected Response Code | Test Description |
|---|
IP_010_001 Single International Payments - positive and error scenarios The tests include consent event and action calls with respect to international payments | PIS_INVAL001 | paymentToTest: event-for-future-dated-payment-retail-user | POST /validate: Happy Path - Succeeds with a valid request containing mandatory and optional fields for a future-dated international payment with a consent status of 'AwaitingAuthorization' (paymentToTest: event-for-future-dated-payment-retail-user). | 200 | "The operation should return a status code of 200, indicating success, if the provided data is valid." | PIS_INVAL002 | paymentToTest: event-for-international-single-instant-payment-retail-user | POST /validate: Negative Test - Verify that the endpoint returns an error when the mandatory field CurrencyOfTransfer from the CurrencyRequest object is missing for a single instant international payment (paymentToTest: event-for-international-single-instant-payment-retail-user) | 400 | "The operation must return a status code of 400, indicating a bad request, if any mandatory field required is missing" | PIS_INVAL003 | paymentToTest: event-for-international-single-instant-payment-retail-user | POST /validate: Negative Test - Verify that the endpoint returns an error when the mandatory fields UnitCurrency and ExchangeRate from the CurrencyRequest.ExchangeRateInformation object are missing for a single instant international payment (paymentToTest: event-for-international-single-instant-payment-retail-user) | 400 | "The operation must return a status code of 400, indicating a bad request, if any mandatory field is missing" | PIS_INAUG004 | paymentToTest: event-for-international-single-instant-payment-retail-user | POST /augment: Happy Path - Succeeds with a valid request containing both mandatory and optional fields for a single instant international payment with a consent status of 'AwaitingAuthorization' (paymentToTest: event-for-international-single-instant-payment-retail-user) | 200 | "The operation must return a status code of 200, indicating success, if the provided data is valid." | PIS_INAUG005 | paymentToTest: event-for-international-future-dated-payment-retail-user | POST /augment: Negative Test - Verify that the endpoint returns an error when the mandatory field CurrencyOfTransfer from the CurrencyRequest object is missing for a future-dated international payment (paymentToTest: event-for-international-future-dated-payment-retail-user) | 400 | "The operation must return a status code of 400, indicating a bad request, if any mandatory field is missing" | PIS_INAUG006 | paymentToTest: event-for-international-future-dated-payment-retail-user | POST /augment: Negative Test - Verify that the endpoint returns an error when the mandatory fields UnitCurrency and ExchangeRate from the CurrencyRequest.ExchangeRateInformation object are missing (paymentToTest: event-for-international-future-dated-payment-retail-user) | 400 | "The operation must return a status code of 400, indicating a bad request, if any mandatory field is missing" | PIS_INEV007 | paymentToTest: event-for-international-single-instant-payment-retail-user | POST /event/post: Happy Path - Verify that an event is created when all mandatory request body fields are provided with a consent status of 'AwaitingAuthorization' for an international single instant payment from Currency AED to Currency A (paymentToTest: event-for-international-single-instant-payment-retail-user) | 204 | Ozone will send a consent in the AwaitingAuthorization state to the LFI after the consent/event/post endpoint is hit. | PIS_INEV008 | paymentToTest: event-for-international-single-instant-payment-retail-user | POST /event/patch: Happy Path - Verify all mandatory request body fields with consent status Authorized' for an international single instant payment from Currency AED to Currency A (paymentToTest: event-for-international-single-instant-payment-retail-user) | 204 | Ozone will send a consent in the AwaitingAuthorization state to the LFI after the consent/event/patch endpoint is hit. | PIS_INP009 | paymentToTest: event-for-international-single-instant-payment-retail-user | POST /payment: Happy Path - Verify that the payment is successfully made with all mandatory and optional request body fields for an international single instant payment are provided (paymentToTest: event-for-international-single-instant-payment-retail-user) | 201 | The operation must succeed with a status code 201 if the payment is created successfully. | PIS_INEV010 | paymentToTest: event-for-international-future-dated-payment-retail-user | POST /event/post: Happy Path - Verify all mandatory request body fields with consent status 'AwaitingAuthorization' for an international future-dated payment from Currency A to Currency B (paymentToTest: event-for-international-future-dated-payment-retail-user) | 204 | Ozone will send a consent in the AwaitingAuthorization state to the LFI after the consent/event/post endpoint is hit. | PIS_INEV011 | paymentToTest: event-for-international-future-dated-payment-retail-user | POST /event/patch: Happy Path - Verify all mandatory request body fields with consent status 'Authorized' for an international future-dated payment from Currency A to Currency B (paymentToTest: event-for-international-future-dated-payment-retail-user). | 204 | Ozone will send a consent in the AwaitingAuthorization state to the LFI after the consent/event/patch endpoint is hit. | PIS_INP012 | paymentToTest: event-for-international-future-dated-payment-retail-user | POST /payment: Happy Path - Verify that the payment is successfully made with all mandatory and optional request body fields for an international single instant payment are provided (paymentToTest: event-for-international-future-dated-payment-retail-user) | 201 | The operation must succeed with a status code 201 if the payment is created successfully. | IP_010_002 Muti-payment International - positive and error scenarios The tests include consent event calls with respect to international payments | PIS_INEV013 | paymentToTest: event-for-international-fixed-defined-schedule-retail-user | POST /event/post: Happy Path - Verify all mandatory request body fields with consent status 'AwaitingAuthorization' for an international fixed defined schedule from Currency A to AED (paymentToTest: event-for-international-fixed-defined-schedule-retail-user) | 204 | Ozone will send a consent in the AwaitingAuthorization state to the LFI after the consent/event/post endpoint is hit. | PIS_INEV014 | paymentToTest: event-for-international-fixed-defined-schedule-retail-user | POST /event/patch: Happy Path - Verify all mandatory request body fields with consent status 'Authorized' for an international fixed-defined schedule from Currency A to AED (paymentToTest: event-for-international-fixed-defined-schedule-retail-user) | 204 | Ozone will send a consent in the AwaitingAuthorization state to the LFI after the consent/event/patch endpoint is hit. | PIS_INP015 | paymentToTest: event-for-international-fixed-defined-schedule-retail-user | POST /payment: Happy Path - Verify that the payment is successfully made with all mandatory and optional request body fields for an international fixed defined schedule are provided (paymentToTest: event-for-international-fixed-defined-schedule-retail-user) | 201 | The operation must succeed with a status code 201 if the payment is created successfully. | IP_010_003 Combined payment International - positive and error scenarios The tests include consent event calls with respect to international payments | PIS_INEV016 | paymentToTest: event-for-international-CombinedSIP-fixed-defined-schedule-retail-user | POST /event/post: Happy Path - Verify all mandatory request body fields with consent status 'AwaitingAuthorization' for an international combined SIP with fixed defined schedule without ExchnageRateInformation object in CurrencyRequest (paymentToTest: event-for-international-CombinedSIP-fixed-defined-schedule-retail-user) | 204 | Ozone will send a consent in the AwaitingAuthorization state to the LFI after the consent/event/post endpoint is hit. | PIS_INEV017 | paymentToTest: event-for-international-CombinedSIP-fixed-defined-schedule-retail-user | POST /event/post: Happy Path - Verify all mandatory request body fields with consent status 'Authorized' for an international combined SIP with fixed defined schedule without ExchnageRateInformation object in CurrencyRequest (paymentToTest: event-for-international-CombinedSIP-fixed-defined-schedule-retail-user) | 204 | Ozone will send a consent in the Authorized state to the LFI after the consent/event/post endpoint is hit. | PIS_INP018 | paymentToTest: event-for-international-CombinedSIP-fixed-defined-schedule-retail-user | POST /payment: Happy Path - Verify that the payment is successfully made with all mandatory and optional request body fields for an international combined SIP with fixed defined schedule are provided (paymentToTest: event-for-international-CombinedSIP-fixed-defined-schedule-retail-user) | 201 | The operation must succeed with a status code 201 if the payment is created successfully. |
|
Back to top
GET /payment-consents/{consentId}/refund
| Expand |
|---|
|
| Test ID | Dynamic Field | Test Name | Expected Response Code | Test Description |
|---|
RFD_010_001 Ensure that the payment refund process for fixed-defined schedules operates correctly when a valid request is made. The tests include consent event and action calls with respect to refund process. | PIS_PRVAL001 | paymentToTest: event-Authorized-payment-refund-for-fixed-defined-schedule-retail-user | POST /validate : Happy Path - Succeeds with a valid request containing all the valid details for fixed-Defined-schedule (paymentToTest: event-Authorized-payment-refund-for-fixed-defined-schedule-retail-user) | 200 | The operation must succeed with a status code 200 if the data is valid. | PIS_PRAUG002 | paymentToTest: event-Authorized-payment-refund-for-fixed-defined-schedule-retail-user | POST /augment : Happy Path - Verify augmentation of additional information in consent for fixed-Defined-schedule (paymentToTest: event-Authorized-payment-refund-for-fixed-defined-schedule-retail-user) | 200 | The operation must succeed with a status code 200 if the data is valid. | Before_PREV003 | | POST /event/patch: Happy Path - Succeed if the event is successfully sent to notify that the consent is created in the Authorized state with an empty response body for fixed defined schedule | 204 | Ozone will successfully send an event to notify that the consent is created in the Authorized state with an empty response body (status code 204) after hitting the /event/post endpoint | PIS_PR004 | | GET /refund: Happy Path - Verify that the payment refund endpoint successfully returns a response when a valid consentId is provided | 200 | "Ensure that when a valid consentId is provided as a path parameter, the payment refund endpoint returns a 200 status code, and the response contains details of the debtor." | PIS_PR005 | | GET /refund: Happy Path - Verify that the payment refund endpoint successfully returns an empty response when an invalid consentId is provided | 200 | "Ensure that when an invalid consentId is provided as a path parameter, the payment refund endpoint returns a 200 status code, and the response contains an empty data object." | RFD_010_002 Ensure that the API returns error when consentId path param is missing | PIS_PR006 | | GET /refund: Negative Test - Verify that the payment refund endpoint fails when the consentId path parameter is missing | 400 | Ensure the endpoint fails with a 400 status code when the consentId path parameter is missing. | RFD_010_003 Ensure that the API correctly validates mandatory headers. | PIS_PR007 | | GET /refund : Negative Test - Mandatory header validation - Fail if o3-api-uri header is missing (paymentToTest: event-Authorized-payment-refund-for-fixed-defined-schedule-retail-user | 400 | The operation must fail with a status code 400 if the o3-api-uri header is missing | PIS_PR008 | paymentToTest: event-Authorized-payment-refund-for-fixed-defined-schedule-retail-user | GET /refund : Negative Test - Mandatory header validation - Fail if o3-psu-identifier header is missing (paymentToTest: event-Authorized-payment-refund-for-fixed-defined-schedule-retail-user) | 400 | The operation must fail with a status code 400 if the o3-psu-identifier header is missing | PIS_PR009 | paymentToTest: event-Authorized-payment-refund-for-fixed-defined-schedule-retail-user | GET /refund : Negative Test - Mandatory header validation - Fail if o3-api-operation header is missing (paymentToTest: event-Authorized-payment-refund-for-fixed-defined-schedule-retail-user) | 400 | TThe operation must fail with a status code 400 if the o3-api-operation header is missing | PIS_PR010 | paymentToTest: event-Authorized-payment-refund-for-fixed-defined-schedule-retail-user | GET /refund : Negative Test - Mandatory header validation - Fail if o3-aspsp-id header is missing (paymentToTest: event-Authorized-payment-refund-for-fixed-defined-schedule-retail-user) | 400 | The operation must fail with a status code 400 if the o3-aspsp-id header is missing | PIS_PR011 | paymentToTest: event-Authorized-payment-refund-for-fixed-defined-schedule-retail-user | GET /refund : Negative Test - Mandatory header validation - Fail if o3-ozone-interaction-id header is missing (paymentToTest: event-Authorized-payment-refund-for-fixed-defined-schedule-retail-user) | 400 | The operation must fail with a status code 400 if the o3-ozone-interaction-id header is missing | PIS_PR012 | paymentToTest: event-Authorized-payment-refund-for-fixed-defined-schedule-retail-user | GET /refund : Negative Test - Mandatory header validation - Fail if o3-provider-id header is missing (paymentToTest: event-Authorized-payment-refund-for-fixed-defined-schedule-retail-user) | 400 | The operation must fail with a status code 400 if the o3-provider-id header has an unexpected value | PIS_PR013 | paymentToTest: event-Authorized-payment-refund-for-fixed-defined-schedule-retail-user | GET /refund : Negative Test - Mandatory header validation - Fail if o3-caller-org-id header is missing (paymentToTest: event-Authorized-payment-refund-for-fixed-defined-schedule-retail-user) | 400 | The operation must fail with a status code 400 if the o3-caller-org-id header is missing | PIS_PR014 | paymentToTest: event-Authorized-payment-refund-for-fixed-defined-schedule-retail-user | GET /refund : Negative Test - Mandatory header validation - Fail if o3-caller-client-id header is missing (paymentToTest: event-Authorized-payment-refund-for-fixed-defined-schedule-retail-user) | 400 | The operation must fail with a status code 400 if the o3-caller-client-id header is missing | PIS_PR015 | paymentToTest: event-Authorized-payment-refund-for-fixed-defined-schedule-retail-user | GET /refund : Negative Test - Mandatory header validation - Fail if o3-caller-software-statement-id header is missing (paymentToTest: event-Authorized-payment-refund-for-fixed-defined-schedule-retail-user) | 400 | The operation must fail with a status code 400 if the o3-caller-software-statement-id header is missing | PIS_PR016 | paymentToTest: event-Authorized-payment-refund-for-fixed-defined-schedule-retail-user | GET /refund : Negative Test - Mandatory header validation - Fail if o3-consent-id header is missing (paymentToTest: event-Authorized-payment-refund-for-fixed-defined-schedule-retail-user) | 400 | The operation must fail with a status code 400 if the o3-consent-id header is missing | PIS_PR017 | paymentToTest: event-Authorized-payment-refund-for-fixed-defined-schedule-retail-user | GET /refund : Negative Test - Mandatory header validation - Fail if o3-caller-interaction-id header is missing (paymentToTest: event-Authorized-payment-refund-for-fixed-defined-schedule-retail-user) | 400 | The operation must fail with a status code 400 if the o3-caller-interaction-id header is missing |
|
Back to top
GET /payments/{paymentId}/report-file
| Expand |
|---|
|
Test Scenario ID | Test Case ID | Field to be updated in the config.yaml | Test Name | Expected Response Code | Test Description |
|---|
RPF_010_001 Ensure the API returns success response for a valid paymentId | PIS_RFP001 | paymentToTest: SamplePaymentId_ReportFile | GET : Happy Path - Succeeds if valid paymentId in path parameter returns file name (paymentToTest: SamplePaymentId_ReportFile) | 200 | Valid paymentId provided in the path parameter should return a 200 and the file name must be present in the response | RPF_010_002 Ensure the API returns error response for an invalid/missing paymentId | PIS_RFP002 | paymentToTest: InvalidPaymentId_ReportFile | GET : Negative Test - Invalid paymentId in path parameter (paymentToTest: InvalidPaymentId_ReportFile) | 400 | Invalid paymentId provided in the path parameter should return a 400 status code | PIS_RFP003 | paymentToTest: NoPaymentIds | GET : Negative Test - Fail if paymentId in path parameter is missing (paymentToTest: NoPaymentIds) | 400 | The paymentId in the path parameter is missing, should return a 400 status code |
|
Back to top
| Expand |
|---|
|
Test Scenario ID | Test Case ID | Field to be updated in the config.yaml | Test Name | Test Description |
|---|
PMT_H10_001 Ensure the POST / Payments API responds correctly for mandatory header validations | PIS_H_001 | paymentToTest : simple-cbuae-payment | POST : Negative Test - Mandatory header validation - Fail if o3-api-uri header is missing (paymentToTest : simple-cbuae-payment) | The operation must fail with a status code 400 if the o3-api-uri header is missing | PIS_H_002 | paymentToTest : simple-cbuae-payment | POST : Negative Test - Mandatory header validation - Fail if o3-api-operation header is missing (paymentToTest : simple-cbuae-payment) | TThe operation must fail with a status code 400 if the o3-api-operation header is missing | PIS_H_003 | paymentToTest : simple-cbuae-payment | POST : Negative Test - Mandatory header validation - Fail if o3-aspsp-id header is missing (paymentToTest : simple-cbuae-payment) | The operation must fail with a status code 400 if the o3-aspsp-id header is missing | PIS_H_004 | paymentToTest : simple-cbuae-payment | POST : Negative Test - Mandatory header validation - Fail if o3-ozone-interaction-id header is missing (paymentToTest : simple-cbuae-payment) | The operation must fail with a status code 400 if the o3-ozone-interaction-id header is missing | PIS_H_005 | paymentToTest : simple-cbuae-payment | POST : Negative Test - Mandatory header validation - Fail if o3-provider-id header is missing (paymentToTest : simple-cbuae-payment) | The operation must fail with a status code 400 if the o3-provider-id header has an unexpected value | PIS_H_006 | paymentToTest : simple-cbuae-payment | POST : Negative Test - Mandatory header validation - Fail if o3-caller-org-id header is missing (paymentToTest : simple-cbuae-payment) | The operation must fail with a status code 400 if the o3-caller-org-id header is missing | PIS_H_007 | paymentToTest : simple-cbuae-payment | POST : Negative Test - Mandatory header validation - Fail if o3-caller-client-id header is missing (paymentToTest : simple-cbuae-payment) | The operation must fail with a status code 400 if the o3-caller-client-id header is missing | PIS_H_008 | paymentToTest : simple-cbuae-payment | POST : Negative Test - Mandatory header validation - Fail if o3-caller-software-statement-id header is missing (paymentToTest : simple-cbuae-payment) | The operation must fail with a status code 400 if the o3-caller-software-statement-id header is missing | PIS_H_009 | paymentToTest : simple-cbuae-payment | POST : Negative Test - Mandatory header validation - Fail if o3-consent-id header is missing (paymentToTest : simple-cbuae-payment) | The operation must fail with a status code 400 if the o3-consent-id header is missing | PIS_H_010 | paymentToTest : simple-cbuae-payment | POST : Negative Test - Mandatory header validation - Fail if o3-psu-identifier header is missing (paymentToTest : simple-cbuae-payment) | The operation must fail with a status code 400 if the o3-psu-identifier header has an unexpected value | PIS_H_011 | paymentToTest : simple-cbuae-payment | POST : Negative Test - Mandatory header validation - Fail if o3-psu-identifier header is having invalid value (paymentToTest : simple-cbuae-payment) | The operation must fail with a status code 400 if the o3-psu-identifier header is having invalid value | PIS_H_012 | paymentToTest : simple-cbuae-payment | POST : Negative Test - Fails if o3-psu-identifier is not b64 encoded (paymentToTest : simple-cbuae-payment) | If o3-psu-identifier is not b64 encoded, the API must return a 400 and an error body | PIS_H_013 | paymentToTest : simple-cbuae-payment | POST : Negative Test - Fails if o3-psu-identifier does not evaluate to a json structure (paymentToTest : simple-cbuae-payment) | If o3-psu-identifier does not evaluate to a json structure, the API must return a 400 and an error body | PIS_H_014 | paymentToTest : simple-cbuae-payment | POST : Negative Test - Fails if o3-psu-identifier does not contain userId (paymentToTest : simple-cbuae-payment) | If o3-psu-identifier does not contain userId, the API must return a 400 and an error body | PIS_H_015 | paymentToTest : simple-cbuae-payment | POST : Negative Test - Fails if o3-psu-identifier header is invalid - the decoded value is valid JSON, but userId is null, empty or undefined (paymentToTest : simple-cbuae-payment) | If o3-psu-identifier header is invalid - the decoded value is valid JSON, but userId is null, empty or undefined, the API must return a 400 and an error body | PIS_H_016 | paymentToTest : simple-cbuae-payment | POST : Negative Test - Fails if o3-psu-identifier header is invalid - the decoded value is valid JSON, but userId is not a string (paymentToTest : simple-cbuae-payment) | If o3-psu-identifier header is invalid - the decoded value is valid JSON, but userId is not a string, the API must return a 400 and an error body | PIS_H_017 | paymentToTest : simple-cbuae-payment | GET : Negative Test - Fails if o3-caller-interaction-id header is missing (paymentToTest : simple-cbuae-payment) | If o3-caller-interaction-id header is missing, the API must return a 400 and an error body | PMT_H10_002 Ensure the GET /payments/{paymentId}/report-file API responds correctly for mandatory header validations | PIS_H_RFP001 | paymentToTest: SamplePaymentId_ReportFile | GET : Negative Test - Mandatory header validation - Fail if o3-psu-identifier header is missing (paymentToTest: SamplePaymentId_ReportFile) | The operation must fail with a status code 400 if the o3-psu-identifier header is missing | PIS_H_RFP002 | paymentToTest: SamplePaymentId_ReportFile | GET : Negative Test - Mandatory header validation - Fail if o3-api-uri header is missing (paymentToTest: SamplePaymentId_ReportFile) | The operation must fail with a status code 400 if the o3-api-uri header is missing | PIS_H_RFP003 | paymentToTest: SamplePaymentId_ReportFile | GET : Negative Test - Mandatory header validation - Fail if o3-api-operation header is missing (paymentToTest: SamplePaymentId_ReportFile) | TThe operation must fail with a status code 400 if the o3-api-operation header is missing | PIS_H_RFP004 | paymentToTest: SamplePaymentId_ReportFile | GET : Negative Test - Mandatory header validation - Fail if o3-aspsp-id header is missing (paymentToTest: SamplePaymentId_ReportFile) | The operation must fail with a status code 400 if the o3-aspsp-id header is missing | PIS_H_RFP005 | paymentToTest: SamplePaymentId_ReportFile | GET : Negative Test - Mandatory header validation - Fail if o3-ozone-interaction-id header is missing (paymentToTest: SamplePaymentId_ReportFile) | The operation must fail with a status code 400 if the o3-ozone-interaction-id header is missing | PIS_H_RFP006 | paymentToTest: SamplePaymentId_ReportFile | GET : Negative Test - Mandatory header validation - Fail if o3-provider-id header is missing (paymentToTest: SamplePaymentId_ReportFile) | The operation must fail with a status code 400 if the o3-provider-id header has an unexpected value | PIS_H_RFP007 | paymentToTest: SamplePaymentId_ReportFile | GET : Negative Test - Mandatory header validation - Fail if o3-caller-org-id header is missing (paymentToTest: SamplePaymentId_ReportFile) | The operation must fail with a status code 400 if the o3-caller-org-id header is missing | PIS_H_RFP008 | paymentToTest: SamplePaymentId_ReportFile | GET : Negative Test - Mandatory header validation - Fail if o3-caller-client-id header is missing (paymentToTest: SamplePaymentId_ReportFile) | The operation must fail with a status code 400 if the o3-caller-client-id header is missing | PIS_H_RFP009 | paymentToTest: SamplePaymentId_ReportFile | GET : Negative Test - Mandatory header validation - Fail if o3-caller-software-statement-id header is missing (paymentToTest: SamplePaymentId_ReportFile) | The operation must fail with a status code 400 if the o3-caller-software-statement-id header is missing | PIS_H_RFP010 | paymentToTest: SamplePaymentId_ReportFile | GET : Negative Test - Mandatory header validation - Fail if o3-consent-id header is missing (paymentToTest: SamplePaymentId_ReportFile) | The operation must fail with a status code 400 if the o3-consent-id header is missing | PIS_H_RFP020 | paymentToTest: SamplePaymentId_ReportFile | GET : Negative Test - Mandatory header validation - Fail if o3-psu-identifier header is having invalid value (paymentToTest: SamplePaymentId_ReportFile) | The operation must fail with a status code 400 if the o3-psu-identifier header is having invalid value | PIS_H_RFP021 | paymentToTest: SamplePaymentId_ReportFile | GET : Negative Test - Fails if o3-psu-identifier is not b64 encoded (paymentToTest: SamplePaymentId_ReportFile) | If o3-psu-identifier is not b64 encoded, the API must return a 400 and an error body | PIS_H_RFP022 | paymentToTest: SamplePaymentId_ReportFile | GET : Negative Test - Fails if o3-psu-identifier does not evaluate to a json structure (paymentToTest: SamplePaymentId_ReportFile) | If o3-psu-identifier does not evaluate to a json structure, the API must return a 400 and an error body | PIS_H_RFP023 | paymentToTest: SamplePaymentId_ReportFile | GET : Negative Test - Fails if o3-psu-identifier does not contain userId (paymentToTest: SamplePaymentId_ReportFile) | If o3-psu-identifier does not contain userId, the API must return a 400 and an error body | PIS_H_RFP024 | paymentToTest: SamplePaymentId_ReportFile | GET : Negative Test - Fails if o3-psu-identifier header is invalid - the decoded value is valid JSON, but userId is null, empty or undefined (paymentToTest: SamplePaymentId_ReportFile) | If o3-psu-identifier header is invalid - the decoded value is valid JSON, but userId is null, empty or undefined, the API must return a 400 and an error body | PIS_H_RFP025 | paymentToTest: SamplePaymentId_ReportFile | GET : Negative Test - Fails if o3-psu-identifier header is invalid - the decoded value is valid JSON, but userId is not a string (paymentToTest: SamplePaymentId_ReportFile) | If o3-psu-identifier header is invalid - the decoded value is valid JSON, but userId is not a string, the API must return a 400 and an error body | PIS_H_RFP026 | paymentToTest : simple-cbuae-payment | GET : Negative Test - Fails if o3-caller-interaction-id header is missing (paymentToTest : simple-cbuae-payment) | If o3-caller-interaction-id header is missing, the API must return a 400 and an error body |
|
Back to top
Consent Event Augment and Validate
POST /consent/action/augment
| Expand |
|---|
|
Test Scenario ID | Test Case ID | Field to be updated in the config.yaml | Test Name | Test Description |
|---|
AUG_010_001 Ensure consent action validate endpoint for fixedDefined-schedule payment request body behaves as expected for happy path and error scenarios | PIS_AUG001 | paymentToTest: event-AwaitingAuthorisation-for-fixed-defined-schedule-retail-user | POST /augment : Happy Path - Succeeds with a valid request containing only the mandatory fields for fixed-Defined-schedule (paymentToTest: event-AwaitingAuthorisation-for-fixed-defined-schedule-retail-user) | The operation must succeed with a status code 200 if the data is valid. | PIS_AUG002 | paymentToTest: event-AwaitingAuthorisation-for-fixed-defined-schedule-retail-user | POST /augment : Happy Path - Succeeds with a valid request containing both mandatory and optional fields for fixed-Defined-schedule (paymentToTest: event-AwaitingAuthorisation-for-fixed-defined-schedule-retail-user) | The operation must succeed with a status code 200 if the data is valid. | PIS_AUG003 | paymentToTest: event-AwaitingAuthorisation-for-fixed-defined-schedule-retail-user | POST /augment : Verify that the endpoint throws error when mandatory fields are missing for fixed-Defined-schedule (paymentToTest: event-AwaitingAuthorisation-for-fixed-defined-schedule-retail-user) | The operation must fail with a status code 400 due to invalid data. | AUG_010_002 Ensure consent action validate endpoint for varaibleDefinedSchedule payment request body behaves as expected for happy path and error scenarios | PIS_AUG004 | paymentToTest: event-AwaitingAuthorisation-for-variable-defined-schedule-retail-user | POST /augment : Happy Path - Succeeds with a valid request containing only the mandatory fields for variable-Defined-schedule (paymentToTest: event-AwaitingAuthorisation-for-variable-defined-schedule-retail-user) | The operation must succeed with a status code 200 if the data is valid. | PIS_AUG005 | paymentToTest: event-AwaitingAuthorisation-for-variable-defined-schedule-retail-user | POST /augment : Happy Path - Succeeds with a valid request containing both mandatory and optional fields for variable-Defined-schedule (paymentToTest: event-AwaitingAuthorisation-for-variable-defined-schedule-retail-user) | The operation must succeed with a status code 200 if the data is valid. | PIS_AUG006 | paymentToTest: event-AwaitingAuthorisation-for-variable-defined-schedule-retail-user | POST /augment : Verify that the endpoint throws error when mandatory fields are missing for variable-Defined-schedule (paymentToTest: event-AwaitingAuthorisation-for-variable-defined-schedule-retail-user) | The operation must fail with a status code 400 due to invalid data. | AUG_010_003 Ensure consent action validate endpoint for fixedPeriodicSchedule payment request body behaves as expected for happy path and error scenarios | PIS_AUG007 | paymentToTest: event-AwaitingAuthorisation-for-fixed-periodic-schedule-retail-user | POST /augment : Happy Path - Succeeds with a valid request containing only the mandatory fields for fixed-periodic-schedule (paymentToTest: event-AwaitingAuthorisation-for-fixed-periodic-schedule-retail-user) | The operation must succeed with a status code 200 if the data is valid. | PIS_AUG008 | paymentToTest: event-AwaitingAuthorisation-for-fixed-periodic-schedule-retail-user | POST /augment : Happy Path - Succeeds with a valid request containing both mandatory and optional fields for fixed-periodic-schedule (paymentToTest: event-AwaitingAuthorisation-for-fixed-periodic-schedule-retail-user) | The operation must succeed with a status code 200 if the data is valid. | PIS_AUG009 | paymentToTest: event-AwaitingAuthorisation-for-fixed-periodic-schedule-retail-user | POST /augment : Verify that the endpoint throws error when mandatory fields are missing for fixed-periodic-schedule (paymentToTest: event-AwaitingAuthorisation-for-fixed-periodic-schedule-retail-user) | The operation must fail with a status code 400 due to invalid data. | AUG_010_004 Ensure consent action validate endpoint for variablePeriodicSchedule payment request body behaves as expected for happy path and error scenarios | PIS_AUG010 | paymentToTest: event-AwaitingAuthorisation-for-variable-periodic-schedule-retail-user | POST /augment : Happy Path - Succeeds with a valid request containing only the mandatory fields for variable-periodic-schedule (paymentToTest: event-AwaitingAuthorisation-for-variable-periodic-schedule-retail-user) | The operation must succeed with a status code 200 if the data is valid. | PIS_AUG011 | paymentToTest: event-AwaitingAuthorisation-for-variable-periodic-schedule-retail-user | POST /augment : Happy Path - Succeeds with a valid request containing both mandatory and optional fields for variable-periodic-schedule (paymentToTest: event-AwaitingAuthorisation-for-variable-periodic-schedule-retail-user) | The operation must succeed with a status code 200 if the data is valid. | PIS_AUG012 | paymentToTest: event-AwaitingAuthorisation-for-variable-periodic-schedule-retail-user | POST /augment : Verify that the endpoint throws error when mandatory fields are missing for variable-periodic-schedule (paymentToTest: event-AwaitingAuthorisation-for-variable-periodic-schedule-retail-user) | The operation must fail with a status code 400 due to invalid data. | AUG_010_005 Ensure consent action validate endpoint for fixedOnDemand payment request body behaves as expected for happy path and error scenarios | PIS_AUG013 | paymentToTest: event-AwaitingAuthorisation-for-fixed-on-demand-retail-user | POST /augment : Happy Path - Succeeds with a valid request containing only the mandatory fields for fixed-on-demand (paymentToTest: event-AwaitingAuthorisation-for-fixed-on-demand-retail-user) | The operation must succeed with a status code 200 if the data is valid. | PIS_AUG014 | paymentToTest: event-AwaitingAuthorisation-for-fixed-on-demand-retail-user | POST /augment : Happy Path - Succeeds with a valid request containing both mandatory and optional fields for fixed-on-demand (paymentToTest: event-AwaitingAuthorisation-for-fixed-on-demand-retail-user) | The operation must succeed with a status code 200 if the data is valid. | PIS_AUG015 | paymentToTest: event-AwaitingAuthorisation-for-fixed-on-demand-retail-user | POST /augment : Verify that the endpoint throws error when mandatory fields are missing for fixed-on-demand (paymentToTest: event-AwaitingAuthorisation-for-fixed-on-demand-retail-user) | The operation must fail with a status code 400 due to invalid data. | AUG_010_006 Ensure consent action validate endpoint for variableOnDemand payment request body behaves as expected for happy path and error scenarios | PIS_AUG016 | paymentToTest: event-AwaitingAuthorisation-for-variable-on-demand-retail-user | POST /augment : Happy Path - Succeeds with a valid request containing only the mandatory fields for variable-on-demand (paymentToTest: event-AwaitingAuthorisation-for-variable-on-demand-retail-user) | The operation must succeed with a status code 200 if the data is valid. | PIS_AUG017 | paymentToTest: event-AwaitingAuthorisation-for-variable-on-demand-retail-user | POST /augment : Happy Path - Succeeds with a valid request containing both mandatory and optional fields for variable-on-demand (paymentToTest: event-AwaitingAuthorisation-for-variable-on-demand-retail-user) | The operation must succeed with a status code 200 if the data is valid. | PIS_AUG018 | paymentToTest: event-AwaitingAuthorisation-for-variable-on-demand-retail-user | POST /augment : Verify that the endpoint throws error when mandatory fields are missing for variable-on-demand (paymentToTest: event-AwaitingAuthorisation-for-variable-on-demand-retail-user) | The operation must fail with a status code 400 due to invalid data. | AUG_010_007 Ensure consent action validate endpoint for combined payment request body behaves as expected os | PIS_AUG019 | paymentToTest: event-AwaitingAuthorisation-for-CombinedFDP-fixed-defined-schedule-retail-user | POST /augment : Happy Path - Succeeds with a valid request containing both mandatory and optional fields for combined FDP with fixed-Defined-schedule (paymentToTest: event-AwaitingAuthorisation-for-CombinedFDP-fixed-defined-schedule-retail-user) | The operation must succeed with a status code 200 if the data is valid. | PIS_AUG020 | paymentToTest: event-AwaitingAuthorisation-for-CombinedFDP-variable-defined-schedule-retail-user | POST /augment : Happy Path - Succeeds with a valid request containing both mandatory and optional fields for combined FDP with variable-Defined-schedule (paymentToTest: event-AwaitingAuthorisation-for-CombinedFDP-variable-defined-schedule-retail-user) | The operation must succeed with a status code 200 if the data is valid. | PIS_AUG021 | paymentToTest: event-AwaitingAuthorisation-for-CombinedFDP-fixed-periodic-schedule-retail-user | POST /augment : Happy Path - Succeeds with a valid request containing both mandatory and optional fields for combined FDP with fixed-periodic-schedule (paymentToTest: event-AwaitingAuthorisation-for-CombinedFDP-fixed-periodic-schedule-retail-user) | The operation must succeed with a status code 200 if the data is valid. | PIS_AUG022 | paymentToTest: event-AwaitingAuthorisation-for-CombinedFDP-variable-periodic-schedule-retail-user | POST /augment : Happy Path - Succeeds with a valid request containing both mandatory and optional fields for combined FDP with variable-periodic-schedule (paymentToTest: event-AwaitingAuthorisation-for-CombinedFDP-variable-periodic-schedule-retail-user) | The operation must succeed with a status code 200 if the data is valid. | PIS_AUG023 | paymentToTest: event-Authorized-for-CombinedFDP-fixed-on-demand-retail-user | POST /augment : Happy Path - Succeeds with a valid request containing both mandatory and optional fields for combined FDP with fixed-on-demand (paymentToTest: event-Authorized-for-CombinedFDP-fixed-on-demand-retail-user) | The operation must succeed with a status code 200 if the data is valid. | PIS_AUG024 | paymentToTest: event-AwaitingAuthorisation-for-CombinedFDP-variable-on-demand-retail-user | POST /augment : Happy Path -Succeeds with a valid request containing both mandatory and optional fields for combined FDP with variable-on-demand (paymentToTest: event-AwaitingAuthorisation-for-CombinedFDP-variable-on-demand-retail-user) | The operation must succeed with a status code 200 if the data is valid. | PIS_AUG025 | paymentToTest: event-AwaitingAuthorisation-for-CombinedSIP-fixed-defined-schedule-retail-user | POST /augment : Happy Path - Succeeds with a valid request containing both mandatory and optional fields for combined SIP with fixed-Defined-schedule (paymentToTest: event-AwaitingAuthorisation-for-CombinedSIP-fixed-defined-schedule-retail-user) | The operation must succeed with a status code 200 if the data is valid. | PIS_AUG026 | paymentToTest: event-AwaitingAuthorisation-for-CombinedSIP-variable-defined-schedule-retail-user | POST /augment : Happy Path - Succeeds with a valid request containing both mandatory and optional fields for combined SIP with variable-Defined-schedule (paymentToTest: event-AwaitingAuthorisation-for-CombinedSIP-variable-defined-schedule-retail-user) | The operation must succeed with a status code 200 if the data is valid. | PIS_AUG027 | paymentToTest: event-AwaitingAuthorisation-for-CombinedSIP-fixed-periodic-schedule-retail-user | POST /augment : Happy Path - Succeeds with a valid request containing both mandatory and optional fields for combined SIP with fixed-periodic-schedule (paymentToTest: event-AwaitingAuthorisation-for-CombinedSIP-fixed-periodic-schedule-retail-user) | The operation must succeed with a status code 200 if the data is valid. | PIS_AUG028 | paymentToTest: event-AwaitingAuthorisation-for-CombinedSIP-variable-periodic-schedule-retail-user | POST /augment : Happy Path - Succeeds with a valid request containing both mandatory and optional fields for combined SIP with variable-periodic-schedule (paymentToTest: event-AwaitingAuthorisation-for-CombinedSIP-variable-periodic-schedule-retail-user) | The operation must succeed with a status code 200 if the data is valid. | PIS_AUG029 | paymentToTest: event-Authorized-for-CombinedSIP-fixed-on-demand-retail-user | POST /augment : Happy Path - Succeeds with a valid request containing both mandatory and optional fields for combined SIP with fixed-on-demand (paymentToTest: event-Authorized-for-CombinedSIP-fixed-on-demand-retail-user) | The operation must succeed with a status code 200 if the data is valid. | PIS_AUG030 | paymentToTest: event-AwaitingAuthorisation-for-CombinedSIP-variable-on-demand-retail-user | POST /augment : Happy Path - Succeeds with a valid request containing both mandatory and optional fields for combined SIP with variable-on-demand (paymentToTest: event-AwaitingAuthorisation-for-CombinedSIP-variable-on-demand-retail-user) | The operation must succeed with a status code 200 if the data is valid. |
|
Back to top
POST /consent/action/validate
| Expand |
|---|
|
Test Scenario ID | Test Case ID | Field to be updated in the config.yaml | Test Name | | Test Description |
|---|
VAL_010_001 Ensure consent action validate endpoint for fixedDefined-schedule payment request body behaves as expected for happy path and error scenarios | PIS_VAL001 | paymentToTest: event-AwaitingAuthorisation-for-fixed-defined-schedule-retail-user | POST /validate : Happy Path - Succeeds with a valid request containing only the mandatory fields for fixed-Defined-schedule (paymentToTest: event-AwaitingAuthorisation-for-fixed-defined-schedule-retail-user) | 200 | The operation must succeed with a status code 200 if the data is valid. | PIS_VAL002 | paymentToTest: event-AwaitingAuthorisation-for-fixed-defined-schedule-retail-user | POST /validate : Happy Path - Succeeds with a valid request containing both mandatory and optional fields for fixed-Defined-schedule (paymentToTest: event-AwaitingAuthorisation-for-fixed-defined-schedule-retail-user) | 200 | The operation must succeed with a status code 200 if the data is valid. | PIS_VAL003 | paymentToTest: event-AwaitingAuthorisation-for-fixed-defined-schedule-retail-user | POST /validate : Verify that the endpoint throws error when mandatory fields are missing for fixed-Defined-schedule (paymentToTest: event-AwaitingAuthorisation-for-fixed-defined-schedule-retail-user) | 400 | The operation must fail with a status code 400 due to invalid data. | VAL_010_002 Ensure consent action validate endpoint for varaibleDefinedSchedule payment request body behaves as expected for happy path and error scenarios | PIS_VAL004 | paymentToTest: event-AwaitingAuthorisation-for-variable-defined-schedule-retail-user | POST /validate : Happy Path - Succeeds with a valid request containing only the mandatory fields for variable-Defined-schedule (paymentToTest: event-AwaitingAuthorisation-for-variable-defined-schedule-retail-user) | 200 | The operation must succeed with a status code 200 if the data is valid. | PIS_VAL005 | paymentToTest: event-AwaitingAuthorisation-for-variable-defined-schedule-retail-user | POST /validate : Happy Path - Succeeds with a valid request containing both mandatory and optional fields for variable-Defined-schedule (paymentToTest: event-AwaitingAuthorisation-for-variable-defined-schedule-retail-user) | 200 | The operation must succeed with a status code 200 if the data is valid. | PIS_VAL006 | paymentToTest: event-AwaitingAuthorisation-for-variable-defined-schedule-retail-user | POST /validate : Verify that the endpoint throws error when mandatory fields are missing for variable-Defined-schedule (paymentToTest: event-AwaitingAuthorisation-for-variable-defined-schedule-retail-user) | 400 | The operation must fail with a status code 400 due to invalid data. | VAL_010_003 Ensure consent action validate endpoint for fixedPeriodicSchedule payment request body behaves as expected for happy path and error scenarios | PIS_VAL007 | paymentToTest: event-AwaitingAuthorisation-for-fixed-periodic-schedule-retail-user | POST /validate : Happy Path - Succeeds with a valid request containing only the mandatory fields for fixed-periodic-schedule (paymentToTest: event-AwaitingAuthorisation-for-fixed-periodic-schedule-retail-user) | 200 | The operation must succeed with a status code 200 if the data is valid. | PIS_VAL008 | paymentToTest: event-AwaitingAuthorisation-for-fixed-periodic-schedule-retail-user | POST /validate : Happy Path - Succeeds with a valid request containing both mandatory and optional fields for fixed-periodic-schedule (paymentToTest: event-AwaitingAuthorisation-for-fixed-periodic-schedule-retail-user) | 200 | The operation must succeed with a status code 200 if the data is valid. | PIS_VAL009 | paymentToTest: event-AwaitingAuthorisation-for-fixed-periodic-schedule-retail-user | POST /validate : Verify that the endpoint throws error when mandatory fields are missing for fixed-periodic-schedule (paymentToTest: event-AwaitingAuthorisation-for-fixed-periodic-schedule-retail-user) | 400 | The operation must fail with a status code 400 due to invalid data. | VAL_010_004 Ensure consent action validate endpoint for variablePeriodicSchedule payment request body behaves as expected for happy path and error scenarios | PIS_VAL010 | paymentToTest: event-AwaitingAuthorisation-for-variable-periodic-schedule-retail-user | POST /validate : Happy Path - Succeeds with a valid request containing only the mandatory fields for variable-periodic-schedule (paymentToTest: event-AwaitingAuthorisation-for-variable-periodic-schedule-retail-user) | 200 | The operation must succeed with a status code 200 if the data is valid. | PIS_VAL011 | paymentToTest: event-AwaitingAuthorisation-for-variable-periodic-schedule-retail-user | POST /validate : Happy Path - Succeeds with a valid request containing both mandatory and optional fields for variable-periodic-schedule (paymentToTest: event-AwaitingAuthorisation-for-variable-periodic-schedule-retail-user) | 200 | The operation must succeed with a status code 200 if the data is valid. | PIS_VAL012 | paymentToTest: event-AwaitingAuthorisation-for-variable-periodic-schedule-retail-user | POST /validate : Verify that the endpoint throws error when mandatory fields are missing for variable-periodic-schedule (paymentToTest: event-AwaitingAuthorisation-for-variable-periodic-schedule-retail-user) | 400 | The operation must fail with a status code 400 due to invalid data. | VAL_010_005 Ensure consent action validate endpoint for fixedOnDemand payment request body behaves as expected for happy path and error scenarios | PIS_VAL013 | paymentToTest: event-AwaitingAuthorisation-for-fixed-on-demand-retail-user | POST /validate : Happy Path - Succeeds with a valid request containing only the mandatory fields for fixed-on-demand (paymentToTest: event-AwaitingAuthorisation-for-fixed-on-demand-retail-user) | 200 | The operation must succeed with a status code 200 if the data is valid. | PIS_VAL014 | paymentToTest: event-AwaitingAuthorisation-for-fixed-on-demand-retail-user | POST /validate : Happy Path - Succeeds with a valid request containing both mandatory and optional fields for fixed-on-demand (paymentToTest: event-AwaitingAuthorisation-for-fixed-on-demand-retail-user) | 200 | The operation must succeed with a status code 200 if the data is valid. | PIS_VAL015 | paymentToTest: event-AwaitingAuthorisation-for-fixed-on-demand-retail-user | POST /validate : Verify that the endpoint throws error when mandatory fields are missing for fixed-on-demand (paymentToTest: event-AwaitingAuthorisation-for-fixed-on-demand-retail-user) | 400 | The operation must fail with a status code 400 due to invalid data. | VAL_010_006 Ensure consent action validate endpoint for variableOnDemand payment request body behaves as expected for happy path and error scenarios | PIS_VAL016 | paymentToTest: event-AwaitingAuthorisation-for-variable-on-demand-retail-user | POST /validate : Happy Path - Succeeds with a valid request containing only the mandatory fields for variable-on-demand (paymentToTest: event-AwaitingAuthorisation-for-variable-on-demand-retail-user) | 200 | The operation must succeed with a status code 200 if the data is valid. | PIS_VAL017 | paymentToTest: event-AwaitingAuthorisation-for-variable-on-demand-retail-user | POST /validate : Happy Path - Succeeds with a valid request containing both mandatory and optional fields for variable-on-demand (paymentToTest: event-AwaitingAuthorisation-for-variable-on-demand-retail-user) | 200 | The operation must succeed with a status code 200 if the data is valid. | PIS_VAL018 | paymentToTest: event-AwaitingAuthorisation-for-variable-on-demand-retail-user | POST /validate : Verify that the endpoint throws error when mandatory fields are missing for variable-on-demand (paymentToTest: event-AwaitingAuthorisation-for-variable-on-demand-retail-user) | 400 | The operation must fail with a status code 400 due to invalid data. | VAL_010_007 Ensure consent action validate endpoint for combined payment request body behaves as expected os | PIS_VAL019 | paymentToTest: event-AwaitingAuthorisation-for-CombinedFDP-fixed-defined-schedule-retail-user | POST /validate : Happy Path - Succeeds with a valid request containing both mandatory and optional fields for combined FDP with fixed-Defined-schedule (paymentToTest: event-AwaitingAuthorisation-for-CombinedFDP-fixed-defined-schedule-retail-user) | 200 | The operation must succeed with a status code 200 if the data is valid. | PIS_VAL020 | paymentToTest: event-AwaitingAuthorisation-for-CombinedFDP-variable-defined-schedule-retail-user | POST /validate : Happy Path - Succeeds with a valid request containing both mandatory and optional fields for combined FDP with variable-Defined-schedule (paymentToTest: event-AwaitingAuthorisation-for-CombinedFDP-variable-defined-schedule-retail-user) | 200 | The operation must succeed with a status code 200 if the data is valid. | PIS_VAL021 | paymentToTest: event-AwaitingAuthorisation-for-CombinedFDP-fixed-periodic-schedule-retail-user | POST /validate : Happy Path - Succeeds with a valid request containing both mandatory and optional fields for combined FDP with fixed-periodic-schedule (paymentToTest: event-AwaitingAuthorisation-for-CombinedFDP-fixed-periodic-schedule-retail-user) | 200 | The operation must succeed with a status code 200 if the data is valid. | PIS_VAL022 | paymentToTest: event-AwaitingAuthorisation-for-CombinedFDP-variable-periodic-schedule-retail-user | POST /validate : Happy Path - Succeeds with a valid request containing both mandatory and optional fields for combined FDP with variable-periodic-schedule (paymentToTest: event-AwaitingAuthorisation-for-CombinedFDP-variable-periodic-schedule-retail-user) | 200 | The operation must succeed with a status code 200 if the data is valid. | PIS_VAL023 | paymentToTest: event-Authorized-for-CombinedFDP-fixed-on-demand-retail-user | POST /validate : Happy Path - Succeeds with a valid request containing both mandatory and optional fields for combined FDP with fixed-on-demand (paymentToTest: event-Authorized-for-CombinedFDP-fixed-on-demand-retail-user) | 200 | The operation must succeed with a status code 200 if the data is valid. | PIS_VAL024 | paymentToTest: event-AwaitingAuthorisation-for-CombinedFDP-variable-on-demand-retail-user | POST /validate : Happy Path -Succeeds with a valid request containing both mandatory and optional fields for combined FDP with variable-on-demand (paymentToTest: event-AwaitingAuthorisation-for-CombinedFDP-variable-on-demand-retail-user) | 200 | The operation must succeed with a status code 200 if the data is valid. | PIS_VAL025 | paymentToTest: event-AwaitingAuthorisation-for-CombinedSIP-fixed-defined-schedule-retail-user | POST /validate : Happy Path - Succeeds with a valid request containing both mandatory and optional fields for combined SIP with fixed-Defined-schedule (paymentToTest: event-AwaitingAuthorisation-for-CombinedSIP-fixed-defined-schedule-retail-user) | 200 | The operation must succeed with a status code 200 if the data is valid. | PIS_VAL026 | paymentToTest: event-AwaitingAuthorisation-for-CombinedSIP-variable-defined-schedule-retail-user | POST /validate : Happy Path - Succeeds with a valid request containing both mandatory and optional fields for combined SIP with variable-Defined-schedule (paymentToTest: event-AwaitingAuthorisation-for-CombinedSIP-variable-defined-schedule-retail-user) | 200 | The operation must succeed with a status code 200 if the data is valid. | PIS_VAL027 | paymentToTest: event-AwaitingAuthorisation-for-CombinedSIP-fixed-periodic-schedule-retail-user | POST /validate : Happy Path - Succeeds with a valid request containing both mandatory and optional fields for combined SIP with fixed-periodic-schedule (paymentToTest: event-AwaitingAuthorisation-for-CombinedSIP-fixed-periodic-schedule-retail-user) | 200 | The operation must succeed with a status code 200 if the data is valid. | PIS_VAL028 | paymentToTest: event-AwaitingAuthorisation-for-CombinedSIP-variable-periodic-schedule-retail-user | POST /validate : Happy Path - Succeeds with a valid request containing both mandatory and optional fields for combined SIP with variable-periodic-schedule (paymentToTest: event-AwaitingAuthorisation-for-CombinedSIP-variable-periodic-schedule-retail-user) | 200 | The operation must succeed with a status code 200 if the data is valid. | PIS_VAL029 | paymentToTest: event-Authorized-for-CombinedSIP-fixed-on-demand-retail-user | POST /validate : Happy Path - Succeeds with a valid request containing both mandatory and optional fields for combined SIP with fixed-on-demand (paymentToTest: event-Authorized-for-CombinedSIP-fixed-on-demand-retail-user) | 200 | The operation must succeed with a status code 200 if the data is valid. | PIS_VAL030 | paymentToTest: event-AwaitingAuthorisation-for-CombinedSIP-variable-on-demand-retail-user | POST /validate : Happy Path - Succeeds with a valid request containing both mandatory and optional fields for combined SIP with variable-on-demand (paymentToTest: event-AwaitingAuthorisation-for-CombinedSIP-variable-on-demand-retail-user) | 200 | The operation must succeed with a status code 200 if the data is valid. |
|
Back to top
Insurance Data Sharing
| Expand |
|---|
|
Test Scenario ID | Test ID | Dynamic Field | Test Name | Expected Response Code | Test Description |
|---|
INS_010_001 Ensure the API returns success response for GET /motor-insurance-policies/{InsurancePolicyId}/customer-payment-details The tests also also cover consent action and even calls related to the insurance payment details | INS_VAL001 | insuranceToTest: event_insurance-AwaitingAuthorization-all-permissions | "POST /validate : Happy Path : Success when consent data is valid, allowing creation of consent in the AwaitingAuthorization state for a insurance data sharing(insuranceToTest: event_insurance-AwaitingAuthorization-all-permissions)" | 200 | The operation must succeed with a status code 200 if the consent data is valid | INS_AUG002 | insuranceToTest: event_insurance-AwaitingAuthorization-all-permissions | POST /augment: Happy Path - Success when the augment endpoint is invoked for an insurance consent in AwaitingAuthorisation state (insuranceToTest: event_insurance-AwaitingAuthorization-all-permissions) | 200 | TThe operation should succeed with a status code 200 if the response contains the necessary fields to augment the consent | INS_EV003 | insuranceToTest: event_insurance-AwaitingAuthorization-all-permissions | POST /event/post: Happy Path - Succeed if the event is successfully sent to notify that the consent is created in the AwaitingAuthorisation state with an empty response body for a insurance data sharing(insuranceToTest: event_insurance-AwaitingAuthorization-all-permissions) | 204 | Ozone will successfully send an event to notify that the consent is created in the AwaitingAuthorisation state with an empty response body (status code 204) after hitting the /event/post endpoint. | INS_EV004 | insuranceToTest: event_insurance-Authorized-all-permissions | POST /event/patch: Happy Path - Succeed if the event is successfully sent to notify that the consent is created in the Authorized state with an empty response body for a insurance data sharing (insuranceToTest: event_insurance-Authorized-all-permissions) | 204 | Ozone will successfully send an event to notify that the consent is created in the Authorized state with an empty response body (status code 204) after hitting the /event/patch endpoint | INS_005 | insuranceToTest: valid_insurancePolicyId-all-permissions | GET /motor-insurance-policies/{InsurancePolicyId}/customer-payment-details : Happy Path : Succeeds if a valid insurance policy ID is provided and returns the correct customer payment details (insuranceToTest: valid_insurancePolicyId-all-permissions) | 200 | The endpoints returns a status code of 200 and the correct customer payment details when a valid InsurancePolicyId is provided in the request path | INS_010_002 Ensure the API returns error response for GET /motor-insurance-policies/{InsurancePolicyId}/customer-payment-details with an invalid insurancePolicyId | INS_006 | insuranceToTest: Invalid-insurancePolicyId-all-permissions | "GET /motor-insurance-policies/{InsurancePolicyId}/customer-payment-details: Negative Test - Returns an error response if a invalid InsurancePolicyId, with a length greater than 128 characters, is provided in the path (insuranceToTest: Invalid-insurancePolicyId-all-permissions)" | 400 | Returns a status code of 400 with the appropriate error details for an invalid InsuranceId with a length greater than the maximum specified | INS_007 | insuranceToTest: no-insurancePolicyId-all-permissions | GET /motor-insurance-policies/{InsurancePolicyId}/customer-payment-details: Negative Test - Returns an error response if a InsurancePolicyId path parameter is missing (insuranceToTest: no-insurancePolicyId-all-permissions) | 400 | Returns a status code of 400 for a missing insurance policy ID as path parameter | INS_010_003 Ensure API returns error mandatory fields are missing for consent event patch related to customer payment details | INS_EV008 | insuranceToTest: event_insurance-AwaitingAuthorization-all-permissions | POST event/patch: Negative Test - Verify that the endpoint throws error when mandatory fields are missing for insurance data sharing (insuranceToTest: event_insurance-AwaitingAuthorization-all-permissions) | 400 | The endpoint responds with a 400 status code when mandatory fields are missing from the request payload | INS_010_004 Ensure the API returns success response for GET /motor-insurance-policies | INS_009 | | GET /motor-insurance-policies: Happy Path - Succeeds if the list of insurance policies for a valid o3-consent-id provided in the header | 200 | "The request returns a status code of 200, and the data object should be an array containing the list of insurance policies corresponding to the provided o3-consent-id in the header" | INS_010_005 Ensure the API returns error response for GET /motor-insurance-policies when page and page-size are missing | INS_010 | | GET /motor-insurance-policies: Negative Test - Verify the endpoint throws an error if the page and page-size query parameters are missing | 400 | The request returns a status code of 400 with the appropriate error details when the page and page-size query parameters are missing | INS_010_006 Ensure the API returns success response for GET /motor-insurance-policies/{InsurancePolicyId} | INS_011 | insuranceToTest: valid_insurancePolicyId-all-permissions | GET /motor-insurance-policies/{InsurancePolicyId} : Happy Path : Succeeds if a valid insurance policy ID as path parameter is provided (insuranceToTest: valid_insurancePolicyId-all-permissions) | 200 | The endpoints returns a status code of 200 when a valid InsurancePolicyId is provided in the request path | INS_010_007 Ensure the API returns error response for GET /motor-insurance-policies/{InsurancePolicyId} for an invalid InsurancePolicyId | INS_012 | insuranceToTest: Invalid-insurancePolicyId-all-permissions | "GET /motor-insurance-policies/{InsurancePolicyId}: Negative Test - Returns an error response if a invalid InsurancePolicyId, with a length greater than 128 characters, is provided in the path (insuranceToTest: Invalid-insurancePolicyId-all-permissions)" | 400 | Returns a status code of 400 with the appropriate error details for an invalid InsuranceId with a length greater than the maximum specified | INS_010_008 Ensure the API returns error response for GET /motor-insurance-policies/{InsurancePolicyId} for a missing InsurancePolicyId | INS_013 | insuranceToTest: no-insurancePolicyId-all-permissions | GET /motor-insurance-policies/{InsurancePolicyId}: Negative Test - Returns an error response if a InsurancePolicyId path parameter is missing (insuranceToTest: no-insurancePolicyId-all-permissions) | 400 | Returns a status code of 400 for a missing insurance policy ID as path parameter | INS_010_009 Ensure the API returns error for missing / invalid mandatory field validations | INS_014 | | GET /motor-insurance-policies/{InsurancePolicyId}/customer-payment-details : Negative Test - Mandatory header validation - Fail if o3-ozone-interaction-id header is missing (insuranceToTest: valid_insurancePolicyId-all-permissions | 400 | The operation must fail with a status code 400 if the o3-ozone-interaction-id header is missing | INS_015 | insuranceToTest: valid_insurancePolicyId-all-permissions | GET /motor-insurance-policies/{InsurancePolicyId}/customer-payment-details : Negative Test - Mandatory header validation - Fail if o3-consent-id header is missing (insuranceToTest: valid_insurancePolicyId-all-permissions) | 400 | The operation must fail with a status code 400 if the o3-consent-id header is missing | INS_016 | insuranceToTest: valid_insurancePolicyId-all-permissions | GET /motor-insurance-policies/{InsurancePolicyId}/customer-payment-details : Negative Test - Mandatory header validation - Fail if o3-caller-interaction-id header is missing (insuranceToTest: valid_insurancePolicyId-all-permissions) | 400 | TThe operation must fail with a status code 400 if the o3-caller-interaction-id header is missing | INS_017 | insuranceToTest: valid_insurancePolicyId-all-permissions | GET /motor-insurance-policies/{InsurancePolicyId}/customer-payment-details : Negative Test - Mandatory header validation - Fail if o3-caller-software-statement-id header is missing (insuranceToTest: valid_insurancePolicyId-all-permissions) | 400 | The operation must fail with a status code 400 if the o3-caller-software-statement-id header is missing | INS_018 | | GET /motor-insurance-policies : Negative Test - Mandatory header validation - Fail if o3-ozone-interaction-id header is missing (insuranceToTest: valid_insurancePolicyId-all-permissions | 400 | The operation must fail with a status code 400 if the o3-ozone-interaction-id header is missing | INS_019 | insuranceToTest: valid_insurancePolicyId-all-permissions | GET /motor-insurance-policies : Negative Test - Mandatory header validation - Fail if o3-consent-id header is missing (insuranceToTest: valid_insurancePolicyId-all-permissions) | 400 | The operation must fail with a status code 400 if the o3-consent-id header is missing | INS_020 | insuranceToTest: valid_insurancePolicyId-all-permissions | GET /motor-insurance-policies : Negative Test - Mandatory header validation - Fail if o3-caller-interaction-id header is missing (insuranceToTest: valid_insurancePolicyId-all-permissions) | 400 | TThe operation must fail with a status code 400 if the o3-caller-interaction-id header is missing | INS_021 | insuranceToTest: valid_insurancePolicyId-all-permissions | GET /motor-insurance-policies : Negative Test - Mandatory header validation - Fail if o3-caller-software-statement-id header is missing (insuranceToTest: valid_insurancePolicyId-all-permissions) | 400 | The operation must fail with a status code 400 if the o3-caller-software-statement-id header is missing | INS_022 | | GET /motor-insurance-policies/{InsurancePolicyId} : Negative Test - Mandatory header validation - Fail if o3-ozone-interaction-id header is missing (insuranceToTest: valid_insurancePolicyId-all-permissions | 400 | The operation must fail with a status code 400 if the o3-ozone-interaction-id header is missing | INS_023 | insuranceToTest: valid_insurancePolicyId-all-permissions | GET /motor-insurance-policies/{InsurancePolicyId} : Negative Test - Mandatory header validation - Fail if o3-consent-id header is missing (insuranceToTest: valid_insurancePolicyId-all-permissions) | 400 | The operation must fail with a status code 400 if the o3-consent-id header is missing | INS_024 | insuranceToTest: valid_insurancePolicyId-all-permissions | GET /motor-insurance-policies/{InsurancePolicyId} : Negative Test - Mandatory header validation - Fail if o3-caller-interaction-id header is missing (insuranceToTest: valid_insurancePolicyId-all-permissions) | 400 | TThe operation must fail with a status code 400 if the o3-caller-interaction-id header is missing | INS_025 | insuranceToTest: valid_insurancePolicyId-all-permissions | GET /motor-insurance-policies/{InsurancePolicyId} : Negative Test - Mandatory header validation - Fail if o3-caller-software-statement-id header is missing (insuranceToTest: valid_insurancePolicyId-all-permissions) | 400 | The operation must fail with a status code 400 if the o3-caller-software-statement-id header is missing |
|
Back to top
