TPDU - The Transaction Protocol Data Unit

Disaster Recovery

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

TPDU header format diagram

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.

#BP-Source TPDU Demo
<TestScript>
<TSName/>Iso8583_R93_script_TPDU
<TSDesc/>Sets TPDU header to 6011112222 and checks response
<TrxFormat/>ISO8583-1993
<StartingStep/>1

<Step>
<ID/>1
<Profile/>1100 - Authorisation request
#Request overload
<ReqTPDU/>6011112222
#Response validation/expectations
<RspDE_39/>000
<RspTPDU/>6022221111
</Step>
</TestScript>

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.

[2015-04-29 21:20:38.381200] Terminal 80000001 sending message to localhost:7001 (online delivery)
1100:
[LLVAR    n            ..19 016] 002       [4025000000008005]
[Fixed    n               6 006] 003       [000000]
[Fixed    n              12 012] 004       [000000000100]
[Fixed    n              12 012] 005       [000000000000]
[Fixed    n               6 006] 011       [002170]
[Fixed    YYMMDDhhmmss   12 012] 012       [150429212038]
[Fixed    YYMM            4 004] 014       [0811]
[Fixed    an             12 012] 022       [B1020120014C]
[Fixed    n               3 003] 024       [200]
[Fixed    n               4 004] 026       [5541]
[LLVAR    n            ..11 006] 032       [414243]
[LLVAR    z            ..37 037] 035       [4025000000008005d13081010000067400000]
[Fixed    n               3 003] 040       [080]
[Fixed    ans             8 008] 041       [80000001]
[Fixed    ans            15 015] 042       [811234567890101]
[Fixed    an              3 003] 049       [826]
[Fixed    b               8 016] 052      *[68E79746C86BCFF5]
[LLVAR    b            ..48 016] 053      *[FEDCBA9876543210]
[Fixed    b               8 016] 064      *[0011223344556677]

binary data:
0000(0000)   00 D0 60 11 11 22 22 31  31 30 30 78 34 05 41 21  ..`..""1100x4.A!
0016(0010)   C0 98 01 31 36 34 30 32  35 30 30 30 30 30 30 30  ...1640250000000
0032(0020)   30 38 30 30 35 30 30 30  30 30 30 30 30 30 30 30  0800500000000000
0048(0030)   30 30 30 30 31 30 30 30  30 30 30 30 30 30 30 30  0000100000000000
0064(0040)   30 30 30 30 30 32 31 37  30 31 35 30 34 32 39 32  0000021701504292
0080(0050)   31 32 30 33 38 30 38 31  31 42 31 30 32 30 31 32  120380811B102012
0096(0060)   30 30 31 34 43 32 30 30  35 35 34 31 30 36 34 31  0014C20055410641
0112(0070)   34 32 34 33 33 37 34 30  32 35 30 30 30 30 30 30  4243374025000000
0128(0080)   30 30 38 30 30 35 64 31  33 30 38 31 30 31 30 30  008005d130810100
0144(0090)   30 30 30 36 37 34 30 30  30 30 30 30 38 30 38 30  0006740000008080
0160(00A0)   30 30 30 30 30 31 38 31  31 32 33 34 35 36 37 38  0000018112345678
0176(00B0)   39 30 31 30 31 38 32 36  68 E7 97 46 C8 6B CF F5  90101826h..F.k..
0192(00C0)   30 38 FE DC BA 98 76 54  32 10 00 11 22 33 44 55  08....vT2..."3DU
0208(00D0)   66 77                                             fw

[2015-04-29 21:20:38.384449] Terminal 80000001 received message from localhost:7001 (online delivery)
1110:
[LLVAR    n            ..19 016] 002       [4025000000008005]
[Fixed    n               6 006] 003       [000000]
[Fixed    n              12 012] 004       [000000000100]
[Fixed    n               6 006] 011       [002170]
[Fixed    YYMMDDhhmmss   12 012] 012       [150429212038]
[LLVAR    n            ..11 006] 032       [414243]
[Fixed    n               3 003] 039       [000]
[Fixed    ans             8 008] 041       [80000001]
[Fixed    ans            15 015] 042       [811234567890101]
[Fixed    an              3 003] 049       [826]
[LLVAR    b            ..48 016] 053      *[FEDCBA9876543210]
[Fixed    b               8 016] 064      *[0011223344556677]

binary data:
0000(0000)   00 7E 60 22 22 11 11 31  31 31 30 70 30 00 01 02  .~`""..1110p0...
0016(0010)   C0 88 01 31 36 34 30 32  35 30 30 30 30 30 30 30  ...1640250000000
0032(0020)   30 38 30 30 35 30 30 30  30 30 30 30 30 30 30 30  0800500000000000
0048(0030)   30 30 30 30 31 30 30 30  30 32 31 37 30 31 35 30  0000100002170150
0064(0040)   34 32 39 32 31 32 30 33  38 30 36 34 31 34 32 34  4292120380641424
0080(0050)   33 30 30 30 38 30 30 30  30 30 30 31 38 31 31 32  3000800000018112
0096(0060)   33 34 35 36 37 38 39 30  31 30 31 38 32 36 30 38  3456789010182608
0112(0070)   FE DC BA 98 76 54 32 10  00 11 22 33 44 55 66 77  ....vT2..."3DUfw
0128(0080)     

BP-Sim will also provide a log with expectations matching actual values received:

Script's name:         Iso8583_R93_script_TPDU
Script's description:     Checks TPDU header
Module:         BP-Source
Transaction format:     ISO8583-1993
Report created on:    2015/04/29 21:20:38
********************
[2015-04-29 21:20:38.738042]
--------------------
Step Id:        1
TPDU Header : [6022221111]|[6022221111]- Passed
DE_039    : [000]|[000] - Passed
--------------------
Test finished:         2015/04/29 21:20:38
Nr. of tests failed:    0
Nr. of tests passed:    2
********************
Test overall result:    Passed

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.

BP-Tools

BP-Tools is a set of freeware applications for EFT testing, benchmarking and transaction service development.

See more...

Download...

Download Flyer...

BP-Sim

The Babylon Payments Simulator (BP-Sim) is a family of highly efficient regression and stress testing tools, designed for deployment in development and pre-production environments. BP-Sim allows users to perform an extensive range of tests across the chain of payment services.

See more...

Download Flyer...

BP-Processing

The Babylon Payments Processing Suite(BP-Processing) is a suite of EFTlab's products for realtime payment transaction processing and authorisation.

See more...