Status Reports

all exchanges with the terminal management system (tms) are initiated by the point of interaction (poi) sending a status report the intended flow is for a poi to send a statusreport requesting a managementplanreplacement and, if updates are needed, send another statusreport requesting an acceptorconfigurationupdate optionally, the poi can send another statusreport checking for further changes request http parameters url /v1/catm/status report http verb post request message use iso20022 message definition statusreportv12 (message identifier catm 001 001 12) it is recommended to use the iso 20022 dictionary to determine the complete structure of the message https //www iso20022 org/standardsrepository/type/statusreportv12 we support two ways of using a statusreport 1\ to request a managementplanreplacement detailing actions the poi must take to align its configuration with the tms' expectations 2\ to request an acceptorconfigurationupdate containing the necessary configuration parameters the intended flow is for a poi to send a statusreport requesting a managementplanreplacement and, if updates are needed, send another statusreport requesting an acceptorconfigurationupdate please note the following additional requirements property securitytrailer of type contentinformationtype33 (child of statusreportv12 ) is mandatory propery datasetrequired of type datasetrequest1 (child of statusreportcontent12 ) is mandatory the type of the first item in the datasetrequired array must be either "securityparameters" or "managementplan" subsequent members of the array will be ignored response message if the request could not be successfully processed, a terminalmanagementrejection message will be returned otherwise, there are two scenarios the statusreport can request a managementplanreplacement (message identifier catm 002 001 12) by setting dataset content datasetrequired\[0] identification type to "managementplan" a managementplanreplacement message will be returned to inform the poi of any changes that need to be made conceptually the poi starts with a 'management plan' of doing nothing, and this is 'replaced' with, for example, 'update the firmware to version x and perform remote key loading' in the integration environment, for ease of testing we always indicate that the poi must download a dataset with name 'rki' and type 'securityparameters' the statusreport can request an acceptorconfigurationupdate (message identifier catm 003 001 12) containing security parameters by setting dataset content datasetrequired\[0] identification type to "securityparameters" the tms will respond with keys and other security material in a format agreed with the integrator (outside the scope of this document) please note that a securitytrailer of type contentinformationtype33 will always be included with the response to allow the acceptor to verify that the response is legitimate examples the messages provided below are formatted for readability when sending requests to the gateway, the request body should be compacted by removing all non significant whitespace characters this section is incomplete