RFC 1898
CyberCash Credit Card Protocol Version 0.8
RFC 1898: CyberCash Credit Card Protocol Version 0.8 🎀
okay bestie, this one is a February 1996 Informational RFC from the Network Working Group 💖 The authors are D. Eastlake 3rd, B. Boesch, S. Crocker, and M. Yesil, and all four of them were at CyberCash. It doesn't say it obsoletes or updates anything. It's basically CyberCash describing how its credit card payment system worked at version 0.8 🦋
Status of this Memo ✨
This memo gives information to the Internet community. It does not set any Internet standard, not even a little. Anyone can distribute it, no limits 💅
Abstract 🌸
CyberCash is building a general payments system for the Internet. This doc describes the structure and communications protocols of version 0.8, and this version only does credit card payments 💳 More capabilities are planned for later versions.
It also covers only the current CyberCash system, which is one of the few systems actually running in the fast-moving world of Internet payments 🔥 CyberCash says it's committed to developing the system further and to working with the Internet Engineering Task Force and other standards orgs. Very cooperative, very iconic 👑
Acknowledgements 🫶
The authors say thank you to these people, listed in alphabetic order, for their big contributions to the protocol:
Bruce Binder, Judith Grass, Alden Hart, Steve Kiser, Steve Klebe, Garry Knox, Tom Lee, Bob Lindenberg, Jim Lum, Bill Melton, Denise Paredes, Prasad Chintamaneni, Fred Silverman, Bruce Wilson, Garland Wong, Wei Wu, Mark Zalewski.
Jeff Stapleton and Peter Wagner also gave useful comments on the first version of the memo, so they get a shoutout too 🌈
History 📜
For the historians out there: this document was first posted as an Internet draft, which made it public, on 8 July 1995 🕰️
Table of Contents 📚
1. Overall System..........................................3
1.1 System Overview........................................3
1.2 Security Approach......................................5
1.2.1 Authentication and Persona Identity..................5
1.2.2 Privacy..............................................6
1.3 Credit Card Operation..................................6
2. General Message Wrapper Format..........................7
2.1 Message Format.........................................7
2.2 Details of Format......................................8
2.3 Body Parts.............................................8
2.4 Transparent Part.......................................9
2.5 Opaque Part...........................................10
2.6 Trailer...............................................10
2.7 Example Messages......................................11
3. Signatures and Hashes..................................12
3.1 Digital Signatures....................................12
3.2 Hash Codes............................................13
4. Specific Message Formats...............................13
4.1 Persona Registration and Application Retrieval........14
4.1.1 R1 - registration...................................14
4.1.2 R2 - registration-response..........................15
4.1.3 GA1 - get-application...............................16
4.1.4 GA2 - get-application-response......................17
4.2 Binding Credit Cards..................................18
4.2.1 BC1 - bind-credit-card..............................18
4.2.2 BC4 - bind-credit-card-response.....................20
4.3 Customer Credit Card Purchasing Messages..............21
4.3.1 PR1 - payment-request...............................21
4.3.2 CH1 - credit-card-payment...........................23
4.3.3 CH2 - charge-card-response..........................24
4.4 Merchant Credit Card Purchasing Messages..............25
4.4.1 CM1 - auth-only.....................................26
4.4.2 CM2 - auth-capture..................................28
3.4.3 CM3 - post-auth-capture.............................28
4.4.4 CM4 - void..........................................30
4.4.5 CM5 - return........................................32
4.4.6 CM6 - charge-action-response........................32
4.4.7 The MM* Message Series..............................34
4.4.8 CD1 - card-data-request.............................35
4.4.9 CD2 - card-data-response............................37
4.5 Utility and Error Messges.............................38
4.5.1 P1 - ping...........................................39
4.5.2 P2 - ping-response..................................39
4.5.3 TQ1 - transaction-query.............................40
4.5.4 TQ2 - transaction-cancel............................41
4.5.5 TQ3 - transaction-response..........................42
4.5.6 UNK1 - unknown-error................................44
4.5.7 DL1 - diagnostic-log................................46
4.5.8 DL2 - merchant-diagnostic-log.......................47
4.6 Table of Messages Described...........................48
5. Future Development.....................................49
5.1 The Credit Card Authorization/Clearance Process.......49
5.2 Lessons Learned.......................................50
6. Security Considerations................................51
References................................................51
Authors' Addresses........................................521. Overall System 🌍
CyberCash, Inc. of Reston, Virginia was founded in August of 1994 to team up with financial institutions and with providers of goods and services. The goal is a payments system for the Internet that is safe, convenient, and inexpensive 💸 The CyberCash approach is built on a trusted link between the new world of cyberspace and the traditional banking world. CyberCash acts as a conduit, so payments can move quickly, easily, and safely between buyers, sellers, and their banks. The best part is that the buyer and seller don't need any prior relationship, just like in the real world of commerce 🛍️
CyberCash is a neutral third party whose only job is making sure payments get from one party to another. That makes it the linchpin for spontaneous consumer electronic commerce on the Internet 🔗
1.1 System Overview ✨
The CyberCash system is going to offer several separate payment services on the Internet, including credit card and electronic cash 💵 Consumers only need a personal computer with a network connection to get in on it. Merchants and banks don't need to change their everyday procedures much to process CyberCash transactions, so they can add safe online payments to their existing services way faster. Communication with banks happens over existing financial communications networks 🏦
To get started, consumers download free software from CyberCash over the Internet. That software sets up the electronic link between consumers, merchants, their banks, and individuals too. To make getting into the system even easier, CyberCash "PAY" buttons can be built into popular online service and software graphical user interfaces. That way, consumers can jump right into the system whenever they're ready to pay for stuff 🛒 Consumers don't need any prior relationship with CyberCash to use it, and they can set up their CyberCash persona online in a snap 🙌
Transactions are automated. Once the consumer puts the right info into their own computer, no manual steps are needed to process authorization or clearance through the whole system. All the consumer has to do is hit the pay option on an electronic form for each transaction 🤳 Transactions are also safe, since they're cryptographically protected from tampering and modification by eavesdroppers 🔐 And they're private, because info about the consumer that doesn't matter for the transaction isn't visible to the merchant 🙈
+------------+ +------------+
| | | |
| Internet | | Internet |
| customer +------------+ merchant +
| | | / |
+------------+ +------------+
/
/
+------------|-+
| CyberCash | |
| server | |
+-----+------|-+
| |
| |
+--------------+------|---------+
| +--------+ +--+-------+ |
| | card +-------+ / charge | |
| | issuer | | acquirer | |
| +--------+ +----------+ |
| |
| The Banking System |
+-------------------------------+
SYSTEM OVERVIEW1.2 Security Approach 🛡️
The CyberCash system takes security really seriously 😤 It uses encryption technology from some of the world's top security sources, and CyberCash is committed to adopting new security technologies as they come out over time 🔒
1.2.1. Authentication and Persona Identity 🔐
Okay bestie, so message authentication is built on public key encryption, the RSA way 💅. The CyberCash Server keeps a record of the public key for every customer and merchant persona, so it can authenticate anything a customer or merchant digitally signed, no matter what path the data took to reach the server ✨. The matching private key, which you need to make those signatures, stays with the customer or merchant and is never revealed to anyone else 🤫. In customer software, the private key is only stored in encrypted form, locked behind a passphrase 🔒.
The true CyberCash identity of a customer or merchant is their public/private key pair, but those keys are way too cumbersome (over 100 hex digits!) for anyone to remember or type 😭. So the user interface uses short alphanumeric IDs that the user or merchant picks to specify a persona 🎀. CyberCash adds check digits to the requested ID to help minimize the chance of picking the wrong persona by accident 🙈. Persona IDs are basically public information, and having a persona ID without its private key doesn't get you anything in the current system 🧚.
Individuals or organizations can set up one or more CyberCash customer personas directly with CyberCash. So one person can have several unrelated CyberCash personas, or share a persona with other people 🦋. This gives you a level of privacy that matches general Internet presence and cash transactions 🌸. Just know that persona holders who want to use a credit card for purchases with their CyberCash persona must first pass whatever online identification checks the card issuing organization requires 💳.
Control over a CyberCash persona is normally only available to whoever holds the private key for that persona. BUT there's a special safety net: you can attach an emergency close out passphrase to a CyberCash persona 🚨. When CyberCash receives that emergency close out passphrase, even over insecure channels like a phone call or ordinary email, it will suspend activity for that persona 📵. The emergency close-out passphrase can be stored separately from the private key and with somewhat less security, because it cannot be used to divert funds to anyone else 💅. This gives some protection if the private key or the passphrase that keeps the private key encrypted gets lost or misappropriated 🛡️. In the cash system, the emergency close-out passphrase may also transfer the persona balance to a designated bank account 🏦.
1.2.2. Privacy 🫶
Okay so message encryption uses the Digital Encryption Standard (DES), which is commonly used in electronic payment systems today 🔐. The plan is to superencrypt (meaning encrypted more than one level) especially sensitive information, like PIN numbers 🔢. They'll be handled so that the plain text readable version never exists in the CyberCash system, except for a moment inside special purpose secure cryptographic hardware that's part of the server, before it gets re-encrypted under another key 🧊.
Card charges are processed so that the merchant never learns the customer's credit card number, unless the merchant's bank chooses to release it to the merchant or it's required for dispute resolution 👀. On top of that, the server keeps no permanent storage of card numbers. They only exist while a transaction involving that card is in progress ⏳. Between these practices, the chance of card number misappropriation is greatly reduced, which is seriously iconic 👑.
1.3. Credit Card Operation 💳
Here's how credit card transactions work with CyberCash ✨. Once the price has been negotiated and the consumer is ready to buy, they just click the CyberCash "PAY" button on the merchant interface 🛒. That invokes the merchant's CyberCash software, which sends the consumer an online invoice with the relevant purchase info, and that info shows up on the customer's screen 📱. (See PR1 message.) The consumer adds their credit card number and other details simply by picking from a list of credit cards they've already registered to their CyberCash persona 💖. Then the customer's CyberCash software digitally signs all of this, encrypts it, and passes it along to the merchant, together with a hash code of the invoice as the customer saw it 🔏. (See CH1 message.)
When the merchant gets it, they add extra authorization info, encrypt everything, sign it electronically, and send it to the CyberCash Server 🚀. (See CM1 & CM2 messages.) The CyberCash Server can authenticate all the signatures and be sure that the customer and merchant agree on the invoice and charge amount 🤝. The server then forwards the relevant info to the acquiring bank, along with a request on behalf of the merchant for a specific banking operation, like charge authorization 🏦. The bank decrypts and processes the data the same way it normally would for any credit card transaction 💅. The bank's response goes back to the CyberCash Server, which sends an electronic receipt to the merchant (see CM6 message). The merchant is expected to forward part of that receipt to the customer (see CH2 message) 🧾. And just like that, the transaction is complete 🎉✨.
2. General Message Wrapper Format 🎁
Version 0.8 of the external format for encoding CyberCash messages is described below 📝. CyberCash messages are stylized documents for sending financial data over the Internet 💸.
There are loads of schemes for sending information over the Internet (HTTP, SMTP, and others), but each one is tied to a specific transmission mechanism 🙄. Since CyberCash messages need to travel over each of these media (and others too), a transmission-independent mechanism is needed 🦋.
2.1. Message Format 📦
CyberCash messages are made up of these components:
- Header - defines the start of the CyberCash message and includes version information.
- Transparent Part - contains information that is not private.
- Opaque Part(s) - contains the financial information in the message and is both privacy protected and tamper protected. An opaque part is not present in some messages. When it is present, the opaque part usually provides tamper protection for the transparent part.
- Trailer - defines the end of the CyberCash message and includes a check value so the receiver can tell the message arrived undamaged. Note: this check value is only intended to detect accidental damage to the message, not deliberate tampering ⚠️.
No null characters (zero value) or characters with the eighth bit on are permitted inside a CyberCash message 🚫. "Binary" quantities that might have such byte values in them are encoded in base64, as described in RFC 1521 🔤.
2.2. Details of Format 🔍
The header is a single line that looks approximately like this:
$$-CyberCash-0.8-$$or like this:
$$-CyberCash-1.2.3-Extra-$$It includes a number of fields separated with the minus character - 🎀.
$$- the literal string, with the initial$in column 1.CyberCash- the literal string (case insensitive).- x.y or x.y.z - the version number of the message format. x is the primary version number. y is a subversion number. z, if present, is a subsubversion number 🔢.
Extra- an optional additional alphanumeric string.$$- the literal string.
Version numbers start at 0.7 and count up. The .z is omitted when z is zero 🧮. 0.7 and 0.8 are the test and initial shipped versions of the credit card system 💳. 0.9 and 1.0 are expected to also incorporate the test and initial shipped versions of the cash facilities, as well as improvements to the credit card system 💵.
The Extra string is used within secure environments so one subcomponent can scribble a little note to another with minimal overhead 📝. For example, a server firewall could put HTTP or SMTP here before forwarding the message to the core server inside the firewall perimeter 🔥.
2.3. Body Parts 🧩
The body parts of the message, both transparent and opaque, consist of attribute value pairs in formats that are reminiscent of the standard electronic mail header (RFC822) format 💌. There are some differences though 👀.
Attribute names start with, and are made up mostly of, letters and internal hyphens, except that they sometimes end with a hyphen followed by a number 🔤. That trailing number is used when there's logically an indexed vector of values 📊. Attribute names are often called labels 🏷️.
If the label ends with a :, then RFC822 processing is done. The existence of trailing white space is significant, but all leading white space on continuation lines is stripped. Those lines are wrapped at 64 characters in length, not counting any line termination character(s) ✂️.
However, if the label is terminated with a ;, that means it's a free-form field, where new-line characters, and any leading white space after the initial space that marks a continuation line, are significant 🎨. Lines like this should not be wrapped, except that, to avoid other processing problems, they're forcibly wrapped at 200 characters 🙃.
Blank lines are ignored, and they don't signal a change to a different mode of line handling 🫧.
Another way of looking at all of the above: after you've found an initial $$ start line, you can treat any following lines according to their first character 🧠. If it's alphanumeric, it's a new label, which should be terminated with a : or ; and starts a new label-value pair 🏷️. If it's a white space character, it continues the value of the preceding label line. (Exactly how the continuation is processed depends on the label termination character.) If it's $, it should be the end line for the message 🏁. If it's #, it's a comment line and should be ignored 💬. Other initial characters are undefined 🤷♀️. (As of this date, no software sends CyberCash messages with # lines, but they're convenient for commenting on messages stored in files 📁.)
2.4. Transparent Part 🔓
The transparent part includes any clear-text data associated with the financial transaction, plus the information CyberCash and others need to decrypt the opaque part(s) 🗝️. It always includes a transaction field, which is the transaction number generated by the requester and repeated in the response 🔁. It always includes a date field, which is the local date and time at the requester, and it's repeated in the response too 🕰️. In all cases other than an initial registration to establish a persona ID, it includes the requester's persona ID 🪪.
On messages bound for the server, there's a cyberkey: field that identifies which server public key was used to encrypt the session key 🔑✨.
2.5 Opaque Part ✨
okay bestie, the opaque part is the secret stash 🤫🔐 It's one big block of characters in base64 (see RFC 1521), and the data inside is ALWAYS encrypted before it gets encoded. No peeking allowed 🙅♀️
The label opaque or merchant-opaque goes in front of the block, and which one you get depends on whether the client software or the merchant software did the encrypting. Totally iconic labeling tbh 💅
Okay, so on messages heading INTO the server, the data gets DES CBC encrypted under a random transaction key 🗝️ and then THAT DES key gets RSA encrypted under one of the server's public keys. The RSA-encrypted DES key shows up as the first part of the base64 field, and it is NOT pulled out as its own value in the message. Sneaky, right? 😭
The server's reply coming back out can just be DES encrypted under that same transaction key. Why? Because there's already enough plain text info to identify the transaction and the customer or merchant will have remembered the transaction key from the inbound message. Memory main character energy 🧠✨
Now, a signature is not generally needed in the opaque part of a reply message 🙈 Knowing the transaction key is already enough authentication. To forge a response, someone would need the server's private key so they could get at the transaction key in the first place. Lowkey impossible 🔒
If anyone tampers with the reply's opaque part, it's assumed the chance that it still decrypts to something that parses is insignificant. (Just the fact that the 8th bit has to be off means a chance of 1 in 2**n where there are n characters, and that's ignoring the rest of the formatting.) 🧮
And yes, someone CAN tamper with the transparent part 🙃 but that usually either does nothing or means the client won't find the transaction key. In that case it's just one more example of denial of service by damaging a message. Not cute 💀
2.6 Trailer 🎀
The trailer's whole job is to close the message and give a definitive, parseable end. Think of it as the period at the end of the sentence 💖
The trailer has several fields separated by -, just like the header does. Here's the lineup:
$$- literal string.CyberCash- literal string (case insensitive).End- literal string (case insensitive).- transmission checksum.
$$- literal string.
Now the transmission checksum is the MD5 hash of all printable characters in the version number in the start line, plus everything after the second $$ of the start line and before the first $$ of the trailer line, exactly as transmitted. 🧾
Note that ALL white space gets left out of this hash, including new-lines, spaces, tabs, carriage returns, etc. 🌸 The exact label terminators actually used (: or ;) ARE included, same with any # comment line. The optional "Extra" string in the $ start line is NOT included in the hash.
The whole point is to check the message arrived correctly without being bothered by gateways or processing that might change the line terminator sequence, convert tabs to spaces, or stuff like that. Smart, no cap 🧠👑
2.7 Example Messages 🦋
Here's the simple message from a client 💌
$$-CyberCash-0.8-$$
id: DONALD-69
transaction: 918273645
date: 199512250102
cyberkey:CC1001
opaque:
GpOJvDpLH62z+eZlbVkhZJXtTneZH32Qj4T4IwJqv6kjAeMRZw6nR4f0OhvbTFfPm+GG
aXmoxyUlwVnFkYcOyTbSOidqrwOjnAwLEVGJ/wa4ciKKI2PsNPA4sThpV2leFp2Vmkm4
elmZdS0Qe350g6OPrkC7TKpqQKHjzczRRytWbFvE+zSi44wMF/ngzmiVsUCW01FXc8T9
EB8KjHEzVSRfZDn+lP/c1nTLTwPrQ0DYiN1lGy9nwM1ImXifijHR19LZIHlRXy8=
$$-End-CyberCash-End-jkn38fD3+/DFDF3434mn10==-$$And here's a message from a merchant, which is giving multi-format chaos in the best way 🌈 It has labels, multi-line values, comments, and everything 😭
$$-CyberCash-a.b.c-extra-$$
merchant-ccid: acme-69
merchant-date: 19951231115959
merchant-transaction: 987654321
label: value
labelx: multiple line
value...
# comment
# another comment line
label; text with a real
multi-line
format !
merchant-cyberkey: CC1001
merchant-opaque:
C1Q96lU7n9snKN5nv+1SWpDZumJPJY+QNXGAm3SPgB/dlXlTDHwYJ4HDWKZMat+VIJ8y
/iomz6/+LgX+Dn0smoAge7W+ESJ6d6Ge3kRAQKVCSpbOVLXF6E7mshlyXgQYmtwIVN2J
66fJMQpo31ErrdPVdtq6MufynN8rJyJtu8xSNolXlqIYNQy5G2I3XCc6D3UnSErPx1VJ
6cbwjLuIHHv58Nk+xxt/FyW7yAMwUb9YNcmOj//6Ru0NiOA9P/IiWczDe2mJRK1uqVpC
sDrWehG/UbFTPD26trlYRnnY
$$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$3. Signatures and Hashes 🔏
Okay so inbound CyberCash request messages normally have a signature 🖋️ It covers all of the message's fields that sit OUTSIDE the signature itself. The signature gets transmitted inside the opaque part, and it lets the server authenticate who sent the message. Verified icon 💅
Messages going from a merchant to a client that kick off a purchase sequence have their fields signed by the merchant. The client then includes these fields and this signature in the opaque part of their card purchase message to the merchant 🛍️ When everything gets passed on to the server, the server can check that the client actually saw the info the merchant intended. Trust chain, bestie 🫶
More info on CyberCash signatures, and the hash codes they're based on, is coming up below 👀
3.1 Digital Signatures ✍️
Digital signatures are a way of authenticating information 🔐 In CyberCash messages, they're calculated by first taking the hash of the data to be authenticated (more on that below), and then encoding that hash using an RSA private key.
Anyone holding the matching public key can decrypt the hash and compare it with the message hash. If they match, you can be sure the signature was made by someone holding the private key that matches the public key you used, AND that the message wasn't tampered with. Chef's kiss 👌
In the CyberCash system, clients, merchants, and the server ALL have public-private key pairs 🗝️ By keeping the private key secret and registering their public key with the server (for a merchant or client), or publishing their public key or keys (for the server), they can provide high quality authentication by signing parts of messages. Iconic security moment ✨
An RSA digital signature is roughly the size of the modulus used. For example, if the modulus is 768 bits long, the binary digital signature is 768 bits, or 96 bytes long, and its base 64 encoding is 128 bytes. Math is giving main character energy 🧮💜
3.2 Hash Codes 🧩
The hashes in CyberCash messages are message digests. That means they're a non-invertible fingerprint of a message, so it's computationally infeasible to find an alternate message with the same hash 🚫 That's what makes the small hash able to secure a bigger message. If you trust the hash and a message matches it, you can be sure it's the original message, at least for all the parts that were included in the hash. Fingerprint energy
The hash is calculated with the MD5 algorithm (see RFC 1321) on a synthetic message. The synthetic message is built from the labels and values listed in a list for that particular hash 📝 The hash depends on input order, so it's ESSENTIAL that the label-value pairs get assembled in the order specified. Order matters, bestie 😭
Sometimes a range of matching labels is specified. For example, card* matches card-number, card-expiration-date, and every other label starting with card. In those cases, all the existing matching labels get used in ascending alphabetic order by ASCII character code 🔤
If a label is in a signature list but NOT present in the label-value data being hashed, it doesn't get included at all. Even the label and label terminator get left out of the synthetic message. Gone, like it never happened 👻
Before hashing, the text of the synthetic message gets processed to remove all "white space" characters. White space is defined as any character with an ASCII value of 32 (space) or less, or 127 (rubout) or greater. So all forms of new-line/carriage-return, blank lines, trailing spaces, and turning a horizontal tab into multiple spaces get ignored for hash purposes 🌊
MD5 hashes are 16 bytes long. That means the base 64 encoding of one is 24 characters, and the last two are always padding equal signs 🌸
4. Specific Message Formats 💎
This section shows the formats of the Version 0.8 CyberCash messages by example, with comments 📚 The reader is assumed to be familiar with terms like "acquirer" and "PAN" (primary account number), which are defined in ISO 8583, plus currency designations defined in ISO 4217. A few fields that aren't relevant to current operations have been removed to keep things simple 🫧
In the example messages below, signatures, hashes, and encrypted sections are fake nonsense text, and the ids are fictitious. So don't panic at the gibberish 🙈
4.1 Persona Registration and Application Retrieval 🎭
Step one for customers is registering a persona using the customer application. This happens with the R1 message (defined below), and the CyberCash server replies with the R2 message 💌
When the customer application figures out it's out of date, it can send the GA1 request message to the server and use the GA2 response to download a new signed version of itself. Glow up on demand ✨
4.1.1 R1 - registration 🌷
Description: This is the initial message sent to create a new CyberCash persona.
#####################################################################
Sender: CyberApp
Receiver: CyberServer
#####################################################################
Sample Message:
$$-CyberCash-0.8-$$
transaction: 123123213
date: 19950121100505.nnn
cyberkey: CC1001
opaque:
FrYOQrD16lEfrvkrqGWkajM1IZOsLbcouB43A4HzIpV3/EBQM5WzkRJGzYPM1r3noBUc
MJ4zvpG0xlroY1de6DccwO9j/0aAZgDi9bcQWV4PFLjsN604j3qxWdYn9evIGQGbqGjF
vn1qI1Ckrz/4/eT1oRkBBILbrWsuwTltFd84plvTy+bo5WE3WnhVKsCUJAlkKpXMaX73
JRPoOEVQ3YEmhmD8itutafqvC90atX7ErkfUGDNqcB9iViRQ7HSvGDnKwaihRyfirkgN
+lhOg6xSEw2AmYlNiFL5d/Us9eNG8cZM5peTow==
$$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$
#####################################################################
Opaque Key: Generated using CyberCash encrypting public key
identified in CyberKey.
#####################################################################
Opaque Section Contents:
type: registration
swversion: 0.8win
content-language: en-us
requested-id: MyRequestedCCID
email: myemail@myemailhost.com
pubkey:
0VdP1eAUZRrqt3Rlg460Go/TTs4gZYZ+mvI7OlS3l08BVeoms8nELqL1RG1pVYdDrTsX
E5L+wcGCLEo5+XU5zTKkdRUnGRW4ratrqtcte7e94F+4gkCN06GlzM/Hux94
signature:
v6JGmxIwRiB6iXUK7XAIiHZRQsZwkbLV0L0OpVEvan9l59hVJ3nia/cZc/r5arkLIYEU
dw6Uj/R4Z7ZdqO/fZZHldpd9+XPaqNHw/y8Arih6VbwrO5pKerLQfuuPbIom
#####################################################################
signature is of the following fields: transaction, date, cyberkey,
type, swversion, content-language, requested-id, email, pubkey
#####################################################################
Explanation:
content-language is taken from the MIME header field (see RFC1766)
and is the language text messages should be generated in. (Only
en-us is implemented at this time.)
swversion is used to check whether the client application is old. 🕵️♀️4.1.2 R2 - registration-response
Description: This message gives the success/failure response to R1. 💌
Sender: CyberServer Receiver: CyberApp
Sample Message:
$$-CyberCash-0.8-$$
transaction: 12312313
date: 19950121100505.nnn
opaque:
r1XfjSQt+KJYUVOGU60r7voFrm55A8fP5DjJZuPzWdPQjGBIu3B6Geya8AlJfHsW11u8
dIv1yQeeYj/+l9TD1dXW21/1cUDFFK++J2gUMVv8mX1Z6Mi4OU8AfsgoCliwSkWmjSOb
kE62sAlZTnw998cKzMFp70TSlI3PEBtvIfpLq5lDCNbWidX8vFZV0ENUmMQ9DTP3du9w
fsFGvz1mvtHLT/Gj8GNQRYKF4xiyx4HYzTkSMhgU5B/QDLPS/SawIJuR86b9X0mwsr0a
gbGTzECPJTiKkrhxxMG/eymptsVQSLqNaTCx6w==
$$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$Opaque Key: Same as session key for R1 for same Transaction and connection (there may be no ID!). 🔑
Opaque Section Contents:
type: registration-response
server-date: 19950121100506.nnn
requested-id: MyRequestedCCID
response-id: CyberCashHandle
email: myemail@myemailhost.com
response-code: success/failure/etc.
pubkey:
0VdP1eAUZRrqt3Rlg460Go/TTs4gZYZ+mvI7OlS3l08BVeoms8nELqL1RG1pVYdDrTsX
E5L+wcGCLEo5+XU5zTKkdRUnGRW4ratrqtcte7e94F+4gkCN06GlzM/Hux94
swseverity: fatal/warning [absent if ok]
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 person
by the CyberCash application...
In general this includes: duplicate-id, bad-signature,
or ill-formed-registrationSignature is of the following fields: no-signature 🙅♀️
Explanation: okay so responseid is used to suggest a unique ID if the failure was due to the requested ID already being in use 🙃 If the reason for failure was not a duplicate ID, then this field may be omitted. responseid gives the actual ID with check characters appended if it's a success ✨ And swseverity can warn the user about an old client application, or flag a failure caused by an old or known buggy version 🫶
4.1.3 GA1 - get-application
Description: Used by CyberApp to get an updated version. 🌸
Sender: CyberApp Receiver: CyberServer
Sample Message:
$$-CyberCash-0.8-$$
transaction: 123123213
date: 19950121100505.nnn
cyberkey: CC1001
opaque:
VHMS611wGkUmR6bKoI+ODoSbl7L5PKtEo6aM88LCidqN+H/8B4xM3LxdwUiLn7rMPkZi
xOGb+5d1lRV7WeTp21QYlqJr8emc6FAnGd5c0csPmcnEpTFh9xZDJaStarxxmSEwm2mw
l2VjEUODH6321vjoMAOFQWn7ER0o
$$-CyberCash-End-0QXqLlNxrn4GNQPPk9AO1Q==-$$Opaque Key: Generated using CyberCash encrypting public key identified in CyberKey. 🗝️
Opaque Section Contents:
type: get-application
swversion: 0.8winSignature is of the following fields: no signature 🫠
Explanation: So there may not be a customer persona, which means there's no ID 🤷♀️ There may also not be a customer public/private key pair, so there's no signature either. The swversion is mandatory though, because that's how the server knows what to send back 💅
4.1.4 GA2 - get-application-response
Description: Return success and URL of up to date copy of CyberApp or failure. 🎀
Sender: CyberServer Receiver: CyberApp
Sample Message:
$$-CyberCash-0.8-$$
transaction: 12312313
date: 19950110102333.nnn
opaque:
EDD+b9wAfje5f7vscnNTJPkn1Wdi7uG3mHi8MrzLyFC0dj7e0JRjZ2PmjDHuR81kbhqb
nX/w4uvsoPgwM5UJEW0Rb9pbB39mUFBDLPVgsNwALySeQGso0KyOjMxNs1mSukHdOmDV
4uZR4HLRRfEhMdX4WmG/2+sbewTYaCMx4tn/+MNDZlJ89Letbz5kupr0ZekQlPix+pJs
rHzP5YqaMnk5iRBHvwKb5MaxKXGOOef5ms8M5W8lI2d0XPecH4xNBn8BMAJ6iSkZmszo
QfDeWgga48g2tqlA6ifZGp7daDR81lumtGMCvg==
$$-CyberCash-End-0QXqLlNxrn4GNQPPk9AO1Q==-$$Opaque Key: session key from GA1 🔐
Opaque Section Contents:
type: get-application-response
server-date: 19950110102334.nnn
response-code: success/failure/etc.
message; Text message to be displayed to the user providing more
information on the success/failure.
swversion: 0.8win
application-url: http://foo.cybercash.com/server/0.8WIN.EXE
application-hash: lSLzs/vFQ0BXfU98LZNWhQ==Signature: none. 🚫
Explanation: application-hash is the MD5 of the binary of the application 🧮 The application-url and application-hash are both left out on failure. And swversion is the version being sent to the customer 📦
4.2 Binding Credit Cards
Okay bestie, so the CyberCash system is designed to let the card issuing organization decide whether a card can be used through CyberCash at all 🏦👑 After the customer has registered a persona with CyberCash (as described above), they can bind each credit card they want to use to that persona. This happens through the BC1 message from the customer to their CyberCash server, and then the BC4 response from the server 💳✨
4.2.1 BC1 - bind-credit-card
Description: This is the initial message in the process of binding a credit card to a CyberCash persona. 🦋
Sender: CyberApp Receiver: CyberServer
Sample Message:
$$-CyberCash-0.8-$$
id: MyCyberCashID
date: 19950121100505.nnn
transaction: 12312314
cyberkey: CC1001
opaque:
EDD+b9wAfje5f7vscnNTJPkn1Wdi7uG3mHi8MrzLyFC0dj7e0JRjZ2PmjDHuR81kbhqb
nX/w4uvsoPgwM5UJEW0Rb9pbB39mUFBDLPVgsNwALySeQGso0KyOjMxNs1mSukHdOmDV
4uZR4HLRRfEhMdX4WmG/2+sbewTYaCMx4tn/+MNDZlJ89Letbz5kupr0ZekQlPix+pJs
rHzP5YqaMnk5iRBHvwKb5MaxKXGOOef5ms8M5W8lI2d0XPecH4xNBn8BMAJ6iSkZmszo
QfDeWgga48g2tqlA6ifZGp7daDR81lumtGMCvg==
$$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$Opaque Key: generated from CyberCash encryption key identified in CyberKey 🗝️
Opaque Section Contents:
type: bind-credit-card
swversion: 0.8win
card-number: 1234567887654321
card-type: mastercard
card-salt: 46735210
card-expiration-date: 05/99
card-name: John Q. Public
card-street:
card-city:
card-state:
card-postal-code:
card-country:
signature:
tX3odBF2xPHqvhN4KVQZZBIXDveNi0eWA7717DNfcyqh2TpXqgCxlDjcKqdJXgsNLkY7
GkyuDyTF/m3SZif64giCLjJRKg0I6mqI1k/Dcm58D9hKCUttz4rFWRqhlFajSignature is of the following fields: id, date, transaction, cyberkey, type, swversion, card-number, card-salt, card-expiration-date, card-name, card-street, card-city, card-state, card-postal-code, card-country ✍️
Explanation: okay the salt is needed so the hash stored on the server is less informative 🧂 The server only remembers the "prefix" of the card number, plus the hash of the card number combined with the salt. If it just hashed the card number, anyone could recover it with modest effort by hashing every plausible number 😬 We don't want to store card numbers on the server, because that would make the server files way too valuable to bad guys 🚨
4.2.2 BC4 - bind-credit-card-response
Description: Indicates that the process of binding a credit card terminated. Returns success or failure. 🎉
Sender: CyberServer Receiver: CyberApp
Sample Message:
$$-CyberCash-0.8-$$
id: mycybercashid
transaction: 12312314
date: 19950121100505.nnn
opaque:
EDD+b9wAfje5f7vscnNTJPkn1Wdi7uG3mHi8MrzLyFC0dj7e0JRjZ2PmjDHuR81kbhqb
nX/w4uvsoPgwM5UJEW0Rb9pbB39mUFBDLPVgsNwALySeQGso0KyOjMxNs1mSukHdOmDV
4uZR4HLRRfEhMdX4WmG/2+sbewTYaCMx4tn/+MNDZlJ89Letbz5kupr0ZekQlPix+pJs
rHzP5YqaMnk5iRBHvwKb5MaxKXGOOef5ms8M5W8lI2d0XPecH4xNBn8BMAJ6iSkZmszo
QfDeWgga48g2tqlA6ifZGp7daDR81lumtGMCvg==
$$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$Opaque Key: Session key from BC1 with same Transaction and ID 🔑
Opaque Section Contents:
type: bind-credit-card-response
server-date: 19950121100506.nnn
swseverity: fatal/warning [absent if ok]
swmessage; message about obsoleteness of customer software
to be shown to the customer. [only present if SWSeverity present]
response-code: success/failure/etc.
card-number: 1234567887654321
card-type: visa
card-salt: 47562310
card-expiration-date: 01/99
card*: [other card* lines to also be given in CH.1 message]
message; Plain text for the user
can be multiple linesSignature is of the following fields: no-signature 🙅♀️
Explanation: All the card* lines can be saved as a blob to be submitted in CH.1 💾 card-expiration-date, card-number, card-salt, and card-type should always be present. Depending on the reason for failure, though, not all fields may show up 🫧
4.3 Customer Credit Card Purchasing Messages
Alright, so CyberCash gets involved in the credit card purchasing cycle pretty much after the user has figured out what they're buying 🛍️ When they click the CyberCash payment button, the merchant sends a PR1 message to the customer, as the body of a message with the MIME type application/cybercash 💖
If the customer wants to go ahead, they reply to the merchant with a CH1. The merchant then answers with a CH2. Between getting the CH1 and sending the CH2, the merchant usually talks to the CyberCash server using the CM* messages 🧚✨
4.3.1 PR1 - payment-request ✨
Okay so this is the very first message CyberCash defines in the buy-from-a-merchant flow 🛍️ The shopping is officially done bestie, and now it's time to actually pay 💸
Sender: MerchantApp Receiver: CyberApp
Sample Message:
$$-CyberCash-0.8-$$
type: payment-request
merchant-ccid: ACME-012
merchant-order-id: 1231-3424-234242
merchant-date: 19950121100505.nnn
note;
ACME Products
Purchase of 4 pairs "Rocket Shoes" at $39.95 ea.
Shipping and handling $5.00
Total Price: 164.80
Ship to:
Wily Coyote
1234 South St.
Somewhere, VA 12345
merchant-amount: usd 164.80
accepts: visa:CC001, master:CC001,amex:CC001,JCPenny:VK005,macy:VK006
url-pay-to: http://www.ACME.com/CybercashPayment
url-success: http://www.ACME.com/ordersuccess
url-fail: http://www.ACME.com/orderfail
merchant-signed-hash:
a/0meaMHRinNVd8nq/fKsYg5AfTZZUCX0S3gkjAhZTmcrkp6RZvppmDd/P7lboFLFDBh
Ec0oIyxWeHfArb3OtkgXxJ7qe0Gmm/87jG5ClGnpBnw0dY7qcJ6XoGB6WGnD
$$-CyberCash-End-lSLzs/vFQ0BXfU98LZNWhQ==-$$Opaque Key: no opaque section
Opaque Section Contents: no opaque section
Signature note: merchant-signed-hash is the signature under the merchant's private key of the hash of the following fields: type, merchant-ccid, merchant-order-id, date, note, merchant-amount, accepts, url-pay-to, url-success, url-fail
Explanation:
Here's the tea ☕ This message is signed by the merchant, but the customer can't directly verify that signature. When the payment happens, the Customer sends back the signature along with a hash that the customer derives directly. If those two don't match, CyberCash will not perform the payment function 🙅♀️
The accepts field is picky, so pay attention 🧐 The client software will only recognize a single-word card name. So MasterCard and AmericanExpress work, but Master card and American express are not recognized. MasterCard and masterCard both count as master card, which is lowkey iconic of them 💅
Each entry is a card type followed by a key designator. For mainline credit cards, the designator is a CC*, and the client can use or ignore the * number however it likes 🤷♀️ For proprietary cards, it's a VK*, where the * is the CheckFree key to use (1 based). Entries are separated by commas, and the key designator comes right after the card type and a colon.
Last but not least, url-pay-to is where the CH1 should be sent 📬 And url-fail and url-success are where the browser should look after a failure or a success 🌈
4.3.2 CH1 - credit-card-payment 💳
Okay this one is the presentation of a "credit card for payment" 💖 It's the customer handing over the card, basically 🫶
Sender: CyberApp Receiver: MerchantApp
Sample Message:
$$-CyberCash-0.8-$$
type: card-payment
id: myCyberCashID
order-id: 1231-3424-234242
merchant-ccid: ACME-012
transaction: 78784567
date: 19950121100505.nnn
pr-hash: c77VU/1umPKH2kpMR2QVKg==
pr-signed-hash:
a/0meaMHRinNVd8nq/fKsYg5AfTZZUCX0S3gkjAhZTmcrkp6RZvppmDd/P7lboFLFDBh
Ec0oIyxWeHfArb3OtkgXxJ7qe0Gmm/87jG5ClGnpBnw0dY7qcJ6XoGB6WGnD
cyberkey: CC1001
opaque:
iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg
3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3
9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3
5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw
3ard3Q==
$$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$Opaque Key: Created using CyberCash encrypting public key in CyberKey 🔐
Opaque Section Contents:
swversion: 0.8win
amount: usd 10.00
card*: [from successful BC4 (includes card-expiration-date,
card-number, card-type, and card-salt)]
signature:
meO38aULnoP09VhTS2E56tnuZBRRlGfbwqaleZ9zNnv7YjExJKBFxuaqYTUDEj427HHh
mm9BVmHRwCq6+8ylZXixGHI1I9A/ufAMrpqMIi6DS3PRlc8WC3CCWoAHyAqrSignature note: the signature is under the client private key of the following fields: type, id, order-id, merchant-ccid, transaction, date, pr-hash, pr-signed-hash, cyberkey, swversion, amount, card*
Explanation:
Plot twist 🦋 The pr-signed-hash field is the exact same thing as the merchant-signed-hash from the PR1 message. It just has a different name, and that's purely for historic reasons 📜
4.3.3 CH2 - charge-card-response ✨
This is the response that heads back to the customer after a CH1 attempt to pay by credit card 💅 It tells you whether it worked or flopped 😭
Sender: MerchantApp Receiver: CyberApp
Sample Message:
$$-CyberCash-0.8-$$
type: charge-card-response
merchant-ccid: ACME-012
id: myCyberCashID
transaction: 78784567
date: 1995121100500.nnn
merchant-date: 19950121100505.nnn
merchant-response-code: failure/success/etc.
pr-hash: 7Tm/djB05pLIw3JAyy5E7A==
pr-signed-hash:
a/0meaMHRinNVd8nq/fKsYg5AfTZZUCX0S3gkjAhZTmcrkp6RZvppmDd/P7lboFLFDBh
Ec0oIyxWeHfArb3OtkgXxJ7qe0Gmm/87jG5ClGnpBnw0dY7qcJ6XoGB6WGnD
merchant-message; This is a message to display to the user from the
merchant. Can be multiple lines... Is not secure.
opaque: [might not be present, see explanation]
EDD+b9wAfje5f7vscnNTJPkn1Wdi7uG3mHi8MrzLyFC0dj7e0JRjZ2PmjDHuR81kbhqb
nX/w4uvsoPgwM5UJEW0Rb9pbB39mUFBDLPVgsNwALySeQGso0KyOjMxNs1mSukHdOmDV
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 note: there is no signature covering these fields
Explanation:
The opaque section is optional, and that's the tea ☕ The CH1 to the merchant can fail for a bunch of reasons, like a bad order-id, a bad date, or the wrong merchant-ccid. So the server might not get involved at all, which means there's no way to generate a secure opaque section. (It could even be that the merchant's attempt to contact the server times out 😩)
If the transaction does make it through the server (via CM*), then the top-level Response-Code should mirror the response-code the merchant got from the server. Hopefully that's the same as the response-code the customer got from the server, but the merchant can't tell that part 🙈
Also, note that there can be two messages: one from the merchant and one from the server 👯
4.4 Merchant Credit Card Purchasing Messages 💼
Merchants are the main characters of the card side of things 👑 They present credit card purchases, make adjustments, and everything in between, all through the CM* series 💅 The general credit card cycle goes like this: get an authorization for a purchase, then capture that purchase in a batch for clearance, then actually do the clearance 🧾 You can also void a capture (which means pulling an item out of a batch), and process credits, which are returns 🔄 (See section 5.1.)
Authorizations always come from an acquirer, through the response to a CM1 or CM2 message 🏦 If the capture is handled by the acquirer, or by some entity sitting between the CyberCash server and the acquirer, it happens via a CM3 or CM2 message. Which one depends on the arrangement between the merchant and whoever is doing the capture. Returns (credits) are handled with CM5 🙌 CM4 is there for voiding a capture or return before the batch is cleared. And CM6 is the format used for responses to all the other CM* messages 💜
There's also an MM* series for purely merchant-originated CyberCash charges, which is described in section 3.4.7 🌸
Now here's where it gets a little spicy 🌶️ Current credit card dispute resolution systems assume that the merchant knows the card number. So, to work with those systems, special bypass messages were set up. They let the merchant get, for one particular transaction, the information that CyberCash otherwise goes out of its way to hide from the merchant. Getting that information is an auditable event, so it's always on the record 👀 See sections 3.4.8 and 3.4.9.
Lastly, many present-day merchants run in "terminal capture" mode. In that setup, the merchant captures the authorizations themselves and later submits the settlement batch. Messages have been defined, and are being implemented, so that these merchant-captured batches can be submitted via CyberCash ✨🫧
4.4.1 CM1 - auth-only
Okay bestie, this is the merchant asking CyberServer for an authorization on the card the customer handed over. Main character energy 💅
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
✨ Okay bestie, this is the receipt the merchant gets once a charge action is done! It tells them whether things were a success, a failure, or somewhere in between. 💅
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.nnnOpaque (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-numberis needed for voids.authorization-codeis needed for post-auth-capture. Each of these fields is only present in the CM6 if the bank returned it, and that depends on which operation was being done.card-prefixis the first two and last four digits ofcard-number.- At the merchant's bank's discretion, either the
card-numberor thecard-prefixis returned. card-hashis really the hash of the full card number and the salt provided by the customer. It's 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-dateis duplicated in the customer opaque area for security. 🔒- The
{}'s in column one are just for clarity of the alternatives and do not actually appear in the message. - The
[]ed comments appear after some fields.
4.4.7 The MM* Message Series
🌸 Okay so the CM* series is the main CyberCash credit card purchase system for handling charges from CyberCash customers securely. 🔐 But merchants who are authorized by their acquiring bank to accept charges can also get telephone, mail, and over-the-counter sales! 📞 ✉️ To save the merchant from needing a second, parallel system for those charges, there's an MM1 through MM6 message series. It's been implemented for these less secure transactions, so just know that going in. ⚠️
The MM* messages look very similar to the CM* series. The difference is that the "customer opaque" section is 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
✨ This one's how the merchant asks for card-number and other details, if they need them 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+Ovmerchant-opaque key: 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+yUfQ4T7eNEsmerchant-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 the CM1 explanation.
- The merchant may need to know the card involved, plus other info, to resolve a disputed transaction. All of that lives in the original CH1, which is embedded in the CM1 for the transaction. If the merchant saved the CM1 and the other transaction info, they can send this CD1 to the server. 💌
- Heads up: while this reduces the pass-through confidentiality of the system, the merchant is then on record as asking for this particular credit card number. Excessive CD1's from a merchant can be flagged. 🚩
passwordis an extra level of security, intended to be entered manually at the merchant to authorize the unusual action. The server stores a hash of themerchant-ccidand the password. 🔑
4.4.9 CD2 - card-data-response
💖 And here's the reply to CD1! It's either a failure, or a success that comes with the 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.nnnSignature 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 ✨
okay so the CyberCash system needs a bunch of extra messages for utility, status checks, and special errors 💅
we want to be able to check connectivity, roughly sync clocks, and get a first look at which client protocol and software versions are accepted. the P1 client-to-server message and its P2 server-to-client response handle all of that 🫶
clients also need a way to figure out what happened to earlier transactions if the client or merchant crashed in the middle or lost data since then 😭 there are two transaction query messages, TQ1 and TQ2. TQ1 just asks, and TQ2 asks and cancels the transaction if it hasn't finished yet. both of them get a TQ3 response from the server.
since everything runs in a query and response mode, there are two spots where special error messages come in clutch 🔥 if a query looks like an unknown or undeterminable type, the server sends the UNK1 response error message. if a response looks unknown or undeterminable, or if some other serious error happens at the client or merchant and it should be logged at the CyberCash server, then the client submits a DL1 diagnostic log message, and the merchant submits a DL2 one 🌸
4.5.1 P1 - ping 🏓
super lightweight check that the customer can reach the server. no crypto at all, so the overhead stays tiny 🍓
#####################################################################
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.the id is optional because the persona might not be set up yet 🧚
4.5.2 P2 - ping-response 🎀
this is the reply to the P1 light weight ping. also no crypto, to keep things snappy ⭐
#####################################################################
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.so swversion never shows up in P1, for security reasons 🔒 that means swseverity and swmessage only appear when the server can tell from the $$ header protocol version that things are old. supported-versions tells the client right away which versions work and, by implication, which don't. and the client doesn't have to say what version it's running, so nothing security-wise gets compromised 👑
4.5.3 TQ1 - transaction-query 🔍
client asks the server about the status of a previous transaction (or a few of them) 💖
#####################################################################
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.the opaque part is generated from the CyberCash encryption key that cyberkey points to 🗝️ the signature covers id, date, transaction, cyberkey, type, swversion, begin-transaction, and end-transaction 🫶 and begin-transaction and end-transaction can be the same value if you're only checking one transaction ✨
4.5.4 TQ2 - transaction-cancel 🛑
client asks the server about a transaction's status, and tries to cancel it 🙈
#####################################################################
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.this is basically TQ1 with a plot twist 😈 it's the client trying to cancel a previous transaction or transactions. same signature rules apply, and begin-transaction and end-transaction can match here too 🌈
the transaction-cancel transaction (TQ.2) is defined between the client and the server. it lets the client check the status of an operation, and also stop that operation from happening if it hasn't already 💅 iconic behaviour, honestly 👑
4.5.5 TQ3 - transaction-response ✨
Okay bestie, this is the reply the server sends back after a TQ1 or TQ2 🧾 It's the receipt for your query or cancel request, and it's giving very "here's what happened to your payment, babe" 💅
Sender: CyberServer
Receiver: CyberAppSample 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 time, and this part is lowkey important 🫶
report-feeis the heads-up that this report cost a fee. It only shows up if there's actually a fee 💸- The same transaction number can show up more than once, because one payment could have had an auth, a post-auth-capture, a void, and so on. Iconic, right? 🔁
Some terms you need to know:
- "original transaction" means the payment or other transaction being queried or canceled. Plot twist: it might not actually live on the server anymore 👀
- "request" means the TQ2 or TQ1 message that asked for this report.
Here's the field rundown:
id: the id from the request messagedate: the date from the request messagetransaction: the transaction from the request messageserver-date: the current date and timetype:transaction-responseresponse-code: the response code for the request message, which can be one of:- "success" means the request message was processed. It does NOT mean anything about whether the query or cancellation worked. Read that again, it matters 💅
- "failure-hard" means the request message wasn't processed because it was ill-formed or otherwise inoperable 💀
- "failure-swversion" means the request message wasn't processed because of software revision problems 🙈
message: this only applies to the TQ transaction itself, not to the status of whatever's being queried or canceled. It depends on the response-code:- "success": the message is omitted 🫧
- "failure-hard": use the standard hard failure message
- "failure-swversion": use the standard swversion message for fatal
swseverity: applies to the request messageswmessage: applies to the request message
Then there are the per query/cancel fields, where N is a series from 1 to N. Bestie, it's a whole lineup 🧚
transaction-N: the transaction number of the original transaction. If the original isn't on the server, it's the transaction number the query or cancel request was referring to.transaction-status-N: the status of the original transaction, which can be one of:- "success": the original transaction was successfully processed. If the request was a TQ2, the cancellation is NOT performed. 🙅♀️
- "failure": the original transaction wasn't successfully processed. If the request was a TQ2, the cancellation isn't performed either. Honestly though, there's nothing to cancel, so it's all the same to the customer app 🤷♀️
- "pending": the original transaction is still being processed and the final outcome isn't known yet ⏳
- "canceled": the original transaction has been canceled by the server. If it shows up late, it won't be processed, and it'll come back with a "failure-canceled" 🚫
server-date-1: the server-date field from the original transaction, or omitted if the original transaction isn't on the serverdate-1: the date field from the original transaction, or omitted if the original transaction isn't on the servertype-1: the type field from the original transaction, or omitted if the original transaction isn't on the server
4.5.6 UNK1 - unknown-error 🙈
This is the "I have NO idea what you just sent me" response 😭 It goes out when the request is so messed up that you can't figure out what type it is, or the type is one the sender doesn't know. It can go from Merchant to Client, from Server to Merchant, or from Server to Client.
Sender: MerchantApp or CyberServer
Receiver: CyberApp or MerchantAppSample 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 one gets sent when the receiver can't find or understand even the type of the message 🫠 It always starts with the type and unknown-error-message fields. Any fields from the request that were parseable get echoed back with "x-" stuck on the front. So if you see an x-opaque, it's whatever the opaque was in the original request. Iconic echo energy 🔁
If you can decrypt the opaque section, do NOT put the results in here in the clear. Keep that stuff private 🔒
A few more things, bestie:
- The
{}s in the first column are only there to group alternatives. They don't show up in the actual message 🧩 - Customers start exchanges with merchants and servers, and merchants start exchanges with servers. So this message only gets emitted from the merchant to the customer, or from the server to the customer or merchant. ✨
- It should generally just get logged for debugging purposes 🪵
Heads up, because this is a real one: you may need to watch out for denial of service through forged or replayed UNK1 messages. Stay alert, babe 🚨
4.5.7 DL1 - diagnostic-log 🩺
This one is the client's diagnostic log of a bad message from either a merchant or a server. It's basically the client saying "hey, look at this weird thing I got" 📋
Sender: CyberApp
Receiver: CyberServerSample 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/wi7nwExplanation time 🎀
- The client app doesn't expect a response to this message. Ghosting is the vibe 👻
- The decrypted original message goes in the opaque section, unless decryption fails. If decryption fails, the undecrypted opaque from the original gets sent instead 🔐
- This message goes to a different script, socket, or host than normal messages do. That way it just gets absorbed and never triggers a UNK1 response or anything, even if this message itself is a total mess 🧹
4.5.8 DL2 - merchant-diagnostic-log ✨
Okay bestie, this one is a merchant diagnostic log 🪵💅 The merchant sends it to the server when it gets a bad message back. It's basically the merchant saying "hey, something's off with this one" 🙈
Sender: CyberMerchant Receiver: CyberServer
Here's a 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==-$$The opaque key is generated from the CyberCash encryption key identified in CyberKey 🔑
Here's what the opaque section looks like once it's decrypted 🦋
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/wi7nwSo here's the tea ☕ The merchant app doesn't expect a response to this one. The decrypted original message goes in the opaque section, unless decryption fails. If decryption fails, the undecrypted message gets sent instead 🫶
Also, this message goes to a different script, socket, or host than the normal messages. That means it just gets absorbed, and it never generates an UNK1 response, even if the DL2 message itself is messed 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-error5. Future Development 🚀
CyberCash is extending the facilities available through the CyberCash system. We're committed to building a full cash system 💸 That includes efficient transfer of small amounts of money, extending the credit card system to handle terminal capture and clearances, and other improvements too ✨
5.1 The Credit Card Authorization/Clearance Process 💳
Okay, so there are six steps in credit card processing. The first four are always involved when a transaction is completed. The fifth and sixth are optional 🫶
- authorization: the merchant contacts their acquiring bank, which normally contacts the card issuing bank. The bank returns an approval/guarantee or a disapproval to the merchant. This temporarily decreases the available credit on the card 💅
- capture: the merchant enters the charge information for a purchase into a batch 🧾
- clearance: a batch of items is processed. This actually causes the items in the batch to show up on credit card statements, as sent by the issuing bank to its cardholders 📬
- settlement: the actual interbank transfer of net funds 🏦
- void: the merchant undoes step 2 (or 6) and removes a charge (or credit) from a batch. Must be done before the batch is processed ⚠️
- credit: the merchant enters a "negative charge" or credit into a batch. This will appear on the cardholder's statement 💜
The fourth step, settlement, is entirely within the banking community, so it doesn't concern us here 🏦
CyberCash 0.8 provides messages to do steps 1, 1&2, 2, 5, and 6. That's enough for credit card processor systems where the batch is accumulated at the bank, or between the bank and the merchant. CyberCash 0.8 supports these "host capture" systems 🌈
Other credit card processor systems make the merchant accumulate the batch. These are often called "terminal capture" systems. This makes actions 2, 5, and 6 internal to the merchant, but it does require messages to perform action 3 🧚 Those batch clearance messages will be included in future versions of the CyberCash merchant and server software 🔥
5.2 Lessons Learned 📚
The continuing rapid development of the CyberCash system has been such an interesting experience. The system has to deal with lots of existing browsers and legacy banking systems. Existing credit card processors that pass transactions to acquiring banks have complex and varied interfaces. And the sophistication of security attacks on the Internet is growing super fast 😭
Given how quickly everything changes, it was essential to adopt a general message framework, so messages and fields could be added as they turned out to be necessary. Trying to shrink the system to a small number of perfectly optimized messages up front would have doomed it to failure 💀 (As of mid-October 1995, the total number of CyberCash messages defined is just over a hundred. That includes the ones planned for cash and microcash, enhancements to the credit card system, and some old messages being phased out in favor of improved replacements.)
Flexible operational and error handling facilities are also, as usual, the bulk of the system 🛠️ Version numbering and tracking has turned out to be really important, and merchant versioning is being added 🎀
Using text for messages has proven very beneficial 💖 It makes it easy to deal with messages using everyday tools like text editors and spreadsheets. Binary TLV (type, length, value) encoding or something similar is definitely possible, but it adds a lot more complexity for every tool that has to deal with the messages 🙈
Encryption and decryption cause some development headaches 🔐 If anything is confused about decryption keys or algorithms, the encrypted material becomes meaningless. Tools are needed to provide decryption for debugging outside of normal program operation. But that's nothing compared to the strictness that signatures demand 😭 All parts of the system must have absolutely identical ideas about the exact bit patterns to be hashed or signed, and their exact order. Even seemingly trivial differences in capitalization, punctuation, framing, order, or the like, along with any disagreement about keys or algorithms, will lead to frustrating signature mismatches 💅 Passing signatures through an intermediate system and checking them at a third system makes things worse. That's what happens when a customer's signature is passed through a merchant and checked at the CyberCash server 🫠
6. Security Considerations 🛡️
The CyberCash Version 0.8 Credit Card system provides substantial protection to payment messages, as described above in sections 1.2, 2.2.4, and 2.2.5. However, it provides no privacy for the shopping interaction, which is essentially outside of its purview 👀 It also provides no protection against dishonest merchants beyond the protections normally available with credit card purchases. Care must be taken to avoid losing control of the machines where parts of this system runs, or security may be compromised 🚨
Current credit card dispute resolution systems require deliberate bypasses to be implemented for some of the security normally established by CyberCash, as described in section 3.4. This is serious, bestie. Don't skip it 💀
References 📖
- [ISO 4217] - Codes for the representation of currencies and funds
- [ISO 8583] - Financial transaction card originated messages - Interchange message specifications, 1993-12-15.
- [RFC 822] - Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, UDEL, August 1982.
- [RFC 1521] - Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft, September 1993.
- [RFC 1766] - Alvestrand, H., "Tags for the Identification of Languages", UNINETT, March 1995.
Authors' Addresses 💌
Donald E. Eastlake 3rd CyberCash, Inc. 318 Acton Street Carlisle, MA 01741 USA Phone: +1 508 287 4877 EMail: dee@cybercash.com
Brian Boesch CyberCash, Inc. 2100 Reston Parkway, Suite 430 Reston, VA 22091 USA Phone: +1 703-620-4200 EMail: boesch@cybercash.com
Steve Crocker CyberCash, Inc. 2100 Reston Parkway, Suite 430 Reston, VA 22091 USA Phone: +1 703-620-4200 EMail: crocker@cybercash.com
Magdalena Yesil CyberCash, Inc. 555 Twin Dolphin Drive, Suite 570 Redwood City, CA 94065 USA Phone: +1 415-594-0800 EMail: magdalen@cybercash.com
📦 where this page comes from
- ietf: rfc1898 1996-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms