Skip to main content
Version

Introduction

Intended audience​

This document is relevant for parties developing software for payment terminals in order to integrate with the CM.com IPP Payments Platform or they are investigating the options for such an integration.

This document details how a third party application or system can connect and use the CM.com IPP Payments Platform.

Processor Style Protocol explained​

The Processor Style Protocol defines the flow and structure of messages between a payment initiator and CM.com IPP Payments Platform.

At it’s core the Processor Style Protocol is using a Request-Response-pattern, where the payment terminal sends an AuthorizationRequest and receives an AuthorizationResponse. For some flows it is needed to send multiple successive AuthorizationRequest, for example when the cardholder has to perform additional tasks for authentication (like inserting a card, entering a PIN or retrying a PIN).\

Messages within a flow are interconnected through a unique Transaction Identifier. This identifier is exclusive to the entire flow and must be included in every subsequent message. It is initially provided in the AuthorizationResponse message. In the case of cloud integration, the Transaction Identifier is received earlier — specifically when the terminal obtains transaction details before sending the authorization request to the CM.com IPP Payments Platform.

Messages between the payment terminal and the CM.com IPP Payments Platform are encoded using the Basic Encoding Rules Tag Length Value format also known as BER TLV and are sent using a TCP-connection.

Initiation of a transaction​

The Processor Style Protocol does not specify a mechanism to initiate a transaction on the payment terminal, since that is dependent on the mechanism of integration. Some examples:

  • A payment terminal could be integrated into a vending-machine or fuel-dispenser, where the transaction starts after the cardholder selected the products.

  • A payment terminal could be connected to an ECR (Electronic Cash Register), where the transaction starts after the Sales Representative initiates the purchase. An example of this integration could be found here: Cloud Integration

  • The payment terminal could be a handheld device, where the ECR application is running on the same payment terminal. An example of this integration could be found here: App2App Integration

These mechanisms are out-of-scope for the Processor Style Protocol. The Processor Style Protocol starts to become relevant when the terminal needs to initiate a transaction.