Test Data
Specific tests for collection payments
This section provides an overview of the information needed to make test payments and obtain all possible transaction outcomes. A detailed table lists the parameters and configurations required to simulate different payment scenarios, allowing for accurate verification of the system's operation.
The goal is to support developers and testers in managing test transactions, ensuring a complete analysis of the system's responses in different scenarios.
As is known, if the credit account is a Fabrick account (for example, Banca Sella), it will also be possible to test the case of a payment reconciled on the account itself, a test that will not be possible in the case of accounts at other banks.
Obviously, the credential sets refer to the debtor banks, so the tests refer to the collection payment mode.
Test cases are, of course, only available in the pre-production environment.
-
bank: identifies the name of the debtor bank
-
product: type of payment, sepa-credit-transfers or instant-sepa-credit-transfers
-
amount: transfer amount
-
status: final payment status to be obtained at the end of the test.
-
threshold: time after which the final status indicated in the status column will be reached. The time interval is indicated in seconds.
In all cases, if the payment flow is not completed within 5 minutes, the KO status will be returned.
Example
Suppose we want to test the positive case, for example a successful instant credit transfer. The credit account is Banca Sella.
In this case, it will be sufficient to refer to the table in the first paragraph, which shows that the first two rows satisfy the conditions indicated above. Both are identical, so I can decide whether to use Banca Sella or Banca Popolare di Sondrio. I will need to pay attention to the amount, since it will be necessary to set the amount variable to €1.
I will then proceed with the payment flow and, depending on the bank chosen, enter the relevant credentials indicated in the "Credentials" section.
By making this type of payment, after 45 seconds the status will be converted to executed, i.e. OK.
| # Test | Product | Bank | User | IBAN in input | Amount | Threshold (s) | PSD2 Status |
|---|---|---|---|---|---|---|---|
| 1 | instant-sepa-credit-transfers | Mock | user05 | no | any value | 0 | EXECUTED |
| 2 | instant-sepa-credit-transfers | Mock | user04 | no | 2-20-200 | 60 | PENDING -> EXECUTED |
| 3 | instant-sepa-credit-transfers | Mock | user04 | no | 5-50-500 | 60 | PENDING -> REJECTED |
| 4 | instant-sepa-credit-transfers | Mock | user06 | IT...114 | any value | 0 | REJECTED |
| 5 | sepa-credit-transfers | Mock | user05 | no | any value | 0 | EXECUTED |
| 6 | sepa-credit-transfers | Mock | user04 | no | 2-20-200 | 120 | PENDING -> EXECUTED |
| 7 | sepa-credit-transfers | Mock | user04 | no | 5-50-500 | 120 | PENDING -> REJECTED |
| 8 | sepa-credit-transfers | Mock | user06 | IT...114 | any value | 0 | REJECTED |
| 9 | instant-sepa-credit-transfers | Mock | user04 | no | 3-30-300 | 60 | PENDING -> SETTLED |
| 10 | sepa-credit-transfers | Mock | user04 | no | 3-30-300 | 120 | PENDING -> SETTLED |
| 11 | instant-sepa-credit-transfers | Mock | user04 | IT...112 | 122 | 60 | PENDING -> SETTLED |
| 12 | sepa-credit-transfers | Mock | user05 | IT...212 | 152 | 120 | PENDING -> SETTLED |
Additional notes:
-
The test cases where the final status is settled are only available if the credit account is an account managed by Fabrick (for example Sella or Fabrick). The behavior is therefore identical to that of production, since the service setup configurations are different.
-
user05 allows simulating IBAN selection, i.e. the choice between two IBANs. This behavior is only available in redirect mode as per the directives. Only for testing purposes has it been decided to also leave the embedded case functional, obviously without allowing the IBAN choice.
-
The "IBAN in input" column indicates whether the case requires an IBAN as input or not, i.e. whether it is necessary to pass the IBAN in the body of the request (in any of the various modes made available by the product). In the required cases, in the absence of an IBAN it will not be possible to complete the payment flow, while in the others the rule will not be enforced.
Credentials
| Bank | IBAN | Usercode | Password | OTP method | OTP |
|---|---|---|---|---|---|
| Mock | IT32X3615900000000000000112 | user04 | passwd04 | SMS | 11111111 |
| Mock | IT09Y3615900000000000000113, IT41K3615900000000000000212 | user05 | passwd05 | SMS | 22222222 |
| Mock | IT83Z3615900000000000000114 | user06 | passwd06 | SMS | 33333333 |
Generic test cases for AIS and PIS
This section lists additional sandbox credential sets that can be used for both the aggregation and the payments parts.
| BANK | SERVICE CODE | USERNAME | PASSWORD | OTP |
|---|---|---|---|---|
| Mock | user01 | passwd01 | 12345678 | |
| Mock | user02 | passwd02 | 23456789 | |
| Mock | user03 | passwd03 | 34567890 | |
| Credem | 13384 | 000000Ab! | 123456 | |
| Intesa San Paolo | Retail | HYND34G7 | 54321 | any 6 digits |
| 6642666 | 20897 | |||
| JYBD3W7Z | 15896 | any 6 digits | ||
| Cassa Rurale di Trento | INBANK | 07391366 | Test07391366 | automatic |
| BPER | SMART | 65561693 | 65561693 | not required |
| BANCO BPM | INTERNET BANKING PER CLIENTELA PRIVATA | 1234567 | 1234567 | any 6 digits |
| 7654321 | 7654321 | any 6 digits | ||
| CREDITO EMILIANO (CREDEM) | RETAIL (Privati e Famiglie) | 13384 | 000000Ab! | 123456 |
| BUDDY BANK | ALL | ituser1bgk | pwituser1bgk | See Notes |
| Unicredit | ALL | ituser2bgk | pwituser2bgk | Not required |
| MONTE DEI PASCHI DI SIENA | retail (Single Account) | 45421323 | 12344321 | 000000 |
| retail (Multi Accounts) | 39442898 | 12344321 | 000000 | |
| BANCA GENERALI | IB | 0010214-77 | pswpsw01 | Not required |
The mock bank is a bank managed by Fabrick; in case of malfunctions, please report it via ticket so that it can be resolved immediately.
As for the other banks, we would like to clarify that they are entirely managed by the reference gateway. We have noticed that these accounts are sometimes under maintenance and/or not working for a short period. In case of error, it is therefore recommended to continue testing using another account and try again later with the previous one. In case of prolonged malfunction, it will be possible to open a Jira ticket with our Service Desk, which will forward the request to the relevant gateway. As for the payments part, for example, the final status is often a constant and therefore the payment will not go through the various states up to the final one; for this reason, for collection payment tests it is advisable to use the previous specific section.