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.
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.
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:
StandardVersion
OBJECT_TYPE
Paycode
PrcC
LUID
PrcM
PaydataC
DateS
DateE
SHS{OD}
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 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.
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.
X9.59 signed elements in a sample tagged signed format:
<x9.59v-doc> <stdvsn>nnn... <objtype>nnn... <paycode>nnn... <prcc>nnn... <luid>nnn... <prcm>nnn... <paydatac>nnnn.nn:nnn <dates>nnn.. <datee>nnn... <shs>hhhhh... </x959v-doc> <sig>hhh....:hhh....