Quality of life improvements I

We added a couple of improvements to several endpoints

New filter for transaction list and card requests

It is now possible

• to filter transactions based on the query parameter partnerSubmissionStatus for our List of Transactions (GET /transactions) endpoint.
• to filter card requests based on the query parameter type for our List Card Requests (GET /cards/requests) endpoint.

The allowed ENUM values are:

NOT_SYNCED
SYNCED
TEMP_LOCKED
LOCKED

VIRTUAL
SINGLE_USE
TRAVEL
PHYSICAL
BLACK

New endpoint to update cards

We are introducing a new endpoint PATCH /cards/{cardId} that enables to update label OR purpose property based on card type:

New callback in case of changing transaction type

In some (rare) cases merchants do create purchases in the amount of 1.00 EUR instead of card checks. Later on, the transaction type changes from PURCHASE to STATUS_INQUIRY. To better handled such cases we introduced a new TRANSACTION_TYPE_UPDATED event in the transactions callback subscription endpoint: POST /transactions/subscription

Minor improvements

• For POST /cards/{cardholderId} and POST /cards/requests/{cardRequestId}/approve the expiryDate response property returns valid values now (previously responded with NULL).
• Instead of returning HTTP response status code 204 No Content we do return 201 Created including the cardRequestId in the response body when creating card requests using the POST /cards/requests endpoint.
• Fixed a bug where it was not possible to provide NULL value for purpose property when creating card requests using the POST /cards/requests endpoint.
• We tightened the security of the endpoint which allows inviting an owner during onboarding. It's now only possible to call the endpoints POST /cardholders/invite-owner once the organisation is in one of the listed states without getting 403 error.

ONBOARDING_STARTED
ONBOARDING_RISK_AND_COMPLIANCE
ONBOARDING_MANDATES_AND_TERMS
ONBOARDING_WAIT