Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!ncar!zaphod.mps.ohio-state.edu!casbah.acns.nwu.edu!nucsrl!telecom-request From: Ed_Greenberg@3mail.3com.com Newsgroups: comp.dcom.telecom Subject: Payment Processing Message-ID: Date: 21 Feb 91 17:48:00 GMT Sender: news@casbah.acns.nwu.edu Organization: TELECOM Digest Lines: 68 Approved: Telecom@eecs.nwu.edu X-Submissions-To: telecom@eecs.nwu.edu X-Administrivia-To: telecom-request@eecs.nwu.edu X-Telecom-Digest: Volume 11, Issue 148, Message 5 of 8 Originator: telecom@delta.eecs.nwu.edu In one of my past lives, I did data entry for the Mastercard (oops, I mean Master Charge) operation of a major New York Bank. (Chemical Bank.) Since the subject of payment processing has come up, I thought I'd describe the payment processing operation, and how we tried to be sure that everybody got the right payment credited to their account. Remember that in a bank, everything must balance to the penny. Payments were received in a mailroom and the envelopes were oriented by means of the stripes printed on the envelope edges. The envelopes were opened by machine and the check and billhead removed. The checks and billheads were separated into two piles and, when about one hundred transactions were accumulated, the piles were rubberbanded together. If a check came in without a payment ticket, one was written, assuming that the account number was on the check. If not, the check went to some sort of exception processing. If the ticket came in without a check, the transaction took a left turn there too. Next the batch went to the encoding machines. These behemoths would take a stack of checks and show them to the operator one by one. The operator would enter (ten-key) the amount, which would be encoded below the signature line. The amount was also printed on a tape, and when the batch was done, the total amount encoded was printed on the bottom of the tape. This total became the batch total and the magic number for the batch. Remember that everything must balance. The encoding department totalled ALL the payment batches, which were subtracted from the totals of all the charge batches (another article, maybe) and thus made part of the whole days business, which also had to balance before it could be released for posting. Next the payments went to Data Entry. The process was this: Open a batch on the terminal by providing the batch number and the total (generated from the encoding procedure.) Now key the account numbers and amounts into the terminals, taken from the billheads. This is why you write the amount paid on the billhead. Note that nobody has totalled the billheads yet. Once the billheads were entered, the terminal would present the batch total (from the checks) and the transaction total (from the billheads.) If they matched, you were "IN BALANCE", you released the batch and went on to the next one. If not, they were "OUTA BALANCE" (really!) and you had to prove them. Proving the transactions involved comparing the entered amounts (displayable on the screen) with the encoding tape. Several error possibilities present themselves. A keying error by the data entry operator, a keying error by the encoding operator, or a billhead that carried an amount different from the check. Once the transaction(s) were proved the batch would balance, and you would release the batch and go on to the next one. If you couldn't prove the batch in about ten minutes, you would hold the batch in the computer, and pass it to Sara. Sara had the eyes of an eagle or a hawk and could find anything. And that, friends, is how your payment got onto your Master Charge, back in 1975. edg PS: Trivia: Who remembers Unicard? What banks pushed it? What did it grow into? What was the logo? How about the jingle? Ed_Greenberg@HQ.3Mail.3Com.COM