This guide walks you through how payment testing in Aritma's development environment utilizes a mock bank and enables you to test a series of payment-scenarios. These are the basic functionalities of what it does.
- Creates receipts for payments
- Creates transactions for payments
- Is a in replacement for the real banks in Aritmas dev environment
- Keep on reading for details on what is possible with the Aritma mock bank
Aritma's mock bank is a service running in place of the actual banks in development. The mock bank will try to emulate the behaviour of the actual bank you are sending payments to. What is important to understand is where the mock bank falls in place in the flow of a payment. After a payment is sent to Aritma it is validated, processed and saved. Then when a authorization is completed Aritma sends the payment to a bank. In this case, the development environment, the mock bank is what receives this payment, based on information in the payment, what bank it is sent to and accounts contained, a response is created and sent back to Aritma banking as Transactions. The mock bank has custom logic to facilitate for various testing which will be explored in this guide.
Before you begin, make sure you have the following in place:
- Completed the Quick Start or otherwise have been onboarded into Aritma's development environment
When sending any payment this is the behaviour that the mock bank will have.
A payment that is sent to the mock bank, if legal and accepted, will receive a acknowledgement. This is common from banks and is also known as a receipt. This receipt will map back to the payment, updating its status to Accp. After this the mock bank creates statements and creditDebitNotifications that will also map back to the payments and updates its status for the last time to Acsc. Both of these updates will send a payment status event which is the best way to stay updated on payment statuses.
Transactions relating to the payments sent into the mock bank will be generated in two forms. Statements and CreditDebitNotifications these both send out transactions received events. These transactions will match payments, but will sometimes be bundled together and come as Transaction details
In this section some more advances features that are needed for specific use cases will be explored
Currency exchange and charges are fields in a transaction that come up in some cases from the bank. It could be making a payment to a foreign bank, using different currency than the account or doing a priority payment. In the mock bank to achieve a both a charge and a currency exchange making any payment to or from an account with a different currency than the account will generate transactions with both charges and currency exchange.
When the mock bank gets a payment it will generate transactions both to the debtor and the creditor, this means that if you want to view both sides of a transaction you should send a payment from an account you own to another account you own. In this scenario you will get both credit transactions on the creditor account and debit transactions on the receiving account.
The mockbank is able to do custom overrides. This is done by setting an URN from the table below in the field remittanceInformationUnstructured in a payment initiation.
| Action | URN Value |
|---|---|
| Set specified status for the payment in the receipt | urn:mock:payments:status:[transaction status code] |
| Set specified status reason for the payment in the receipt | urn:mock:payments:status_reason:[reason] |
These actions will override the default behaviour of the mock bank, but if this should succeed then the status update should still be a legal one following the flow in the status chart. The example below shows how the payment line should look to achive any of these overrides
"paymentLines": [
{
"endToEndIdentification": "bla1",
...
"remittanceInformationUnstructured": "urn:mock:payments:status_reason:AC03:Insufficient_funds"
}
]