4uZR4HLRRfEhMdX4WmG/2+sbewTYaCMx4tn/+MNDZlJ89Letbz5kupr0ZekQlPix+pJs
rHzP5YqaMnk5iRBHvwKb5MaxKXGOOef5ms8M5W8lI2d0XPecH4xNBn8BMAJ6iSkZmszo
QfDeWgga48g2tqlA6ifZGp7daDR81lumtGMCvg==
$$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$
#####################################################################
Opaque Key: Same customer session key from CH1 passed through CM1
for ID and Transaction
#####################################################################
Opaque Section Contents (from CM.6):
server-date: 19950121100706.nnn
amount: usd 10.00
order-id: 1231-3424-234242
card*: [from successful BC4]
response-code: failure/success/etc.
swseverity: fatal/warning
swmessage; Tells CyberApp that it is obsolete. Display this
text to the user. [only present if SWSeverity present]
message;
Free text of the error/success condition.
This text is to be displayed to the customer
by the CyberCash application...
#####################################################################
Signature is of the following fields: no signature
#####################################################################
Explanation:
Opaque section optional because the CH1 to the merchant can fail due
to bad order-id, date, wrong merchant-ccid, etc., etc. So the
server may not be involved at all in which case there is no
mechanism for generating a secure opaque section. (It could even
be that merchant attempt to contact the server times out.)
If transaction makes it through server (via CM*) then
Response-Code at top level should mirror response-code to
merchant from server. (Hopefully the same as the
response-code to customer from server but the merchant can't
tell that.)
Note that there can be two messages, one from merchant and one
from the server.
4.4 Merchant Credit Card Purchasing Messages
The merchant presents credit card purchases, makes adjustments, and
the like via the CM* series. In general, the credit card cycle is
one of getting authorization for a purchase, then capturing the
purchase in a batch for clearance, then performing the clearance. It
is also possible to void a capture (i.e., remove an item from a
batch), and process credits (returns). (See section 5.1.)
Authorizations always come from an acquirer via the response to a CM1
or CM2 message. If capture is being performed by the acquirer or some
entity between the CyberCash server and the acquirer, this is done
via a CM3 or CM2 message depending on the arrangement between the
merchant and the entity doing the capture. Returns (credits) are
handled via message CM5. Message CM4 is provided for voiding a
capture or return before the batch is cleared. CM6 is the message
format used for responses to all the other CM* messages.
An MM* series has also been implemented for purely merchant
originated CyberCash charges as described in section 3.4.7
Current credit card dispute resolution systems assume that the
merchant knows the card number. Thus, to work with these systems,
special bypass messages have been set up that allow the merchant to
obtain, for a particular transaction, the information that CyberCash
otherwise goes to lengths to hide from the merchant. See sections
3.4.8 and 3.4.9. This makes the obtaining os such information by the
merchant an auditable event.
Many present day merchants operate in a "terminal capture" mode where
the authorizations are captured by the merchant and the merchant
later submits the settlement batch. Messages have been defined and
are being implemented so that such merchant captured batches can be
submitted via CyberCash.
4.4.1 CM1 - auth-only
Description: This message is used by the merchant to perform an
authorization operation on the credit card sent in by the
customer.
#####################################################################
Sender: MerchantApp
Receiver: CyberServer
#####################################################################
Sample Message:
$$-CyberCash-0.8-$$
merchant-ccid: ACME-69
merchant-transaction: 123123
merchant-date: 19950121100705.nnn
merchant-cyberkey: CC1001
cyberkey: CC1001
opaque:
EDD+b9wAfje5f7vscnNTJPkn1Wdi7uG3mHi8MrzLyFC0dj7e0JRjZ2PmjDHuR81kbhqb
nX/w4uvsoPgwM5UJEW0Rb9pbB39mUFBDLPVgsNwALySeQGso0KyOjMxNs1mSukHdOmDV
4uZR4HLRRfEhMdX4WmG/2+sbewTYaCMx4tn/+MNDZlJ89Letbz5kupr0ZekQlPix+pJs
rHzP5YqaMnk5iRBHvwKb5MaxKXGOOef5ms8M5W8lI2d0XPecH4xNBn8BMAJ6iSkZmszo
QfDeWgga48g2tqlA6ifZGp7daDR81lumtGMCvg==
merchant-opaque:
6BVEfSlgVCoGh1/0R+g1C143MaA6QLvKpEgde86WWGJWx45bMUZvaAu4LVeqWoYCqSGf
aWKUF7awol0h1i1jtgieyAcXB8ikvRJIsupSAwsRMyoNlekR6tucvfv/622JY7+n7nGO
dGbMzP0GJImh2DmdPaceAxyOB/xOftf6ko0nndnvB+/y2mFjdUGLtFQP/+3bTpZttZXj
j7RO1khe1UrAIk2TGQJmNw+ltsu0f42MgsxB8Q31vjPtoiPi5LEmD0Y4jlpJ7Jg2Ub84
F9vJhYpmzNkdiJUe83Hvo/xfJRbhafJpXFEsUZwQK0jU1ksU6CQd2+CPBB+6MxtsHoxJ
mjD6ickhd+SQZhbRCNerlTiQGhuL4wUAxzGh8aHk2oXjoMpVzWw2EImPu5QaPEc36xgr
mNz8vCovDiuy3tZ42IGArxBweasLPLCbm0Y=
$$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$
#####################################################################
Merchant-Opaque Section Contents:
type: auth-only
order-id: 12313424234242
merchant-amount: usd 10.00
pr-hash: 7Tm/djB05pLIw3JAyy5E7A==
pr-signed-hash:
a/0meaMHRinNVd8nq/fKsYg5AfTZZUCX0S3gkjAhZTmcrkp6RZvppmDd/P7lboFLFDBh
Ec0oIyxWeHfArb3OtkgXxJ7qe0Gmm/87jG5ClGnpBnw0dY7qcJ6XoGB6WGnD
id: myCyberCashID
transaction: 78784567
date: 19950121100505.nnn
merchant-signature:
v4qZMe2d7mUXztVdC3ZPMmMgYHlBA7bhR96LSehKP15ylqR/1KwwbBAX8CEqns55UIYY
GGMwPMGoF+GDPM7GlC6fReQ5wyvV1PnETSVO9/LAyRz0zzRYuyVueOjWDlr5
#####################################################################
merchant-opaque key is generated from the CyberCash encrypting public
key identified in merchant-cyberkey.
Customer opaque section (Opaque) - see CH1.
#####################################################################
Opaque Section Contents & Signature: (exactly as in CH1)
swversion: 0.8win
amount: usd 10.00
card*: [from successful BC4 (includes card-expiration-date,
card-number, and card-salt)]
signature:
48SBKUfojyC9FDKCwdCYNvucgiDxYO9erZW4QndIXZRyheTHXH8OeIhwUkyLmgQSD/UK
+IX9035/jUkdNPOxUQq9y/beHS1HU9Fe0wlzfXYRtnjlqvQX+yUfQ4T7eNEs
#####################################################################
merchant-signature is on the following fields: merchant-ccid,
merchant-transaction, merchant-date, merchant-cyberkey, type,
order-id, merchant-amount, pr-hash, pr-signed-hash, id,
transaction, date, cyberkey
Customer Signature: see CH1
#####################################################################
Explanation:
The merchant signature ensures integrity of the majority of the
message. validation of the customer signature ensures that the
customer opaque part was not tampered or replaced.
4.4.2 CM2 - auth-capture
Description: Do authorization and actually enters charge for
clearance. Message just like CM1 except for different
type.
#####################################################################
Sender: MerchantApp
Receiver: CyberServer
#####################################################################
Sample Message:
[exactly the same as CM1 except
type: auth-capture
]
4.4.3 CM3 - post-auth-capture
Description: Captures a charge previously authorized. Message is
the same as CM1 except that it also has an authorization-code
field (which is also included in the signature) and the type
is different.
#####################################################################
Sender: MerchantApp
Receiver: CyberServer
#####################################################################
Sample Message:
$$-CyberCash-0.8-$$
merchant-ccid: ACME-012
merchant-transaction: 123123
merchant-date: 19950121100705.nnn
merchant-cyberkey: CC1001
cyberkey: CC1001
opaque:
EDD+b9wAfje5f7vscnNTJPkn1Wdi7uG3mHi8MrzLyFC0dj7e0JRjZ2PmjDHuR81kbhqb
nX/w4uvsoPgwM5UJEW0Rb9pbB39mUFBDLPVgsNwALySeQGso0KyOjMxNs1mSukHdOmDV
4uZR4HLRRfEhMdX4WmG/2+sbewTYaCMx4tn/+MNDZlJ89Letbz5kupr0ZekQlPix+pJs
rHzP5YqaMnk5iRBHvwKb5MaxKXGOOef5ms8M5W8lI2d0XPecH4xNBn8BMAJ6iSkZmszo
QfDeWgga48g2tqlA6ifZGp7daDR81lumtGMCvg==
merchant-opaque:
6BVEfSlgVCoGh1/0R+g1C143MaA6QLvKpEgde86WWGJWx45bMUZvaAu4LVeqWoYCqSGf
aWKUF7awol0h1i1jtgieyAcXB8ikvRJIsupSAwsRMyoNlekR6tucvfv/622JY7+n7nGO
dGbMzP0GJImh2DmdPaceAxyOB/xOftf6ko0nndnvB+/y2mFjdUGLtFQP/+3bTpZttZXj
j7RO1khe1UrAIk2TGQJmNw+ltsu0f42MgsxB8Q31vjPtoiPi5LEmD0Y4jlpJ7Jg2Ub84
F9vJhYpmzNkdiJUe83Hvo/xfJRbhafJpXFEsUZwQK0jU1ksU6CQd2+CPBB+6MxtsHoxJ
mjD6ickhd+SQZhbRCNerlTiQGhuL4wUAxzGh8aHk2oXjoMpVzWw2EImPu5QaPEc36xgr
mNz8vCovDiuy3tZ42IGArxBweasLPLCbm0Y=
$$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$
#####################################################################
Merchant-Opaque Section Contents:
type: post-auth-capture
authorization-code: a12323
order-id: 1231-3424-234242
merchant-amount: usd 10.00
pr-hash: 7Tm/djB05pLIw3JAyy5E7A==
pr-signed-hash:
a/0meaMHRinNVd8nq/fKsYg5AfTZZUCX0S3gkjAhZTmcrkp6RZvppmDd/P7lboFLFDBh
Ec0oIyxWeHfArb3OtkgXxJ7qe0Gmm/87jG5ClGnpBnw0dY7qcJ6XoGB6WGnD
id: myCyberCashID
transaction: 78784567
date: 19950121100505.nnn
merchant-signature:
vxyEF1ZHn5Rgmtms3H3t/+UB6RAvZQA1AdddjvlS0H75N1x83FyJuh8V9Ok6t4EUQQZ6
Mnptzc6phJi3Ar0s0oumELsdc8upJdXpNpJV021PGJXfDKfHP0heJIWLodXr
#####################################################################
merchant-opaque key is generated from the CyberCash encrypting public
key identified in merchant-cyberkey.
Customer opaque section (Opaque) - see CH1.
#####################################################################
Opaque Section Contents & Signature: (exactly as in CH1)
swversion: 0.8win
amount: usd 10.00
card*: [from successful BC4 (includes card-salt, card-number,
and card-expiration)]
signature:
48SBKUfojyC9FDKCwdCYNvucgiDxYO9erZW4QndIXZRyheTHXH8OeIhwUkyLmgQSD/UK
+IX9035/jUkdNPOxUQq9y/beHS1HU9Fe0wlzfXYRtnjlqvQX+yUfQ4T7eNEs
#####################################################################
merchant-signature is on the following fields: merchant-ccid,
merchant-transaction, merchant-date, merchant-cyberkey, type,
authorization-code, order-id, merchant-amount, pr-hash,
pr-signed-hash, id, transaction, date, cyberkey
#####################################################################
Explanation:
The merchant signature ensures integrity of the majority of the
message validation of the customer signature ensures that the
customer opaque part was not tampered or replaced.
4.4.4 CM4 - void
Description: Voids out a charge/return if received before
clearance. Message is the same as CM1 except that it also has
a retrieval-reference-number field (which is also included in the
signature) and the type is different.
#####################################################################
Sender: MerchantApp
Receiver: CyberServer
#####################################################################
Sample Message:
$$-CyberCash-0.8-$$
merchant-ccid: ACME-012
merchant-transaction: 123123
merchant-date: 19950121100705.nnn
merchant-cyberkey: CC1001
cyberkey: CC1001
opaque:
EDD+b9wAfje5f7vscnNTJPkn1Wdi7uG3mHi8MrzLyFC0dj7e0JRjZ2PmjDHuR81kbhqb
nX/w4uvsoPgwM5UJEW0Rb9pbB39mUFBDLPVgsNwALySeQGso0KyOjMxNs1mSukHdOmDV
4uZR4HLRRfEhMdX4WmG/2+sbewTYaCMx4tn/+MNDZlJ89Letbz5kupr0ZekQlPix+pJs
rHzP5YqaMnk5iRBHvwKb5MaxKXGOOef5ms8M5W8lI2d0XPecH4xNBn8BMAJ6iSkZmszo
QfDeWgga48g2tqlA6ifZGp7daDR81lumtGMCvg==
merchant-opaque:
6BVEfSlgVCoGh1/0R+g1C143MaA6QLvKpEgde86WWGJWx45bMUZvaAu4LVeqWoYCqSGf
aWKUF7awol0h1i1jtgieyAcXB8ikvRJIsupSAwsRMyoNlekR6tucvfv/622JY7+n7nGO
dGbMzP0GJImh2DmdPaceAxyOB/xOftf6ko0nndnvB+/y2mFjdUGLtFQP/+3bTpZttZXj
j7RO1khe1UrAIk2TGQJmNw+ltsu0f42MgsxB8Q31vjPtoiPi5LEmD0Y4jlpJ7Jg2Ub84
F9vJhYpmzNkdiJUe83Hvo/xfJRbhafJpXFEsUZwQK0jU1ksU6CQd2+CPBB+6MxtsHoxJ
mjD6ickhd+SQZhbRCNerlTiQGhuL4wUAxzGh8aHk2oXjoMpVzWw2EImPu5QaPEc36xgr
mNz8vCovDiuy3tZ42IGArxBweasLPLCbm0Y=
$$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$
#####################################################################
Merchant-Opaque Section Contents:
type: void
retrieval-reference-number: 432112344321
order-id: 1231-3424-234242
merchant-amount: usd 10.00
pr-hash: WATCQuH2q17lRuoxD78YBg==
pr-signed-hash:
8zqw0ipqtLtte0tBz5/5VPNJPPonfTwkfZPbtuk5lqMykKDvThhO0ycrfT7eXrn/hLUC
kXoSctahEVdw1KBJbp0EVr1zVzcN9Aa7m2fJgxNfiisTgIRW+PMaa78rn+Ov
id: myCyberCashID
transaction: 78784567
date: 19950121100505.nnn
Merchant-Signature: lkjladjslkjflsakjflkjsdljflsakjflkjsdljflsakjflkj
flsakjflkjsdljflsakjflkjsdljflsajflksdjflksdjflsdjssf=
#####################################################################
Merchant-Opaque key is generated from the CyberCash encrypting public
key identified in Merchant-CyberKey.
Customer opaque section (Opaque) - see CH1.
#####################################################################
Opaque Section Contents & Signature: (exactly as in CH1)
swversion: 0.8win
amount: usd 10.00
card*: [from successful bc4 (includes card-salt, card-number,
and card-expiration)]
signature:
48SBKUfojyC9FDKCwdCYNvucgiDxYO9erZW4QndIXZRyheTHXH8OeIhwUkyLmgQSD/UK
+IX9035/jUkdNPOxUQq9y/beHS1HU9Fe0wlzfXYRtnjlqvQX+yUfQ4T7eNEs
#####################################################################
merchant-signature is on the following fields: merchant-ccid,
merchant-transaction, merchant-date, merchant-cyberkey, type,
retrieval-reference-number, order-id, merchant-amount, pr-hash,
pr-signed-hash, id, transaction, date, cyberkey
#####################################################################
Explanation:
The merchant signature ensures integrity of the majority of the
message. Validation of the customer signature ensures that the
customer opaque part was not tampered or replaced.
4.4.5 CM5 - return
Description: Reverse a previous charge. Really sort of a negative
charge. Message just like CM1 except for different type.
#####################################################################
Sender: MerchantApp
Receiver: CyberServer
#####################################################################
Sample Message:
[exactly the same as CM1 except
type: return
]
4.4.6 CM6 - charge-action-response
Description: This receipt is given to the merchant as a receipt
for a completed charge action. Indicates success/failure/etc.
#####################################################################
Sender: CyberServer
Receiver: MerchantApp
#####################################################################
Sample Message:
$$-CyberCash-0.8-$$
merchant-ccid: ACME-012
merchant-transaction: 123123
merchant-date: 19950121100705.nnn
opaque:
EDD+b9wAfje5f7vscnNTJPkn1Wdi7uG3mHi8MrzLyFC0dj7e0JRjZ2PmjDHuR81kbhqb
nX/w4uvsoPgwM5UJEW0Rb9pbB39mUFBDLPVgsNwALySeQGso0KyOjMxNs1mSukHdOmDV
4uZR4HLRRfEhMdX4WmG/2+sbewTYaCMx4tn/+MNDZlJ89Letbz5kupr0ZekQlPix+pJs
rHzP5YqaMnk5iRBHvwKb5MaxKXGOOef5ms8M5W8lI2d0XPecH4xNBn8BMAJ6iSkZmszo
QfDeWgga48g2tqlA6ifZGp7daDR81lumtGMCvg==
merchant-opaque:
6BVEfSlgVCoGh1/0R+g1C143MaA6QLvKpEgde86WWGJWx45bMUZvaAu4LVeqWoYCqSGf
aWKUF7awol0h1i1jtgieyAcXB8ikvRJIsupSAwsRMyoNlekR6tucvfv/622JY7+n7nGO
dGbMzP0GJImh2DmdPaceAxyOB/xOftf6ko0nndnvB+/y2mFjdUGLtFQP/+3bTpZttZXj
j7RO1khe1UrAIk2TGQJmNw+ltsu0f42MgsxB8Q31vjPtoiPi5LEmD0Y4jlpJ7Jg2Ub84
F9vJhYpmzNkdiJUe83Hvo/xfJRbhafJpXFEsUZwQK0jU1ksU6CQd2+CPBB+6MxtsHoxJ
mjD6ickhd+SQZhbRCNerlTiQGhuL4wUAxzGh8aHk2oXjoMpVzWw2EImPu5QaPEc36xgr
mNz8vCovDiuy3tZ42IGArxBweasLPLCbm0Y=
$$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$
#####################################################################
Merchant-Opaque Key: Session key same as that of CM1/2/3/4/5 for
same Merchant-Transaction and Merchant-CCID.
Opaque Key: Same customer session key from CH1 passed through CM*
for ID and Transaction
#####################################################################
Merchant-Opaque Section Contents:
type: charge-action-response
server-date: 19950121100706.nnn
action-code: XXX [per ISO 8583]
response-code: failure/success/etc.
order-id: 1231-3424-234242
pr-hash: 7Tm/djB05pLIw3JAyy5E7A==
pr-signed-hash:
8zqw0ipqtLtte0tBz5/5VPNJPPonfTwkfZPbtuk5lqMykKDvThhO0ycrfT7eXrn/hLUC
kXoSctahEVdw1KBJbp0EVr1zVzcN9Aa7m2fJgxNfiisTgIRW+PMaa78rn+Ov
retrieval-reference-number: 432112344321
authorization-code: a12323
card-hash: 7Tm/djB05pLIw3JAyy5E7A==
{
card-prefix: nnxxxx [Returned if merchant is not full-PAN]
}
or
{
card-number: 1234567890123456 [Returned if merchant is full-PAN]
}
expiration-date: 12/34 [always present]
merchant-swseverity: fatal/warning
merchant-swmessage; Message for merchant about out of date
protocol number in $$ start line of merchant message.
merchant-message;
Free text of the error/success condition.
This text is for the merchant from the server...
id: myCyberCashID
transaction: 78784567
date: 19950121100505.nnn
Opaque (Customer) contents:
server-date: 19950121100706.nnn
amount: usd 10.00
order-id: 1231-3424-234242
card*: [from successful BC4]
response-code: failure/success/etc.
swseverity: fatal/warning
swmessage; Tells CyberApp that it is obsolete display this
text to the user. [only present if SWSeverity present]
message;
Free text of the error/success condition.
This text is to be displayed to the customer
by the CyberCash application...
#####################################################################
Signature is of the following fields: no signature
#####################################################################
Explanation:
retrieval-reference-number is needed for voids. authorization-code
is needed for post-auth-capture. These fields are each only
present in the CM6 if they were returned by the bank which
depends on what operation was being done.
card-prefix is first two and last four digits of card-number.
At merchant's bank's discretion the card-number or card-prefix is
returned.
card-hash is really the hash of the full card number and the salt
provided by the customer. card-hash is needed so the merchant
can, if they wish, sort customer transactions by card without
knowing the card number.
card* is the card* fields delivered in the CM* messages being
responded to. They appear in alphabetic order.
server-date duplicated in customer opaque area for security.
{}'s in column one just for clarity of alternatives and do not
actually appear in the message.
[]ed comments appear after some fields.
4.4.7 The MM* Message Series
The CM* message series above is the primary CyberCash credit card
purchase system for securely handling charges from CyberCash
customers. However, merchants, who are authorized by their acquiring
bank to accept such charges, may also receive telephone, mail, and
over-the-counter sales. To avoid any necessity for the merchant to
have a second parallel system to handle these charges, an MM1 through
MM6 message series is defined and has been implemented for these less
secure transactions.
The MM* messages look very similar to the CM* series but the
"customer opaque" section is actually signed by the merchant and no
separate customer CyberCash ID or prior card binding is required.
The MM* message examples are omitted here in the interests of
brevity.
4.4.8 CD1 - card-data-request
Description: Used by merchant to get card-number, etc., if
information needed by merchant to resolve a dispute.
#####################################################################
Sender: MerchantApp
Receiver: CyberServer
#####################################################################
Sample Message:
$$-CyberCash-0.8-$$
merchant-ccid: ACME-69
merchant-transaction: 123123
merchant-date: 19950121100705.nnn
merchant-cyberkey: CC1001
cyberkey: CC1001
opaque:
EDD+b9wAfje5f7vscnNTJPkn1Wdi7uG3mHi8MrzLyFC0dj7e0JRjZ2PmjDHuR81kbhqb
nX/w4uvsoPgwM5UJEW0Rb9pbB39mUFBDLPVgsNwALySeQGso0KyOjMxNs1mSukHdOmDV
4uZR4HLRRfEhMdX4WmG/2+sbewTYaCMx4tn/+MNDZlJ89Letbz5kupr0ZekQlPix+pJs
rHzP5YqaMnk5iRBHvwKb5MaxKXGOOef5ms8M5W8lI2d0XPecH4xNBn8BMAJ6iSkZmszo
QfDeWgga48g2tqlA6ifZGp7daDR81lumtGMCvg==
merchant-opaque:
6BVEfSlgVCoGh1/0R+g1C143MaA6QLvKpEgde86WWGJWx45bMUZvaAu4LVeqWoYCqSGf
aWKUF7awol0h1i1jtgieyAcXB8ikvRJIsupSAwsRMyoNlekR6tucvfv/622JY7+n7nGO
dGbMzP0GJImh2DmdPaceAxyOB/xOftf6ko0nndnvB+/y2mFjdUGLtFQP/+3bTpZttZXj
j7RO1khe1UrAIk2TGQJmNw+ltsu0f42MgsxB8Q31vjPtoiPi5LEmD0Y4jlpJ7Jg2Ub84
F9vJhYpmzNkdiJUe83Hvo/xfJRbhafJpXFEsUZwQK0jU1ksU6CQd2+CPBB+6MxtsHoxJ
mjD6ickhd+SQZhbRCNerlTiQGhuL4wUAxzGh8aHk2oXjoMpVzWw2EImPu5QaPEc36xgr
mNz8vCovDiuy3tZ42IGArxBweasLPLCbm0Y=
$$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$
#####################################################################
Merchant-Opaque Section Contents:
type: card-data-request
password: xyzzy
server-date: 19950121100505.nnn [optional]
order-id: 12313424234242
merchant-amount: usd 10.00
pr-hash: 7Tm/djB05pLIw3JAyy5E7A==
pr-signed-hash:
IV8gWHx1f8eCkWsCsMOE3M8mnTbQ7IBBcEmyGDAwjdbaLu5Qm/bh06OX1npe2d3Hijxy
+X8vKcVE6l6To27u7A7UmGm+po9lCUSLxgtyqyn3jWhHZpc5NZpwoTCf2pAK
id: myCyberCashID
transaction: 78784567
date: 19950121100505.nnn
merchant-signature:
8zqw0ipqtLtte0tBz5/5VPNJPPonfTwkfZPbtuk5lqMykKDvThhO0ycrfT7eXrn/hLUC
kXoSctahEVdw1KBJbp0EVr1zVzcN9Aa7m2fJgxNfiisTgIRW+PMaa78rn+Ov
#####################################################################
merchant-opaque key is generated from the CyberCash encrypting public
key identified in merchant-cyberkey.
Customer opaque section (Opaque) - see CH1.
#####################################################################
Opaque Section Contents & Signature: (exactly as in CH1)
swversion: 0.8win
amount: usd 10.00
card*: [from successful BC4 (includes card-expiration-date,
card-number, and card-salt)]
signature:
48SBKUfojyC9FDKCwdCYNvucgiDxYO9erZW4QndIXZRyheTHXH8OeIhwUkyLmgQSD/UK
+IX9035/jUkdNPOxUQq9y/beHS1HU9Fe0wlzfXYRtnjlqvQX+yUfQ4T7eNEs
#####################################################################
merchant-signature is on the following fields: merchant-ccid,
merchant-transaction, merchant-date, merchant-cyberkey, type,
password, server-date, order-id, merchant-amount, pr-hash,
pr-signed-hash, id, transaction, date, cyberkey
Customer Signature: see CH1
#####################################################################
Explanation:
[see also CM1 explanation]
The merchant may need to know the card involved and other
information in order to resolve a disputed transaction. This
information is all contained in the original CH1 embedded in the
CM1 for the transaction. If the merchant saves the CM1 and other
transaction information, they can send this CD1 message to the
server. While this reduces the pass through confidentiality of
the system, the merchant is then on record as asking for this
particular credit card number and excessive CD1's from a merchant
can be flagged.
password is an extra level of security intended to be manually entered
at the merchant to authorize the unusual action. Server stores a
hash of the merchant-ccid and the password.
4.4.9 CD2 - card-data-response
Description: Respond to CD1 with failure or with success and card
data.
#####################################################################
Sender: CyberServer
Receiver: MerchantApp
#####################################################################
Sample Message:
$$-CyberCash-0.8-$$
merchant-ccid: ACME-012
merchant-transaction: 123123
merchant-date: 19950121100705.nnn
merchant-opaque:
t731/86R72ZLrqHLIf0VG6m3ybvs+dG6K705L8LFKEXgCti0NGjK83CwDsUdiso7U1JP
2Z0BClVHLmhIBY7+QXx5iCEGHy8JKC9IWyNNi2O/OOIDgLeJAkMSZYbNQrSKViY34imS
0s7Q6uDk9wV0fixjvRBuNO2B7urWWsqfkLOYDnHy0RvhyUzYxLrMaTX+/6IkyU5Z0lH3
BXYBUNV8DgitEjgLXmyWuXRDlEBN02yeZgsFRm9GmuBHfCTySm2XqnifizpmKMUa9UiH
onNx9W86fuBdcJF7CJgH5Gct2M/dx/f2VpoRkmeSmWxFrYi8wgtvddSXF9my40NZ8WZz
CEUEvQhcmruopwEeehv+bejc3fDDZ23JKrbhlZ17lSvFR14PKFsi32pXFqTO0ej9GTc5
L6c8nM3tI1qdHNCe0N5f7ASdKS0tYSxAYJLIR6MqPrXjNJEaRx7Vu1odMlkgrzGOV1fo
5w33BQHK3U2h+1e5zYBeHY3ZYG4nmylYYXIye4xpuPN4QU0dGrWZoImYE44QOwjd5ozl
xulPBjj6cpEI/9wTwR3tpkBb4ZfYirxxnoj9JUkPK9Srv9iJ
$$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$
#####################################################################
Opaque Key: session key from CD1.
#####################################################################
Opaque Section Contents:
type: card-data-response
server-date: 19950121100706.nnn
response-code: failure/success/etc.
order-id: 1231-3424-234242
pr-hash: 7Tm/djB05pLIw3JAyy5E7A==
pr-signed-hash:
IV8gWHx1f8eCkWsCsMOE3M8mnTbQ7IBBcEmyGDAwjdbaLu5Qm/bh06OX1npe2d3Hijxy
+X8vKcVE6l6To27u7A7UmGm+po9lCUSLxgtyqyn3jWhHZpc5NZpwoTCf2pAK
card-hash: 7Tm/djB05pLIw3JAyy5E7A==
card-number: 4811123456781234
card-type: visa
card-name: John Q. Public
expiration-date: 01/99
merchant-swseverity: fatal/warning
merchant-swmessage; Message for merchant about out of date
protocol number in $$ start line of merchant message.
merchant-message;
Free text of the error/success condition.
This text is for the merchant from the server...
id: myCyberCashID
transaction: 78784567
date: 19950121100505.nnn
#####################################################################
Signature is of the following fields: no signature.
#####################################################################
Explanation:
This normally returns selected fields from the decoding of the
opaque part of a CH1 as sent to the server in a CD1.
4.5 Utility and Error Messges
A number of utility, status query, and special error reporting
messages have also been found necessary in implementing the CyberCash
system.
It is desirable to be able to test connectivity, roughly synchronize
clocks, and get an initial determination of what client protocol and
software versions are accepted. This is done via the P1 client to
server message and its P2 server to client response.
Clients need to be able to determine the status of earlier
transactions when the client or merchant has crashed during or has
suffered data loss since the transaction. Two transaction query
messages are defined, TQ1 and TQ2. One just queries and the other
also cancels the transaction, if it has not yet completed. The
response to both of these messages is a TQ3 response from the server.
Since the system operates in a query response mode, there are two
cases where special error messages are needed. If a query seems to
be of an undeterminable or unknown type, the UNK1 response error
message is sent. If a response seems to be of an undeterminable or
unknown type or other serious error conditions occur at the client or
merchant which should be logged at the CyberCash server, the DL1 or
DL2 diagnostic log message is submitted by the client or merchant in
question respectively.
4.5.1 P1 - ping
Description: Very light weight check that we have connectivity from
the customer to the server. Does no crypto to minimize
overhead.
#####################################################################
Sender: CyberApp
Receiver: CyberServer
#####################################################################
Sample Message:
$$-CyberCash-0.8-$$
type: ping
id: myCyberCashID [optional]
transaction: 123123213
date: 19950121100505.nnn
$$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$
#####################################################################
Explanation:
id optional as persona may not have been set up yet.
4.5.2 P2 - ping-response
Description: Response to the P1 light weight ping. Does no
crypto to minimize overhead.
#####################################################################
Sender: CyberServer
Receiver: CyberApp
#####################################################################
Sample Message:
$$-CyberCash-0.8-$$
type: ping-response
id: myCyberCashID [if present in P1]
transaction: 12312313
date: 19950121100505.nnn
server-date: 19950121100506.nnn
swseverity: fatal/warning [absent if ok]
swmessage; Tells CyberApp that it is using an obsolete protocol.
Display this text to the user. [only present if SWSeverity
present]
response-code: success/failure/etc.
message;
Free text of the error/success condition.
This text is to be displayed to the sender
by their CyberCash application...
supported-versions: 08.win, 0.81win, 0.8mac
$$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$
#####################################################################
Explanation:
swversion does not appear in P1 for security reasons so
swseverity and swmessage appear only if the server can tell
that things are old from the $$ header protocol version.
supported-versions lets client know as soon as possible what
versions are supported and, by implication, which are not. Does
not compromise security by having client say what version it
is.
4.5.3 TQ1 - transaction-query
Description: Client query to server for Transaction status.
#####################################################################
Sender: CyberApp
Receiver: CyberServer
#####################################################################
Sample Message:
$$-CyberCash-0.8-$$
id: MyCyberCashID
date: 19950121100505.nnn
transaction: 12312314
cyberkey: CC1001
opaque:
VFaztHuj757Jrv+JxZFsHORy/zgkrxhBCu9cPdE04c1NnXzVlGOHygpSl+UGbUvnhkYl
21QQaHkaE3geccRk03cqFYoLNRCclImcsyeIZCgVt+2dJTj1V+E7R7ePQtCj+0gY42+V
L5BWhVtmDQFyg1DdJ6n3S/er6ZuObAjpcAogG+T1Na5dJmrTA1wRMiYVkqhXi2KMYdur
3U47P8ZGUza7W0MST3DgvviN0kVhtmHEnm515mo6NTQdfdxw9WZpy6vMqrBGk2nTgi2c
bnf+muO0+kiNPXVvEzRrO8o=
$$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$
#####################################################################
Opaque Key: generated from CyberCash encryption key identified in
CyberKey
#####################################################################
Opaque Section Contents:
type: transaction-query
swversion: 0.8win
begin-transaction: 1234
end-transaction: 4321
signature:
jJfFsKvOxLaV87gxu7lIPet3wIDwh1H2F61reYC9jmUrS6WAtUVFG9aCNuTEBoMixF0X
vD5oPfyheJRIlnL6i0c4o/bfyO3edKAacmWjTmKt6/4y9p3qgvKkSX8r9aym
#####################################################################
signature is of the following fields: id, date, transaction,
cyberkey, type, swversion, begin-transaction,
end-transaction
#####################################################################
Explanation:
This is a client status query of a previous transaction or
transactions.
begin-transaction and end-transaction can be the same.
4.5.4 TQ2 - transaction-cancel
Description: Client query to server for Transaction
cancellation/status.
#####################################################################
Sender: CyberApp
Receiver: CyberServer
#####################################################################
Sample Message:
$$-CyberCash-0.8-$$
id: MyCyberCashID
date: 19950121100505.nnn
transaction: 12312314
cyberkey: CC1001
opaque:
VFaztHuj757Jrv+JxZFsHORy/zgkrxhBCu9cPdE04c1NnXzVlGOHygpSl+UGbUvnhkYl
21QQaHkaE3geccRk03cqFYoLNRCclImcsyeIZCgVt+2dJTj1V+E7R7ePQtCj+0gY42+V
L5BWhVtmDQFyg1DdJ6n3S/er6ZuObAjpcAogG+T1Na5dJmrTA1wRMiYVkqhXi2KMYdur
3U47P8ZGUza7W0MST3DgvviN0kVhtmHEnm515mo6NTQdfdxw9WZpy6vMqrBGk2nTgi2c
bnf+muO0+kiNPXVvEzRrO8o=
$$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$
#####################################################################
Opaque Key: generated from CyberCash encryption key identified in
CyberKey
#####################################################################
Opaque Section Contents:
type: transaction-cancel
swversion: 0.8win
begin-transaction: 1234
end-transaction: 4321
signature:
kD7DEav2uLQIYMtP9gbhYaBUpB2a5whNwnK2eXbbyTCf56F6dl3DIVf7D8Z4WxbY2YZn
ByRIKeqlhmss7fbdnBiDYmKfOuc+I4bi/Oslml5riaciQhTd2JdHG+PCcHwZ
#####################################################################
signature is of the following fields: id, date, transaction,
cyberkey, type, swversion, begin-transaction, end-transaction
#####################################################################
Explanation:
This is a client attempt to cancel a previous transaction or
transactions.
begin-transaction and end-transaction can be the same.
The transaction-cancel transaction (TQ.2) is defined between the
client and the server. This transaction permits the client to
query the status of an operation and to stop the operation from
occurring if it has not already occurred.
4.5.5 TQ3 - transaction-response
Description: Reports generated by a TQ1 or TQ2
#####################################################################
Sender: CyberServer
Receiver: CyberApp
#####################################################################
Sample Message:
$$-CyberCash-0.8-$$
id: mycybercashid
date: 19950121100505.nnn
transaction: 12312314
server-date: 19950121100505.nnn
opaque:
eFXRL+H0J5q318M21wRdtcbhu9WCyLysQkeF9oIcjtbstymx343bbt0EAtU1gcJaUKJZ
3skgvwrhcxU4bFcE68OPlUXAvLq10I3MczPYPsiGrsU0K4bZtQvDZmn727QQAfONBm5s
s1yjIha+Fj481BJQs0CTYc3ju90lAjCYgirXtnnR6yJXoDO75b7UjthvHSnrTWVZvktX
PvTuUCYzbXSFoYvwFM3Y+yHqSHlmWutYKQpYze8zbUSDQfmwTCJyw3aY2JasZ+xMP/CD
JWbCA+gCLBYCnvzM/ExKTZTFD3xr5JBfNbV4p6CiK6lsfRFD7maAK6TSVnWjwCEJNpOv
fyllfWD04fT7LINQcjJiQK1Pk/912Tk6Q35eRaQZorwv2hnY/7By2OkPyFdAqFL+D0H6
TqzxmdEjEFKxi/PPT1+Cs/Nszy8wZzaGg8iWATfARY6stl+02dDhwOoFXSBNvchlVrcI
IlvhumSIQs29Pntj3DbkYo4IEmmN/qi1vnzld22q7lA1q/CQakyc7jlQUFISx76buqwy
35XiC9Yn8flE4Va14UxMf2RCR1B/XoV6AEd64KwPeCYyOYvwbRcYpRMBXFLyYgWM+ME1
+yp7c66SrCBhW4Q8AJYQ+5j5uyO7uKyyq7OhrV0IMpRDPjiQXZMooLZOifJPmpvJ66hC
VZuWMuA6LR+TJzWUm4sUP9Zb6zMQShedUyOPrtw1vkJXU1vZ5aI8OJAgUcLEitcD+dsY
Df4CzA00fC10POkJ58HZB/pSBfUrHAa+IqMHyZkV/HBi9TjTwmktJi+8T9orXS0jSvor
dMTGWn0ifETy2VXt
$$-CyberCash-End-0QXqLlNxrn4GNQPPk9AO1Q==-$$
#####################################################################
Opaque Key: Session key from TQ1/TQ2 with same Transaction and ID.
#####################################################################
Opaque Section Contents:
type: transaction-response
response-code: success/failure/etc.
message; general free form text message from server to
customer....
swseverity: fatal/warning
swmessage; Message indicating that CyberApp software is obsolete.
May be multiple lines.
report-fee: usd 0.15 [if non-zero]
transaction-1: old-transaction-number
transaction-status-1: success/failure/pending/cancelled/etc.
server-date-1: 19951212125959.nnn
date-1: 19950121100505.nnn
type-1: auth-only/etc.
#####################################################################
Signature is of the following fields: no signature
#####################################################################
Explanation:
Report-fee is the notification that this report cost a fee and is
only present if there is a fee.
There can be multiple transaction for the same transaction number as
there could have been a auth, post-auth-capture, void, etc.
Terms
"original transaction" refers to the payment or other transaction
that is being queried or canceled.
Note: this transaction may not actually reside at the server.
"request" refers to the requesting TQ.2 or TQ.1 message
id: id from the request message
date: date from the request message
transaction: transaction from the request message
server-date: current date/time
type: transaction-response
response-code: response code for request message, can be one of:
"success" means the request message was processed. Does not imply
query or cancellation status of the request.
"failure-hard" means that the request message was not processed
due to being ill-formed or otherwise inoperable.
"failure-swversion" means that the request message was not
processed due to software revision problems.
message: the message applies only to the TQ transaction, not to the
status of the transactions being queried or canceled. The
message is provided according to the response-code as: "success"
- message is omitted. "failure-hard" - use standard hard failure
message. "failure-swversion" - use standard swversion message for
fatal
swseverity: applies to request message
swmessage: applies to request message
-- per query/cancel fields ('N' is a series from 1 to N) --
transaction-N: transaction number of original transaction, or if
the original transaction is not present in server the transaction
number that the query / cancel request refers to
transaction-status-N: status of original transaction, may be one of:
"success" the original transaction was successfully processed.
If request was TQ.2, cancellation is not performed.
"failure" the original transaction was not successfully processed.
If request was TQ.2, cancellation is not performed (however,
there is nothing to cancel, so it's all the same to the customer
app).
"pending" the original transaction is still being processed and
final disposition is not known.
"canceled" the original transaction has been canceled by the server.
Later arrival of the original transaction will not be processed,
but will be returned with a "failure-canceled" returned.
server-date-1: server-date field from original transaction or
omitted if original transaction is not present in the server"
date-1: date field from original transaction or omitted if original
transaction is not present in the server"
type-1: type field from original transaction or omitted if original
transaction is not present in the server"
4.5.6 UNK1 - unknown-error
Description: This is the response sent when the request is so
bad off you can't determine what type it is or the type is
unknown to you. Sent from Merchant to Client or from Server
to Merchant or from Server to Client.
#####################################################################
Sender: MerchantApp or CyberServer
Receiver: CyberApp or MerchantApp
#####################################################################
Sample Message:
$$-CyberCash-0.8-$$
type: unknown-error
unknown-error-message:
Text message of error condition to display to user. (CyberCash
wrapper not found, wrapper integrity check fails, unknown protocol
version specified, unknown type specified, etc.)
{
server-date: 19950121100506.nnn [if sent by server]
}
or
{
merchant-date: 19950121100506.nnn [if sent by merchant]
}
x-id: mycybercashID
x-transaction: 123123213
x-date: 19950121100505.nnn
x-cyberkey: CC1001
x-opaque:
2DqiOQfGRZjzddWpEZwGsJnoTsp9Yiri8DE9cPUMPsJ7lTFuE4XHi4QfN2cAipDB2G/G
9hr7Hj4u4xfMky7nPvJurClZejkI8eNp8iXLtrfS4DhR4yCFQjCiKk0dh83p+DDsFVV7
TI3Du2B15sQS+SdaoPwkfVDnJv4Y+b7vu2cN7bG7exCkBapBcJZbReNaWX5sf+U8ypfw
5V6QdMOzNXpef3z+cTTWfGOtmn9T1Pwo1Yi9ObyIf/wiK+IPb+bBZ9UwLZSB+qVMfJmX
GnHXO3AnA/PD+jKYCtsm2Gxv2WB3CuezOyzPtORuqLp5ubgnLBF9aBBjxwLdbn+cp5sm
lw51IHbmo1Jj7H6wyNnRpEjy4tM73jcosBfGeQDHxgyH1uaiFNr2D+WvmuYo7eun2dsy
Wve2O/FwicWHvkg5aDPsgOjzetsn1JCNZzbW
$$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$
#####################################################################
Opaque Key: see explanation
#####################################################################
Opaque Section Contents: see explanation
#####################################################################
Signature is of the following fields: see explanation
#####################################################################
Explanation:
This message is sent as a response when you can't find or understand
even the type of a message to you. It will always have type and
unknown-error-message fields at the beginning. Any fields from
the request that are parseable are simply echoed back in the UNK1
message with "x-" prefixed to it. Thus, if an x-opaque appears,
it was whatever the opaque was in the original request, etc. If
you can decrypt the opaque section, you don't want to put the
results here in the clear!
{}'s in the first column are to group alternatives only and do not
appear in the message.
Since the customer originates exchanges with merchant and server
and merchant originates exchanges with server, this message
will only be emitted from the merchant to the customer or the
server to the customer or merchant. It should generally just
be logged for debugging purposes.
You may need to watch out for denial of service via forged or
replayed UNK1 messages.
4.5.7 DL1 - diagnostic-log
Description: Client diagnostic log of bad message from either
merchant or server.
#####################################################################
Sender: CyberApp
Receiver: CyberServer
#####################################################################
Sample Message:
$$-CyberCash-0.8-$$
id: MyCyberCashID
date: 19950121100505.nnn
transaction: 1234
cyberkey: CC1001
opaque:
2DqiOQfGRZjzddWpEZwGsJnoTsp9Yiri8DE9cPUMPsJ7lTFuE4XHi4QfN2cAipDB2G/G
9hr7Hj4u4xfMky7nPvJurClZejkI8eNp8iXLtrfS4DhR4yCFQjCiKk0dh83p+DDsFVV7
TI3Du2B15sQS+SdaoPwkfVDnJv4Y+b7vu2cN7bG7exCkBapBcJZbReNaWX5sf+U8ypfw
5V6QdMOzNXpef3z+cTTWfGOtmn9T1Pwo1Yi9ObyIf/wiK+IPb+bBZ9UwLZSB+qVMfJmX
GnHXO3AnA/PD+jKYCtsm2Gxv2WB3CuezOyzPtORuqLp5ubgnLBF9aBBjxwLdbn+cp5sm
lw51IHbmo1Jj7H6wyNnRpEjy4tM73jcosBfGeQDHxgyH1uaiFNr2D+WvmuYo7eun2dsy
Wve2O/FwicWHvkg5aDPsgOjzetsn1JCNZzbW
$$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$
#####################################################################
Opaque Key: generated from CyberCash encryption key identified in
CyberKey
#####################################################################
Opaque Section Contents:
type: diagnostic-log
message: incorrect order-id
swversion: 0.8win
x-type: original-message-type
x-transaction: original-transaction-number
x-opaque: [if can't decrypt]
9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3
5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw
#####################################################################
Explanation:
Client application does not expect a response for this message. The
decrypted original message will be in the opaque section unless
decryption fails. If decryption fails then un-decrypted opaque
in the original will be sent.
This message will be sent to a different script or socket or host
than normal messages so that it will just be absorbed and never
generate an UNK1 response or anything, even if this message
itself is screwed up.
4.5.8 DL2 - merchant-diagnostic-log
Description: Merchant diagnostic log of bad message from server.
#####################################################################
Sender: CyberMerchant
Receiver: CyberServer
#####################################################################
Sample Message:
$$-CyberCash-0.8-$$
merchant-ccid: MyCyberCashID
merchant-transaction: 1234
merchant-date: 19950121100505.nnn
merchant-cyberkey: CC1001
merchant-opaque:
2DqiOQfGRZjzddWpEZwGsJnoTsp9Yiri8DE9cPUMPsJ7lTFuE4XHi4QfN2cAipDB2G/G
9hr7Hj4u4xfMky7nPvJurClZejkI8eNp8iXLtrfS4DhR4yCFQjCiKk0dh83p+DDsFVV7
TI3Du2B15sQS+SdaoPwkfVDnJv4Y+b7vu2cN7bG7exCkBapBcJZbReNaWX5sf+U8ypfw
5V6QdMOzNXpef3z+cTTWfGOtmn9T1Pwo1Yi9ObyIf/wiK+IPb+bBZ9UwLZSB+qVMfJmX
GnHXO3AnA/PD+jKYCtsm2Gxv2WB3CuezOyzPtORuqLp5ubgnLBF9aBBjxwLdbn+cp5sm
lw51IHbmo1Jj7H6wyNnRpEjy4tM73jcosBfGeQDHxgyH1uaiFNr2D+WvmuYo7eun2dsy
Wve2O/FwicWHvkg5aDPsgOjzetsn1JCNZzbW
$$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$
#####################################################################
Opaque Key: generated from CyberCash encryption key identified in
CyberKey
#####################################################################
Opaque Section Contents:
type: merchant-diagnostic-log
server-date: 19950121100505.nnn [optional]
message: incorrect order-id
x-type: original-message-type
x-transaction: original-transaction-number
x-opaque: [if can't decrypt]
9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3
5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw
#####################################################################
Explanation:
Merchant application does not expect a response for this message. The
decrypted original message will be in the opaque section unless
decryption fails. If decryption fails then un-decrypted message
will be sent.
This message will be sent to a different script or socket or host
than normal messages so that it will just be absorbed and never
generate an UNK1 response or anything even if this message
itself is screwed up.
4.6 Table of Messages Described
The following 31 messages are described in this document.
C = Customer App, M = Merchant App, S = CyberCash Server
FLOW SECTION NAME
C->S 4.2.1 BC.1 bind-credit-card
S->C 4.2.2 BC.4 bind-credit-card-response
C->M 4.3.2 CH.1 credit-card-payment
M->C 4.3.3 CH.2 credit-card-response
M->S 4.4.8 CD.1 card-data-request
S->M 4.4.9 CD.2 card-data-response
M->S 4.4.1 CM.1 auth-only
M->S 4.4.2 CM.2 auth-capture
M->S 4.4.3 CM.3 post-auth-capture
M->S 4.4.4 CM.4 void
M->S 4.4.5 CM.5 return
S->M 4.4.6 CM.6 charge-action-response
C->S 4.5.7 DL.1 diagnostic-log
M->S 4.5.7 DL.2 merchant-diagnostic-log
C->S 4.1.3 GA.1 get-application
S->C 4.1.4 GA.2 get-application-response
M->S 4.4.7 MM.1 merchant-auth-only
M->S 4.4.7 MM.2 merchant-auth-capture
M->S 4.4.7 MM.3 merchant-post-auth-capture
M->S 4.4.7 MM.4 merchant-void
M->S 4.4.7 MM.5 merchant-return
S->M 4.4.7 MM.6 merchant-charge-action-response
C->S 4.5.1 P.1 ping
S->C 4.5.2 P.2 ping-response
M->C 4.3.1 PR.1 payment-request
C->S 4.1.1 R.1 registration
S->C 4.1.2 R.2 registration-response
C->S 4.5.3 TQ.1 transaction-query
C->S 4.5.4 TQ.2 transaction-cancel
S->C 4.5.5 TQ.3 transaction-response
S->C, S->M, M->C
4.5.6 UNK.1 unknown-error
5. Future Development
CyberCash is extending the facilities available through the CyberCash
system. We are committed to implementing a full cash system,
including efficient transfer of small amounts of money, the extension
of the credit card system to handle terminal capture and clearances,
and other improvements.
5.1 The Credit Card Authorization/Clearance Process
There are six steps in credit card processing as listed below. The
first four are always involved if a transacation is completed. The
fifth and sixth are optional.
(1) authorization: merchant contacts their acquiring back which
normally contacts the card issung bank and returns to the
merchant an approval/guarantee or a disapproval. This
temporarily decreases the available credit on the card.
(2) capture: the charge information for a purchase is entered by
the merchant into a batch.
(3) clearance: a batch of items is processed. This actually causes
the items in the batch to appear on credit card statements as
sent by the issuing bank to its carholders.
(4) settlement: the actual interbank transfer of net funds.
(5) void: the merchant undoes step 2 (or 6) and causes a charge (or
credit) to be removed from a batch. Must be done before the
batch is processed.
(6) credit: the merchant causes a "negative charge" or credit to be
entered into a batch. This will appear on the cardholders
statement.
The fourth step, settlement, is entirely within the banking community
and does not concern us here. CyberCash 0.8 provides messages to do
1, 1&2, 2, 5, and 6. This is adequate for credit card processor
systems where the batch is accumulated at the bank or between the
bank and the merchant. CyberCash 0.8 supports such "host capture"
systems. Other credit card processor systems require the merchant to
accumulate the batch. Such systems are frequently referred to as