...
| title | MENU |
|---|
| Table of Contents | ||
|---|---|---|
|
The following test cases have been implemented in the Testing Tool:
...
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 in descending/ascending order of which date? |
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
Fail if o3-provider-id header is missing
400
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
Fail if o3-ozone-interaction-id header is missing with status 400 and correct schema
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 |
|
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
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
Inquire a 'Rejected' Single Immediate DomesticpaymentNote: 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
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
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-callerapi-org-id uri header is missing | 400 | Fail if o3-callerapi-org-id uri header is missing with status 400 and correct schema |
Fail if o3-callerapi-client-id operation header is missing | 400 | Fail if o3-callerapi-client-id operation header is missing with status 400 and correct schema |
Fail if o3-calleraspsp-software-statement-id header is missing | 400 | Fail if o3-calleraspsp-software-statement-id header is missing with status 400 and correct schema |
Fail if o3-consentozone-interaction-id header is missing | 400 | Fail if o3-ozone-consentinteraction-id header is missing with status 400 and correct schema |
Fail if o3-consentprovider-id header is having invalid valuemissing | 400 | Fail if o3-consentprovider-id header is having invalid value missing with status 400 and correct schema |
Fail if o3-caller-softwareorg-statement-id header is having invalid valuemissing | 400 | Fail if o3-caller-softwareorg-statement-id header is having invalid value missing with status 400 and correct schema |
Fail if o3-caller-client-id header is having invalid valuemissing | 400 | Fail if o3-caller-client-id header is having invalid value with missing with status 400 and correct schema |
Fail if o3-caller-orgsoftware-statement-id header is having invalid valuemissing | 400 | Fail if o3-caller-orgsoftware-statement-id header is having invalid value missing with status 400 and correct schema |
Fail if o3-providerconsent-id header is having invalid valuemissing | 400 | Fail if o3-providerconsent-id header is having invalid value missing with status 400 and correct schema |
Fail if o3-ozone-interactionconsent-id header is having invalid value | 400 | Fail if o3-ozoneconsent-interaction-id header is having invalid value with status 400 and correct schema |
Fail if o3-aspspcaller-software-statement-id header is having invalid value | 400 | Fail if o3-aspspcaller-software-statement-id header is having invalid value with status 400 and correct schema |
Fail if o3-caller-apiclient-operation id header is having invalid value | 400 | Fail if o3-apicaller-client-operation id header is having invalid value with status 400 and correct schema |
Fail if o3-caller-apiorg-uri id header is having invalid value | 400 | Fail if o3-apicaller-org-uri id header is having invalid value with status 400 and correct schema |
Fail if o3-psuprovider-identifier id header is having invalid value | 400 | Fail if o3-psuprovider-identifier id header is having invalid value with status 400 and correct schemaFails |
Fail if o3-ozone-psuinteraction-identifier is not b64 encodedid header is having invalid value | 400 | Fails Fail if o3-ozone-psuinteraction-identifier is not b64 encoded id header is having invalid value with status 400 and correct schemaFails |
Fail if o3-psu-identifier does not evaluate to a json structureaspsp-id header is having invalid value | 400Fails | Fail if o3-psu-identifier does not evaluate to a json structure, aspsp-id header is having invalid value with status 400 and correct schemaFails |
Fail if o3-psu-identifier does not contain userIdapi-operation header is having invalid value | 400 | Fails Fail if o3-psu-identifier does not contain userId, api-operation header is having invalid value with status 400 and correct schema |
Fails Fail if o3-psuapi-identifier uri header is having invalid - the decoded value is valid JSON, but userId is null, empty or undefined | 400 | Fails Fail if o3-psuapi-identifier uri header is having invalid - the decoded value is valid JSON, but userId is null, empty or undefined, with status 400 and correct schemaFails |
Fail if o3-psu-identifier header is having invalid - the decoded value is valid JSON, but userId is not a string | 400 | Fails Fail if o3-psu-identifier header is having invalid - the decoded value is valid JSON, but userId is not a string, with status 400 and correct schema |
2. Bank Service Test Cases
POST /payments & Get /payments
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 |
|
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 Inquire a 'Rejected' Single Immediate Domesticpayment 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 | 400 | Error response |
Negative Test - Fail if | 400 | Error response |
Negative Test - Fail if | 400 | Error response |
Negative Test - Fail if | 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 |
|
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}
...