Process Flow of a Credit Card Authorization

I was looking for an old file on an old computer and ran across some old documents.

Here is something that I put together in 2003:

OP_FC

(Click for full sized version)

Merchant ID's are not Amounts

I was reading this on MSNBC.com a short while ago:

A commuter in Richland, Wash., who thought he was overcharged — by $81 billion — for a tank of gas instead may have been confused by an e-mail about the transaction, his debit card company suggests.

Juan Zamora told the Tri-City Herald newspaper this week that an e-mail he received from PayPal showed a debit card transaction of $81,400,836,908, instead of the $26 worth that he said he pumped.

But a spokeswoman for PayPal, Sara Gorman, said Friday that Zamora may have been confused by a merchant identification number that appeared along with details about the transaction in the e-mail. “I can assure you that we did not charge him $81 billion,” Gorman said.

Thats a lot of gas !

Common Point of Purchase (CPP)

The Merchant Account Blog has a great post and great diagrams on what is called Common Point of Purchase or Point of Compromise (POC), this is one method of how a merchant or processor can be identified as the breach point in a payment card fraud / compromise scenario:

Fraud Detection

(from Merchant Account Blog )

Visa also has a presentation on this here:

When End-to-End Encryption is really not End-to-End.

I’m reading a lot about solutions that implement end-to-end encryption, where account numbers and track data is encrypted and can utilize a Hardware Security Module (HSM) and DUKPT or other encryption algorithms from the point-of-sale. I thought it important to share what data is actually encrypted in the payment system.

Here is a list in no particular order:

Gateways:

(contact me and I’ll add you if you are not listed)

Most of these are ISO’s that sell you a merchant account and access to their gateway that uses “end-to-end” encryption and that it will shift the PCI and PA-DSS burden from you to them, if you are a merchant, some claim you don’t even need to go through PCI compliance because you don’t have access to the card numbers or the encryption keys to decrypt the cards (Please also see this post on this subject). This is all really good stuff, I’ve written about End-to-End Encryption before and am a big proponent of it. This can help prevent “sniffers” and card capturing malware from capturing track data and account numbers in the clear as they traverse your internal network. Attackers would either need to install card skimmers or gain access to encryption keys, or use brute force methods against captured encrypted data to capture data at your store.

But it isn’t really End-to-End Encryption.

Let look at two examples:

  1. A typical small merchant using a payment gateway
  2. A large retailer or processor/gateway that uses a payment switch

A typical small merchant that uses a payment gateway:

Slide2

A large retailer or processor/gateway that uses a payment switch

Slide1

( uses leased lines to connect directly to a Payment Processor (FDR, Chase/PaymentTech, Fifth Third, MPS, etc ) or Interchange Network (VisaNet, BankNet, etc )

Let’s say that you are using a gateway or even a switch that supports an encrypted message format from the point-of-sale (POS). The area in RED in each diagram shows where the account number traverses the payment networks in clear text. At the small merchant example from the Gateway to the rest of the network - the account number and track data and CVV2/CVC2 data is sent in the clear. In the direct connect model with the Payment Switch (which actually just operates as a local gateway) from the payment switch to the rest of the network. So End-to-End is really not End-to-End at all. (it depends on where you define end :) This should also explain why End-to-End Encryption in its current state would not of prevented the breach at Heartland Payment Systems - as a processor they need to connect and communicate over the interchange networks using TCP/IP connection and ISO-8583 messages to these endpoints.

Why is this ? The Payment interchange networks and message formats that processors and the Interchange networks use does not support this in their current message formats (primarily ISO-8583) There is no room in the current implementations of Visa’s Base1, MasterCard’s MIP, or FDR’s message formats for example. Data Elements can be added to support this, but would require massive changes to Payment Systems infrastructures and systems.

Does any one have any solutions for this ? Please provide comments below – I’ll provide a follow-up blog post with some of my ideas.

Remember that End-to-End is really not End-to-End, it may shift or transfer some of the compliance “burden” from the merchant to that of the processor, but still exists in clear text on private networks and at processors. Oh, and tokenization and secure card vaults would work the same way here, the cards need to be translated to their raw value to ride the payment networks.

Obopay Widgets - part II (Obopay Widgets share your mobile number)

My plan to take over the world using capital financed by mobile payments (using Obopay Widgets ) has been put on hold, you see I don’t really want to share my cell phone number with you. I have a fear of getting SMS and text messages and mobile calls that I really don’t want and exorbitant fees on my mobile statement. You see the new Obopay widgets that I blogged about here, act differently the the Obopay buttons that I used in my first campaign here: Let’s look at the two different methods:

OboPay Buttons:

Send me $1 by cell

When you click on it to send me $1:

obopay-button

(notice - you don’t see my cell phone here)

OboPay Widgets:

When you click on it to send me $110:

1-13-2009 3-58-22 PM

(111) 222-3333 is my cell phone number (no not really) that is accessible to anyone who visits the Obopay Widget. Why did they not implement this like they did the “buttons” ?!??!

Obopay Widgets

logo_noshadow

I saw this press release: Obopay Introduces Bailout Tools for the Rest of Us:

With millions turning to friends and family for a personal bailout in the form of a little extra cash, Obopay, the pioneering service provider for payments via mobile phones, today announced three widgets – small applications that can be added to web pages such as blogs and profile pages – to help people give, donate and pay money quickly and easily. Receiving and sending money with Obopay to friends and loved ones online has never been easier.

Here is my Obopay Widget in action:

(***note this widget is not configured to use my cell phone***)

Get code to create your Obopay widgets here.

I personally don’t like the fact that Obopay allows for anyone to view your cell phone number, after they click though the “widget” if it is configured with your cell phone number. I see SMS Spam and un-wanted cell calls with this.

Gift Card Activation Patent Lawsuits

I was reading Evan Schumans’ blog post Sears, OfficeMax Agree To Pay In Gift Card Patent Lawsuit, this evening. It appears that there is a company called Card Activation Technologies that has a patent on a gift card validation process:

The Patent itself (click for full text of Patent 6,032,859) was filed in 1996, and it anticipated the next wave of gift card and phone card usage. At the time, the cards were issued for a specific value and then thrown away when emptied. The Patent envisioned POS units that could add and deduct value. Such POS processes are commonplace today, and therein lies the Patent infringement issue.

I have not read the patent in detail, I probably will - but I found this interesting. The article has stated that other companies have either settled or agreed to a licensed agreement with Card Activation Technologies.

Payment Systems Blog : Predictions for 2009

Gypsy_fortune_teller

I got out my Crystal Ball and Tarot Cards out and thought it would be fun to share some 2009 Payment Systems Predictions.

Here they are in no particular order:

Reduction of number of Stores for retailers: The Economy will not be kind to retailers and speciality shops in 2009. We will see stores closing; as the economy expanded retailers expanded, and the inverse will be true. This means that companies will be looking to the expense side and looking for innovative ways to reduce operating costs that have a fast ROI and payback. This will be in systems and back-office standardization and migration from expensive legacy platforms and large maintenance agreements. Decrease in jobs means decrease in spending. Any governmental based stimulus program needs to ensure that monies provided for “kick-starting” the economy are controlled in a manner that they are spent and not saved or used to pay down existing debt.

Gift Cards: You or someone that you know will have a gift card, merchandise credit/refund card for a merchant that is no-longer is business in 2009. Gift givers will take note of this and consider giving cash rather then gift cards in holiday 2009 season.

Issuing Banks: When the “times were good” people could live with negative savings rate, and see the value of their home increase, this increasing equity plus mortgage refinances allowed people to live beyond their means. Many consumers’ behaviors will not change, and we will see a run up of credit card debt. Credit Card Issuers will be trying to mitigate this risk, and will reduce credit lines, increase fees and rates, and be more restrictive in their underwriting processes. For some issuing banks we may see similar bailouts to that of mortgage companies and consumers are unable to pay.

Interchange Rates: There will be continued pressure by merchants to the Card Brands to lower interchange rates, and Issuers lobbing to increase them to cover increased losses on bad debt. Alternative payment structures and card types and acceptance and Cash Discounts will be offered to consumers and driven by merchants to reduce cost of accepting payments.

End-to-End Encryption: We will continue to see a proliferation of “End-to-End” encryption options that are based on or mirror Mag Tek’s MagneSafe offering - More Terminal Manufactures will be using capable devices, and payment gateways solutions here as well. PCI Council with notice this and consider making this a requirement in a future version of the PCI DSS.

PCI Data Security Breaches: There will be data breaches of cardholder data in 2009. We will see more innovative attacks that replace those that were effective before PCI compliance was a wide spread. Even organizations that are validated “PCI Compliant“ will not be exempt. We will see attacks that adapt and change around current PCI Controls.

Mobile Payments: 2009 will be the year of push of mobile payments, with many new entries in this space and those fighting for mass acceptance. The contact-less infrastructure that has been put in place will be used and leveraged by mobile phones at card acceptor locations using Near Field Communication (NFC).

Cloud Computing / Hosted Payments Platforms: 2009 will see more applications that are typically ran in the back-office of certain types of companies to the “cloud” - the proliferation of virtualization and commodity servers allowing this, and Amazon EC2, Microsoft Azure and others including vendors that provide cloud based access to their software solutions. IT Security Buffs and PCI Auditors will debate PCI and Cloud Computing.

iPhone Credit Card Terminal

screenshot-iphone-terminal-testvisa-thumb

innerfence has developed an iPhone App called the Credit Card Terminal. It is a thin application that acts as a front end and uses an Authorize.net Merchant account using the Authorize.net API over SSL. Looks pretty neat and a useful option for mobile acceptance of credit cards.

Looks like innerfence is a Authorize.net reseller, since you can use any authorize.net merchant account - I suggest you shop around the the best rates, theirs appear to be a little high.

I’ll put this in the “Why didn’t I think of that ?” category.

EDIT: Check out this link to the innerfence blog where there is a video on the app, and its integration to another iPhone App - Ring It Up Point of Sale.

Card Readers in Vending Machines

Years ago I assisted a company that developed magstripe readers that would operate in vending machines, copiers, laundry machines for a project related to college campus cards. My part was to assist them with both the message formats, connection methods, as well as selecting transaction types and device captures modes (Host Based Capture works the best in this model, BTW) for integration to a payment switch and authorization host and ultimately certifying the different devices.

While I was in Dallas last week I took a snap shot of a vending machine that had a similar device:

12132008059

These are not new, but I don’t visit Vending Machines like I used to and don’t see that many Vending Machines that accept payment cards. This appears to be a model from USA Tech called the ePort. I got a water and coke for a total of $3.00, btw :)

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×