Card Processing Introduction

This project is an example of a Card Processing application. This application uses the JPOS channel example and the ActiveSpaces Transactions Business State Machine framework to implement a highly available Card Processing application.

The Card Processing application uses the common ActiveSpaces Transactions application architecture.

Please see the enclosed source, javadoc, and application architecture.

Quick Start

Perform the following steps to execute a Card Processing request:

  1. Build the channels. See the Dependencies section for details on building the the example channels required by the Card Processing application.
  2. Start Card Processing application. See the Usage section for details on starting the application.
  3. Load merchant profile data See the Merchant_Profile section for details on loading merchant profile data.
  4. Confirm that the application has signed on to the VISAW and VISAE processors during application startup. See the Administration section for details.
  5. Send request. See the Merchant_Requests section for details on how to send a merchant request.

Dependencies

The Card Processing application uses the JPOS and the Host Security Module (HSM) example channels so these examples must be built and installed in your local Maven repository before building the Card Processing application.

Use the Maven install command to build and install the example channels. The install command needs to be run separately for each channel, and needs to be run from the channel's root directory (e.g. examples/jposchannel and examples/hsmchannel). The install command compiles the example channel, runs the channel's unit tests, and installs the channel's jar file into the local Maven repository.

cd <path to examples>/jposchannel

mvn -Dcom.kabira.fluency.administrationPort=2000 \
        -Dcom.kabira.fluency.hostName=kabira-server.local \
        install

cd <path to examples>/hsmchannel

mvn -Dcom.kabira.fluency.administrationPort=2000 \
        -Dcom.kabira.fluency.hostName=kabira-server.local \
        install

NOTE: kabira-server.local only works on OS X. Other platforms may use a different name or have to specify an IP address.

For information on all of the Card Processing application's dependencies see the Dependencies page.

For each dependency listed in the Project Dependencies section of the Dependencies page, the application's POM (or parent POM) defines a property specifying the version of the dependency used by the application. These properties can be overridden if there is a need to change the dependency versions used by the application. The names of these properties are of the form com.tibco.groupId.artifactId.version where groupId and artifactId are the group id and artifact id of the dependency. For example, the property named com.tibco.com.tibco.ast.version specifies the version of the dependency with the group id of com.tibco and the artifact id of ast.

Usage

The Card Processing application can be started on one or more nodes.

Use this command to start the Card Processing Application on the A node on the ActiveSpaces Transactions Development Appliance:

NOTE: kabira-server.local only works on OS X. Other platforms may use a different name or have to specify an IP address.

mvn -Dcom.kabira.fluency.administrationPort=2000 \
        -Dcom.kabira.fluency.hostName=kabira-server.local \
        compile deploy:exec

The application will display the following when it has completed initialization on all nodes. Trace messages from the Visa and HSM simulators (not shown below) are also displayed if the simulator configurations enable tracing.

[A] ==============================================
[A] VISAW-Simulator started at port - 10060.
[A] ==============================================
[A] ==============================================
[A] VISAE-Simulator started at port - 10061.
[A] ==============================================
[A] ==============================================
[A] HSM-Simulator-Primary started at port - 2010.
[A] ==============================================
[A] ==============================================
[A] HSM-Simulator-Backup started at port - 2012.
[A] ==============================================
[A] ==============================================
[A] Acme mail order merchant listener started at port - 10050.
[A] ==============================================
[A] ==============================================
[A] Processor started - VISA West Processing Center.
[A] ==============================================
[A] ==============================================
[A] Processor endpoint created - VISAW.
[A] ==============================================
[A] ==============================================
[A] Processor started - Visa East Processing Center.
[A] ==============================================
[A] ==============================================
[A] Processor endpoint created - VISAE.
[A] ==============================================
[A] INFO: JMX Management Service started at:
[A]         kabira-server:2099
[A]         192.168.71.130:2099
[A]         service:jmx:rmi:///jndi/rmi://kabira-server:2099/jmxrmi
[A] ==============================================
[A] Card Processing application started.
[A] ==============================================

The port numbers that are displayed during initialization are:

  • Acme mail order listener is the port number that must be used to connect to the server with a client.
  • processor simulator ports are used by the application internally.

By default the Card Processing application starts the following services:

Default Services

These services are:

  • nodeagent - Node management agent
  • Acme - Merchant listener
  • VISAW - Connections to VISA West processor
  • VISAE - Connections to VISA East processor
  • HSM-Service - Host Security Module simulator
  • VISAW-Simulator - VISA West processor simulator listener
  • VISAE-Simulator - VISA East processor simulator listener

Administration

The Card Processing application supports these application specific administration targets:

  • processor - used to signon/signoff a processor and display processor status.
  • cardprocessing - display and reset statistics
  • merchant - display and load merchant terminal data
  • accesslist - manage white, black, and grey lists

    Here is the usage for the processor target.

      valid commands and parameters for target "processor":
    
      display processor
            [ name=<String> ]
                    Processor name
    
            Display processor status
    
      signon processor
            name=<String>
                    Processor name
    
            [ trace=<Boolean, default = false> ]
                    If true, enables tracing.  Both the signon and signoff commands are traced.
    
            Initiate a processor sign-on command
    
      signoff processor
            name=<String>
                    Processor name
    
            [ force=<Boolean, default = false> ]
                    If true, a forceful signoff occurs. No signoff message is sent to the processor.
    
            [ trace=<Boolean, default = false> ]
                    If true, enables tracing of the signoff command.
    
            Initiate a processor sign-off command
    
    
    Description:
    
    Processor management

    The Card Processing application signs on to the network processors when the application starts. See the Connectivity section for details on this behavior can be enabled or disabled.

    An administrator can use the processor signon and signoff commands to manually signon on to a processor or signoff from a processor.

    The processor signon and signoff commands just initate the respective processor command. The actual signon or signoff completes after the processor management command returns to the operator. Any errors detected during the signon or signoff process are reported with an event.

    The processor signon and signoff commands send individual signon (or signoff) requests for each of the processor's endpoints. The processor signon command retries the signon request if a failure occurs while sending the command (e.g. the endpoint has not been started).

    The display processor command can be used to determine if the application has signed on to the network processors.

    Here is example output from the display processor command executed after the application has started. Note that the application has signed on to the VISAW and VISAE processors.

    Processor

    There is an active Processor Management business state machine process for each of the processor's endpoints following a successful signon to a processor. The currently active business state machine processes can be displayed using the Business State Machines tab in ActiveSpaces Transactions Administrator.

    Processor Management Business State Machine

    Here is the usage for the cardprocessing target.

      valid commands and parameters for target "cardprocessing":
    
      reset cardprocessing
            [ mti=<String> ]
                    MTI statistic to reset
    
            Reset one or more of the MTI statistics
    
      display cardprocessing
            Display current MTI statistic values
    
    Description:
    
    Card processing MTI statistics
    

    Here is example output from the display cardprocessing command.

    Statistics

    Here is the usage for the merchant target.

      valid commands and parameters for target "merchant":
    
      count merchant
            Count merchants
    
      load merchant
            filename=<String>
                    The full path to the merchant data file on the server
    
            Load merchant data file
    
      display merchant
            [ merchant=<String> ]
                    merchant
    
            [ terminal=<String> ]
                    terminal
    
            Display a merchant's terminals or the merchant associated with a
            particular terminal
    
    
    Description:
    
    Merchant management

    Here is example output from the display merchant command for a particular merchant.

    Merchant Terminals

    Here is the usage for the accesslist target.

      valid commands and parameters for target "accesslist":
    
      load accesslist
            name=<String>
                    The name of the access list
    
            type=<String>
                    The type of access list. Legal values are whitelist, blacklist, and greylist.
    
            filename=<String>
                    The full path to the access list data file on the server
    
            Load an access list data file
    
      remove accesslist
            name=<String>
                    The name of the access list to remove.
    
            Remove the specified access list. This command fails if the access list does not exist.
    
      audit accesslist
            Checks if all of the configured access lists have been loaded.  
            The command's output contains the names of the missing access lists.
            There is no output if all access lists have been loaded.
    
      display accesslist
            [ name=<String> ]
                    The name of the access list to display. This parameter is optional. 
                    If name is not empty then this command only displays information
                    for the access list with this name.
    
            [ type=<String> ]
                    The type of access list to display. This parameter is optional.
                    The legal values are whitelist, blacklist, and greylist.  If type
                    is not empty then this command only displays information for the
                    access lists of this type.
    
            Displays information about one or all access lists.
    
    
    Description:
    
    Access list management

    Here is example output from the display accesslist command after the acquirers white list and creditcards black list were loaded using the load accesslist command.

    Access Lists

Processor Simulation

When the Card Processing application is started, processor and Host Security Module (HSM) simulators are started.

Processor simulators support receiving and responding to these request types:

  • Authorization
  • Financial Transaction
  • Processor Management

The response values for Authorization and Financial Transactions must be configured for each PAN that will be routed to the simulator. If there is no configuration for a received PAN, an invalid card number response code will be returned by the simulator.

A positive response code is always returned for Processor Management requests.

The HSM simulators service the Host Security Module requests which are initiated by Card Processing business state machines. The HSM simulators only support the subset of HSM requests which are actually used by the Card Processing application.

Configuration

The Card Processing application has these separate configuration files:

  • Business State Machines - configure business state machines
  • Connectivity - configure merchants and processors
  • Card Routes - configure card number routing
  • Processor Simulator - configure simulators

The default configuration files are loaded using a ActiveSpaces Transactions component. The ast.properties file contains the following configuration entry.

#
#   Configuration files associated with this component
#   
#   - businessstatemachines.kcs must be loaded before connectivity.kcs
#
Configuration-Files processor-simulators.kcs, businessstatemachines.kcs, connectivity.kcs, cardroutes.kcs,  security.kcs

The configuration values supported are described in the sections below.

Simulator Configuration

The Simulator configuration has a configuration type of simulator. The following configuration values are supported:

Processor Simulator Configuration
NameTypeDescription
simulators hsmSimulatorsArray ArrayList of simulator configuration List of HSM simulator configuration

Simulator configuration data contains the following values:

Simulator Configuration
NameTypeDescription
nodenameStringStart simulator on this node
nameStringSimluator name
descriptionStringSimluator description
listenerPortLongListener port number
jposPackagerNameStringJPOS packager name
jposChannelNameStringJPOS channel name
enableTraceBooleanTrue to enable simulator tracing
cardsArrayList of card entry configuration

A Card Entry configuration contains the following values:

Card Entry Configuration
NameTypeDescription
cardNumberStringCard number (PAN)
responseCodeStringResponse code to return for this card
responseDescriptionStringResponse description to return for this card

HSM simulator configuration data contains the following values:

HSM Simulator Configuration
NameTypeDescription
nodenameStringStart simulator on this node
nameStringSimulator name
portLongListener port number
enableTraceBooleanTrue to enable simulator tracing

Connectivity

The Card Processing connectivity configuration has a configuration type of connectivity. The following configuration values are supported:

Connectivity Configuration
NameTypeDescription
merchantsArrayList of merchant configuration
processorsArrayList of processor configuration
hostSecurityModulesArrayList of Host Security Module configuration
processorSignonMaximumRetriesLongHow many times to retry failed processor signon commands
processorRetryIntervalMillisecondsLongHow long to wait between retry attempts
processorResponseTimeoutMillisecondsLongHow long to wait for signon/signoff responses
zonePINKeyExpirationTimeoutSecondsLongHow long to wait before an HSM Zone PIN Key expires

A Merchant configuration contains the following values:

Merchant Configuration
NameTypeDescription
nodenameStringStart merchant listener on this node
nameStringMerchant name
descriptionStringMerchant description
listenerPortLongListener port number
jposPackagerNameStringJPOS packager name
jposChannelNameStringJPOS channel name
mapperFactoryClassNameStringOptional fully qualified factory class name to create message mappers

A Processor configuration contains the following values:

Processor Configuration
NameTypeDescription
nameStringProcessor name
descriptionStringProcessor description
signonPolicyEnumEnable or disable automatic signon to network processors
endpointsArrayList of processor endpoint configuration, in priority order

A Processor Endpoint configuration contains the following values:

Processor Endpoint Configuration
NameTypeDescription
nameStringEndpoint name
nodeNameStringStart endpoint on this node
descriptionStringEndpoint description
hostStringHost name
portLongPort number
numberOfSessionsIntegerNumber of sessions to open to processor. Default value is 1.
jposPackagerNameStringJPOS packager name
jposChannelNameStringJPOS channel name
mapperFactoryClassNameStringOptional fully qualified factory class name to create message mappers

A Host Security Module configuration contains the following values:

Host Security Module Configuration
NameTypeDescription
nameStringHost Security Module (HSM) service name
descriptionStringHost Security Module (HSM) service description
zoneMasterKeyStringHost Security Module (HSM) Zone Master Key
sessionsArrayList of configured HSM sessions

A Host Security Module Session configuration contains the following values:

Host Security Module Session Configuration
NameTypeDescription
nameStringSession name
descriptionStringEndpoint description
hostStringThe Host Security Module host name
portLongThe Host Security Module port number
priorityLongThe Session priority
connectionRetryCountLongThe number of times to retry connection establishment
connectionRetryIntervalSecondsLongThe connection retry interval
messageHeaderLengthLongThe Host Security Module protocol message header length

Card Routes

The Card Processing card routes configuration has a configuration type of cardroutes. The following configuration values are supported:

Card Routes Configuration
NameTypeDescription
cardRoutesArrayList of card routes

A Card Route configuration contains the following values:

Card Route Configuration
NameTypeDescription
rangeBeginStringBeginning of the card number range
rangeEndStringEnd of the card number range
lengthlongCard number length
processorsArrayPriority list of processors to use for this card range

Business State Machines

The Business State Machines configuration has a configuration type of businessstatemachines. The following configuration values are supported:

Business State Machines Configuration
NameTypeDescription
businessStateMachinesArrayList of Business State Machine configuration
partitionsArrayList of Partition configuration

A Business State Machine configuration contains the following values:

Business State Machine Configuration
NameTypeDescription
mtiStringMessage type indicator
factoryClassNameStringFully qualified class name for factory to create business state machine processes
stateMachineVersionStringVersion of the state machine to use
maximumDurationMillisecondsLongMaximum duration of a business state machine process
descriptionStringBusiness state machine description
acquirerWhiteListNameStringName of the white list used by the business state machine
creditCardBlackListNameStringName of the black list used by the business state machine
creditCardGreyListNameStringName of the grey list used by the business state machine

A Partition configuration contains the following values:

Partition Configuration
NameTypeDescription
nameStringPartition name
nodeListArrayNames of the nodes that host the partition

Merchant Profile

Merchant profile data is bulk loaded into the application using a CSV file format and the load merchant administration command.

The Merchant profile data contains the following values:

Merchant Profile
NameTypeDescription
Merchant15 byte IntegerMerchant identifier
Terminal8 char StringTerminal identifier

The syntax of the profile file is:

#
#   Comment lines start with a #
#
<merchant identifier>,<terminal identifier>
<merchant identifier>,<terminal identifier>
   ...

Merchant profile must be loaded on the server. The command sequence to do this using the ActiveSpaces Transactions development appliance is shown below. The profile data loaded is the acme.csv file.

sftp guest@kabira-server.local
Connecting to kabira-server.local...
guest@kabira-server.local's password: 
sftp> put acme.csv
Uploading acme.csv to /home/guest/acme.csv
acme.csv                                      100%  300     0.3KB/s   00:00    
sftp> bye
Muir-Beach >> ssh guest@kabira-server.local
guest@kabira-server.local's password: 

   ...

administrator servicename=A load merchant filename=~/acme.csv

White and Black Lists

The Card Processing application uses white and black lists to determine if a message should be forwarded to a card processor.

The Card Processing white list contains the identification codes of the acquirers supported by the application. The Card Processing application rejects the message if the acquirer identification code in the message (field 32) does not exist in the white list.

The Card Processing black list contains credit cards that have been black listed. The Card Processing application rejects the message if the PAN in the message (field 2) exists in the black list.

White list and black list data is bulk loaded into the application using a text file and the load accesslist administration command.

The white list data contains the following values:

Acquirer White List
NameTypeDescription
AcquirerStringAcquirer identification code

The black list data contains the following values:

Credit Card Black List
NameTypeDescription
PANStringPrimary account number

The syntax of the white and black list files is:

#
#   One identifier per line.
#   Comment lines start with a #
#   Blank lines and duplicate entries are not allowed.
#
<identifier>
   ...

White and black list data files must be loaded on the server so that the file can be read by the load accesslist command. The command sequence to do this using the development appliance is shown below. In this example the white list data file, whitelist.txt, is ftp'ed to the server machine (i.e. the development appliance) so that it can be read by the load accesslist command.

sftp guest@kabira-server.local
Connecting to kabira-server.local...
guest@kabira-server.local's password:
sftp> put whitelist.txt
Uploading whitelist.txt to /home/guest/whitelist.txt
whitelist.txt                                 100%  300     0.3KB/s   00:00
sftp> bye
Muir-Beach >> ssh guest@kabira-server.local
guest@kabira-server.local's password:

   ...

administrator servicename=A load accesslist name=acquirers type=whitelist filename=/home/guest/whitelist.txt

The names assigned to white and black lists correspond to the acquirerWhiteListName and creditCardBlackListName fields in the Business_State_Machines configuration. The Card Processing business state machines reject messages if any of their configured white and black lists have not been loaded. The audit accesslist administration command can be used to check if any white and black lists have not been loaded.

Grey List

The Card Processing application uses grey list to enrich the message with a corresponding rating that is passed on to the card processor for fraud analysis (if desired).

The Card Processing grey list contains credit cards that have been grey listed. The Card Processing application enriches the message with the associated rating (field 119) if the PAN in the message (field 2) exists in the grey list.

Grey list is bulk loaded into the application using a text file and the load accesslist administration command.

The grey list data contains the following values:

Credit Card Grey List
NameTypeDescription
PAN RATINGString StringPrimary account number Grey list rating value

The syntax of the grey list file is:

#
#   One entry per line.
#   Comment lines start with a #
#   Blank lines and duplicate entries are not allowed.
#
<identifier> <rating>
   ...

The names assigned to grey lists correspond to the creditCardGreyListName field in the Business_State_Machines configuration. The Card Processing business state machines reject messages if their configured grey lists have not been loaded. The audit accesslist administration command can be used to check if the grey lists have not been loaded.

Merchant Requests

The easiest way to send merchant requests to the application is to use a telnet client. By default, the merchant listener is configured to accept XML-encoded ISO 8583 messages.

The target processor must be signed on before any request is sent, or the request will fail with an error. See the Administration section for details on how to signon a processor.

Authorization, Merchant Key Exchange, and Financial Transaction requests are supported from merchants by Card Processing.

Examples of sending these requests are below.

Authorization Request

Here is the encoding of an example 0100 (authorization) request:

  • field id 0 - MTI - 0100
  • field id 2 - PAN - 4111111111111111
  • field id 3 - Processing Code - 003000
  • field id 4 - Transaction Amount - 100
  • field id 7 - Transmission Date & Time - 0831115901 (Aug 31 11:59:01)
  • field id 11 - System Trace Audit Number (STAN) - 123456
  • field id 32 - Acquiring Institution Identification Code - 12345
  • field id 41 - Card Acceptor Terminal Identification - 00000001
  • field id 42 - Card Acceptor Identification Code - 000000000000001

Here is the decoding of the 0110 response:

  • field id 0 - MTI - 0110
  • field id 2 - PAN - 4111111111111111
  • field id 3 - Processing Code - 003000
  • field id 4 - Transaction Amount - 100
  • field id 7 - Transmission Date & Time - 0831115901 (Aug 31 11:59:01)
  • field id 11 - System Trace Audit Number (STAN) - 123456
  • field id 32 - Acquiring Institution Identification Code - 12345
  • field id 39 - Response Code - 00
  • field id 41 - Card Acceptor Terminal Identification - 00000001
  • field id 42 - Card Acceptor Identification Code - 000000000000001
  • field id 48 - Network Information - 1234 1234123456789012345
  • field id 124 - Transaction Qualifier - 01
  • field id 125 - Personal Use Field Code - Transaction Approved

A sample telnet session is shown below that sends the 0100 request defined above.

telnet kabira-server.local 10050
Escape character is '^]'.
<isomsg>
   <field id="0" value="0100"/>
   <field id="2" value="4111111111111111"/>
   <field id="3" value="003000"/>
   <field id="4" value="100"/>
   <field id="7" value="0831115901"/>
   <field id="11" value="123456"/>
   <field id="32" value="12345"/>
   <field id="41" value="00000001"/>
   <field id="42" value="000000000000001"/>
</isomsg>
<isomsg>
  <!-- org.jpos.iso.packager.XMLPackager -->
  <field id="0" value="0110"/>
  <field id="2" value="4111111111111111"/>
  <field id="3" value="003000"/>
  <field id="4" value="100"/>
  <field id="7" value="0831115901"/>
  <field id="11" value="123456"/>
  <field id="32" value="12345"/>
  <field id="39" value="00"/>
  <field id="41" value="00000001"/>
  <field id="42" value="000000000000001"/>
  <field id="48" value="1234  1234123456789012345"/>
  <field id="124" value="01"/>
  <field id="125" value="Transaction Approved"/>
</isomsg>

Merchant Key Exchange Request

Here is the encoding of an example 0800 (Dynamic Key Exchange) request:

  • field id 0 - MTI - 0800
  • field id 7 - Transmission Date & Time - 0831115901 (Aug 31 11:59:01)
  • field id 11 - System Trace Audit Number (STAN) - 123456
  • field id 32 - Acquiring Institution Identification Code - 12345
  • field id 37 - Retrieveal Reference Number - 123456789012
  • field id 42 - Card Acceptor Identification Code - 000000000000001
  • field id 53 - Security Related Control Information - 1234567890123456
  • field id 59 - Transport Data - 000000000000001 (merchant identifier)
  • field id 70 - Network Management Information Code - 000
  • field id 96 - Message Security Key - 12345678
  • field id 100 - Receiving Institution Identification Code - 12345678901
  • field id 120 - Triple DES Key Data - 0123456789abcdef0123456789abcdef0123456789abcdef
  • field id 127 - Version Indicator - 00000

Here is the decoding of the 0810 Dynamic Key Exchange response:

  • field id 0 - MTI - 0810
  • field id 7 - Transmission Date & Time - 0831115901 (Aug 31 11:59:01)
  • field id 11 - System Trace Audit Number (STAN) - 123456
  • field id 32 - Acquiring Institution Identification Code - 12345
  • field id 37 - Retrieveal Reference Number - 123456789012
  • field id 39 - Response Code - 00
  • field id 42 - Card Acceptor Identification Code - 000000000000001
  • field id 53 - Security Related Control Information - 1234567890123456
  • field id 59 - Transport Data - 000000000000001
  • field id 70 - Network Management Information Code - 000
  • field id 96 - Message Security Key - 12345678
  • field id 100 - Receiving Institution Identification Code - 12345678901
  • field id 120 - Triple DES Key Data - 0123456789abcdef0123456789abcdef0123456789abcdef
  • field id 125 - Personal Use Field Code - Transaction Approved
  • field id 127 - Version Indicator - 00000

A sample telnet session is shown below that sends the 0800 request defined above.

telnet kabira-server.local 10050
Escape character is '^]'.

<isomsg>
  <field id="0" value="0800"/>
  <field id="7" value="0831115901"/>
  <field id="11" value="123456"/>
  <field id="32" value="12345"/>
  <field id="37" value="123456789012"/>
  <field id="42" value="000000000000001"/>
  <field id="53" value="1234567890123456"/>
  <field id="59" value="000000000000001"/>
  <field id="70" value="000"/>
  <field id="96" value="12345678"/>
  <field id="100" value="12345678901"/>
  <field id="120" value="0123456789abcdef0123456789abcdef0123456789abcdef"/>
  <field id="127" value="00000"/>
</isomsg>
<isomsg>
  <!-- org.jpos.iso.packager.XMLPackager -->
  <field id="0" value="0810"/>
  <field id="7" value="0831115901"/>
  <field id="11" value="123456"/>
  <field id="32" value="12345"/>
  <field id="37" value="123456789012"/>
  <field id="39" value="00"/>
  <field id="42" value="000000000000001"/>
  <field id="53" value="1234567890123456"/>
  <field id="59" value="000000000000001"/>
  <field id="70" value="000"/>
  <field id="96" value="12345678"/>
  <field id="100" value="12345678901"/>
  <field id="120" value="0123456789abcdef0123456789abcdef0123456789abcdef"/>
  <field id="125" value="Transaction Approved"/>
  <field id="127" value="00000"/>
</isomsg>

Financial Transaction Request

Here is the encoding of an example 0200 (Financial Transaction) request:

  • field id 0 - MTI - 0200
  • field id 2 - PAN - 4111111111111111
  • field id 3 - Processing Code - 003000
  • field id 4 - Transaction Amount - 100
  • field id 7 - Transmission Date & Time - 0831115902 (Aug 31 11:59:02)
  • field id 11 - System Trace Audit Number (STAN) - 123457
  • field id 32 - Acquiring Institution Identification Code - 12345
  • field id 41 - Card Acceptor Terminal Identification - 00000002
  • field id 42 - Card Acceptor Identification Code - 000000000000001
  • field id 52 - PIN Data = 12345

Here is the decoding of the 0210 response:

  • field id 0 - MTI - 0210
  • field id 2 - PAN - 4111111111111111
  • field id 3 - Processing Code - 003000
  • field id 4 - Transaction Amount - 100
  • field id 7 - Transmission Date & Time - 0831115902 (Aug 31 11:59:02)
  • field id 11 - System Trace Audit Number (STAN) - 123457
  • field id 32 - Acquiring Institution Identification Code - 12345
  • field id 38 - Approval Code - 123456
  • field id 39 - Response Code - 00
  • field id 41 - Card Acceptor Terminal Identification - 00000002
  • field id 42 - Card Acceptor Identification Code - 000000000000001
  • field id 48 - Network Information - 1234 1234123456789012345
  • field id 124 - Transaction Qualifier - 01
  • field id 125 - Personal Use Field - Transaction Approved

A sample telnet session is shown below that sends the 0200 request defined above.

telnet kabira-server.local 10050
Escape character is '^]'.
<isomsg>
   <field id="0" value="0200"/>
   <field id="2" value="4111111111111111"/>
   <field id="3" value="003000"/>
   <field id="4" value="000000000100"/>
   <field id="7" value="0831115902"/>
   <field id="11" value="123457"/>
   <field id="32" value="12345"/>
   <field id="38" value="123456"/>
   <field id="41" value="00000002"/>
   <field id="42" value="000000000000001"/>
   <field id="52" value="1234567890123456"/>
</isomsg>
<isomsg>
  <!-- org.jpos.iso.packager.XMLPackager -->
  <field id="0" value="0210"/>
  <field id="2" value="4111111111111111"/>
  <field id="3" value="003000"/>
  <field id="4" value="100"/>
  <field id="7" value="0831115902"/>
  <field id="11" value="123457"/>
  <field id="32" value="12345"/>
  <field id="38" value="123456"/>
  <field id="39" value="00"/>
  <field id="41" value="00000002"/>
  <field id="42" value="000000000000001"/>
  <field id="48" value="1234  1234123456789012345"/>
  <field id="124" value="01"/>
  <field id="125" value="Transaction Approved"/>
</isomsg>