TPDU – The Transaction Protocol Data Unit
The Transaction Protocol Data Unit (TPDU) is an old-school packet-based protocol designed for transaction-oriented applications. On the OSI model it stands between Transport Layer (e.g. X.25, TCP or UDP) and the Application Layer. It was originally designed for X.25-based dial up payment devices to provide the ability to concentrate a large number of these into one central host connection.
TPDU uses first 5 bytes to store routing information for the payment message and also provides this space for marking up its way back to its origin (source). Having 2 bytes for destination address and 2 bytes for the source address, this system can be effectively set with up to 10^4 routes over 3 router jumps.
While being very efficient in the past, today’s routing requirements have changed a lot and are not limited by the number of router/switch jumps and the need to deliver the payment message to the acquirer more efficiently (less jumps) and faster. Modern payment switches have to unpack message content and provide wider business logic on top of network packet routing options like per Card Issuer, Business Unit, Incoming connection socket or simply by the cheapest available route.
TPDU is still widely in use and in this article we’ll have a look into its basics and demonstrate this interesting technology using an example with BP-Sim.
TPDU message has 3 parts:
- Protocol ID – Access protocol for a TPDU message
- Destination Address – Routing information for reaching message’s destination
- Source Address – Routing information for getting back to message’s origin
Protocol ID is commonly set to the hexadecimal value of 0x60. Destination address will be originally determined by the payment terminal (e.g. by BIN range) arriving into the NAC or payment switch and the router parses its values to find its desired destination. Source address is being formed during this process, virtually marking up its path back. Response message is then formed swapping Destination and Source bytes and sent back through the same system. Modern switches have commonly an option to do a straight lookup and match destination address with a configured NII and using its internal routing facilities to overload this mechanism.
One of the interesting features of TPDU comes from its origin in dial-up ages. This protocol doesn’t provide a reliable transport mechanism so additional session and flow control is needed to establish reliable payment message delivery system. Such behavior ensures that only one live connection is currently in place across the system for a particular payment device.
EFTlab have provided facilities to emulate this message processing using the BP-Sim emulator through its BP-Source and BP-Host components.
The following BP-Source script allows an overload of TPDU header for an arbitrary payment request message with Protocol ID 0x60, Destination Address 0x1111 and Source Address 0x2222.
Processing this script with BP-Sim against a TPDU router will result in message represented by the following trace. TPDU header parts are clearly visible in its binary data.
BP-Sim will also provide a log with expectations matching actual values received:
A similar facility is provided in BP-Host where the script logic is completely opposite. The TPDU header is validated upon receiving the message then the scripting features provide an option to amend the TPDU header values for the response to test most processing scenarios.
It should be noted that regardless of the test script mentioning TPDU that TPDU must be enabled on the particular BP-Source or BP-Host node for the scripting options to be applied.
