X9.59 Payment Card Process


X9.59 defines the signed data elements that are necessary for preserving the integrity of the financial infrastructure. The consumer originates and digitally signs the data elements. The consumer's financial institution (CFI), responsible for execution of the financial transaction, verifies the digital signature (providing end-to-end security and integrity).

The payment-card model maps the signed X9.59 data elements into a (ISO8583) payment-card authorization request. When a merchant receives a X9.59 payment object, 1) it is mapped into an authorization request, 2) transmitted to the acquiring processor (i.e. merchant financial institution or MFI), 3) who then forwards it to the issuing processor (i.e.consumer's financial institution or CFI). When the merchant receives an approved authorization response from its acquiring processor (i.e. MFI), the merchant can be assured of transfer of funds.

The consumer's financial institution (CFI) defines digital signature only accounts. It is not necessary to hide such account numbers since transactions on the account are only valid when the consumer's digital signature is included.

The CFI performs consumer digital signature verification on the transaction using a copy of the consumer's public key that has been registered and stored in the consumer's account record.

A signed tagged-document format is also included in this description.

Definitions for Payment Card Process

CFI = issuer
The Consumer's Financial Institution is referred to as the card issuing bank, or issuer, defined in X9.24 as "the institution or its agent that issues the identification card to the card holders."
MFI = acquirer
The Merchant's Financial Institution is referred to as the acquiring bank, or acquirer, defined in X9.24 as "the institution or its agent that receives from the card acceptor the data relating to the transaction."
Merchant = card acceptor
defined in X9.24 as the "party accepting the card and presenting transaction data to the acquirer."
Consumer = card holder.
PayMech = Bin
The PRC for this example is based on the credit card bank identification number, also called the IIN or issuer identification number as defined in ISO 7812.
secure hash standard (FIPS-180)
ANSI X9 31-2: 1996, Public Key Cryptography Using Reversible Algorithms for the Financial Services Industry, The Secure Hash Algorithm -1 (SHA-1).
digital signature standard (FIPS-186)
ANSI X9 31-1: 1996, Public Key Cryptography Using Reversible Algorithms for the Financial Services Industry, The Digital Signature Algorithm (DSA)X9.30-1
ANSI X9.62: (Draft) Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)

Overview of Consumer Purchase

The consumer is provided product details, merchant supported payment options, and merchant-id (possibly on a CDROM or WEB-page). X9.59 is designed so that a transaction can possibly be completed in a single round-trip.

X9.59 Data Elements

The X9.59 signed payment elements:

   StandardVersion    X9.59 protocol version
   Paycode            payment instructions to merchant
   PrcC               customer account number
   LUID               (customer) locally unique identifier
   PrcM               merchant account number/id
   PaydataC           currency type and transaction amount
   DateS              transaction date/time
   DateE              account expiration
   SHS{OD}            hash of order detail
   DSS{VD}            digital signature of X9.59 signed elements

The X9.59 addenda field:

   StandardVersion    X9.59 protocol version
   Paycode            payment instructions to merchant
   LUID               (customer) locally unique identifier
   DateS              transaction date/time
   SHS{OD}            hash of order detail
   DSS{VD}            digital signature of X9.59 signed elements

Components of typical merchant->acquirer/MFI authorization message:

Components of 8583 authorization request message:

Note: most current interchange implementations have differences from the 8583 standards definition.


Those X9.59 signed elements that don't have interchange equivalents, but are necessary for the integrity of the transaction are forwarded to the CFI in X9.15 and interchange/8583 X9.59 addenda fields.

Prior to signing the X9.59 data elements, the consumer has completed selecting items to be purchased. The consumer creates an order detail document specifying the selected items to be purchased as well as total amounts (included misc. charges like taxes and shipping). The consumer then is able to compute the hash of the order detail document.

The mapping between the X9.59 signed elements and the merchant to acquirer/MFI authorization request message is:

   PrcC:             card number and card type
   PrcM:             merchant id
   PaydataC:         transaction amount
   DateE:            expiration date

The additional items necessary for the integrity of the transaction are:

   StandardVersion    X9.59 protocol version
   OBJECT_TYPE        type of message
   Paycode            payment instructions to merchant
   LUID               locally unique id
   DateS              date of transaction
   SHS{OD}            SHS hash of order detail
   DSS{VD}            digital signature of the signed elements

StandardVersion is 2 bytes. It is not necessary to transmit OBJECT_TYPE since it is a constant Paycode is 2 bytes. The LUID is 2 bytes (2 bytes). DateS is 8-bytes, 7-byte unsiged packed decimal (YYYYMMDDHHMMSS) with an appended zero byte. Secure Hash Standard results in a 160 bit value (or 20 bytes). Digital Signature Standard (DSS) is the private key encryption of the SHS hash that results in two 163-bit numbers, 42 bytes total.

The X9.59 signed payment elements:


These signed elements are specified as being built with ASCII character set.

The consumer will know PrcC, Paycode, PaydataC, DateE, SHS{OD}, and LUID.

It will be necessary for the merchant to supply to the consumer the value to be placed in PrcM. It is believed that PrcM is obtained as part of the order selection phase. This can either be part of the message exchange during an online ordering processing and/or obtained from something like a CDROM (as part of an offline order process).

In the same process that supplies PrcM to the consumer, the payment (&/or card) types that the merchant can validly process are also supplied.

After formatting and signing the X9.59 signed data elements, the order detail, the X9.59 signed data elements and the X9.59 digital signature are transmitted to the merchant

The merchant receives the X9.59 signed data elements and places PrcC, PrcM, PaydataC, and DateE in the standard acquiring authorization request record:

   PrcC:             card number and card type
   PrcM:             merchant id
   PaydataC:         transaction amount
   DateE:            expiration date

The remaining signed data elements are formated and placed in the X9.59 addenda field.

   StandardVersion     16-bit octet string
   Paycode             16-bit octet string
   LUID                16-bit octet string
   DateS               64-bit octet string
   SHS{OD}            160-bit octet string
   DSS{VD}            336-bit octet string

The X9.59 addenda field is transmitted along with the authorization request record to the acquiring processor (MFI). The addenda field is treated as a single 76-byte binary object.

It is not necessary to transmit the OBJECT_TYPE since it is always the same known value.

DateS encodes YYYYMMDDHHMMSS as unsigned 14 packed decimal digits in seven bytes (the eight byte is reserved and set to zero).

The MFI moves the authorization request to appropriately formatted interchange record (8-bit EBCDIC). The 8583 mapping:

   PrcC:         primary account number (bit2)
   PrcM:         card acceptor identification code (bit42)
   PaydataC:     amount, transaction (bit4) and
                  currency code, transaction (bit49)
   DateE:        date, expiration (bit14)

A binary copy of the X9.59 addenda field is then moved into the appropriate interchange record (tentatively: bit-28 255-byte ViSA record, bit-127 100-byte MasterCard record).

When the issuing processor (CFI) receives the authorization request from interchange, it recognizes that it is a X9.59 request (and verifies that the account number is a digital signature only account).

As part of the digital signature verification, the CFI takes PrcC, PrcM, PaydataC, and DateE (from the authorization request); converts them back to ASCII and recreates the the original X9.59 signing format. StandardVersion, Paycode, LUID, DateS, and SHS{OD} binary objects are formatted and moved into the appropriate fields (and the OBJECT_TYPE is filled in). Then the DSS{VD} binary object is verified against the digital signature of the recreated signed elements (using the public key registered in the CFI's account record).



Denial of service attack

Denial of service attacks on merchants by fraudulent consumers presenting invalid account numbers and/or invalid digital signatures.

The merchant will send off an authorization request based on the values in the X9.59 payment object. The merchant will at least incur a service fee for the authorization request (even if the request is denied). The X9.59 transaction only has the CFI performing verification of the X9.59 payment object.

A merchant might wish to prescreen valid consumers with a minimal certificate-based digital signature verification (a consumer digital signature operation verified with a CFI-signed digital certificate that binds the consumer's public key to the CFI's account number or PrcC).

A PrcC/public-key certificate (signed by the CFI or well-known trusted 3rd party) could be appended to a X9.59 payment object. The merchant would verify the signature on the certificate, verify the PrcC in the payment object and (pre-)verify the signature on the signed elements.

Alternatively (for the online/interactive scenario), the merchant might wish to prescreen the consumer earlier in the shopping process.

Credit Card Settlement

In a typical point-of-sale request, a merchant (say a restaurant) will take the customer's credit card and get an authorization for the amount of the bill. The consumer will then sign the credit card receipt and possibly add in a tip. Typically at end of the shift (or end of business day) all the signed receipts will be submitted for "settlement" with their amended values.

When the credit card receipts are presented to the CFI for funds transfer, the CFI matches each receipt electronically to the corresponding authorization request. If the two monetary amounts don't match, then the CFI must resolve the difference between the amount that was authorized and the amount submitted for payment.

The CFI rules for mismatching amounts are quite heuristic and tend to be tied to the business category of the submitting merchant. There are specific rules for restaurants having to do with tips that are added to the bill after authorization. There are other kinds of rules for hotel and rental car merchants.

The purpose of the Paycode field is to provide a vehicle for consumers to explicitly authorize the type of rules that would be used to resolve a difference between the authorized amount and the amount submitted later by the merchant for payment.

Sample X9.59 Tagged Signed Format

X9.59 signed elements in a sample tagged signed format:


is numeric data
is hexadecimal representation of binary data
is the SHS of the order detail document
is the DSS signature of the tagged elements