RSS

Category Archives: credit cards

Back on privacy issues

In a conversation with my father in-law this morning…

(a) there was a time when your social security number was truly secret. Now everyone from the cable company, ISP, newspaper boy, lawn service, High School, University, hospital and doctor wants your SSN and we give it freely and without challenge. Who really knows why a doctor or newspaper delivery service needs my SSN. Are they going to sue me into and after I’m buried? In Sweden the SSN is sacred; I’m just not sure how they get around the problems we have. (could be functional and/or legal)

(b) There is no privacy on the internet. Whether your using any of the big name browsers, you never login, you always use other people’s computers or cyber cafes. The challenge is that between the ISP, browser manufacturers, super/affiliate advertisers, search engines; they where where you have been and where you are going. Not even the like of TOR is going to save you. Same goes for the anonymous breadcrumbs you thing you are dropping. They will always lead “them” back to you.

In a side note. If you’ve ever seen or purchased from one of those “as seen on tv” infomercials. The deals are great. Essentially you pay for shipping which costs them much either, however, it does offset their costs somewhat. The “play” for these companies is to get you to buy something. Anything.  This way they capture you personal information which they will resell at a profit. This is how all of these marketing machines work. One interesting thing… I have never experienced an increase in the amount of spam I receive. Hmmm.

Another side note. Over the last 18 to 36 months there have been some data breaches amounting to tens or hundreds of millions of credit card numbers and personal information. So why haven’t more people been complaining about credit card fraud? Why haven’t news programs done additional reporting? I wonder if we’re being marketed to because the credit card infrastructure is just not that sophisticated.

 

Beware of mobile payments

With the likes of PayAnywhere and Square are making moves in the mobile payment space one should always remain vigilant when handing your credit cards to anyone.

To start. PayAnywhere and Square; while they are a Point of Sale(POS) application implemented on a mobile device they are really a mobile merchant payment device or mPOS. The distinction is going to be important because for the time being these devices are riding the coat tails of the in-app and cardholder facing payment in order to get marketshare.

Cardholder facing payment services and apps require that the cardholder install an app on their mobile device. The vehicle for installing the software is typically a 3rd party like the Apple AppStore which acts as a vetting process for the app vendor.

Merchant facing apps, while it’s a good idea that the apps are installed from a 3rd party like the appstore, it’s not required.  A merchant can, in fact, develop their own application, download a development version of the application to a mobile device, and you’d never know the difference. They could be skimming your credit cards in plain sight.

With an mPOS application, like most traditional devices, you are the mercy of the merchant that they are trustworthy, however, unlike traditional POS devices where there is typically a professional service organization supporting the device. Most mobile devices are self maintained or maintained by amateurs.

The point I’m getting to here… mPOS devices and payments are not any more or less secure than traditional POS systems. Make sure you trust the merchant or the clerk with your card before you hand it over.

PS: Square does offer an interesting alternative. It’s s suite for the cardholder and the merchant that lets the cardholder initiate the payment from the cardholder facing device then is loosely integrated with the merchant facing device.

 

Tags: , ,

The History of my Payments Experience

During a phone screen this weekend I was asked to describe all of my payments experience in a 2-3 page cover letter. I quickly wrote an outline and started filling in the blanks and submitted my first draft. This morning I printed the first draft which was now 7 pages. I have since cleaned up the spelling and much of the grammar. It’s not meant to be a memoir and some descriptions are subjectively technical; and I’ve left out details that professionals should already know. Anyway here it is.

—-

The following text represents the many payment systems I designed, implemented, supported, updated, managed, and contributed to in some way. It should be needless to say that I have worked on other projects in other vertical markets and other languages. I trust you will see the value that I bring to the business as well as the technology. One final note. These are my personal accomplishments. Sometimes I was part of a team and sometimes I worked alone it just depended on scheduling, resources, SME, etc.

In 1993 I started working, as a contractor, for NaBanco (acquired by First Data) as a contractor. I designed and implemented a TSR, written in assembler, for their FoxPro/DOS hospitality application. The TSR was designed to connect to each of the property’s Zon terminals and download it’s transactions. It would then post the transactions in the FoxPro database. Later the FoxPro app would send all of the aggregated data to the NaBanco’s host via the TSR. One last thing that the TSR would do (in the days prior to the popular internet) was a trivial email service for HQ to communicate with the properties.

After this project was finished my manager recommended me to the HR department. I interviewed with and was hired to design and develop the ValueLink platform. This was a closed loop stored value system. The First client, BlockBuster Video, needed a working platform ASAP. Once the hardware was selected I went about defining the toolset. Having evaluated Informix, which was currently running on NaBanco’s debit system, I decided on Oracle with PRO*C and a RAD GUI development tool from Computer Associates.

There were a number of tough challenges in designing this system. At the time I did not have any experience on Sun hardware and while I had worked on databases for years I did not know much about SQL other than the evaluation I had just performed. Additionally I had to learn multi-threading, multiplexing transactions over X.25, and everything that comes with OLTP production support. And while I had experience with the Zon terminal there was still a lot more to learn.

The next challenge was the helpdesk. I implemented the first desktop app with a toolset from CA (Computer Associates). The app lacked performance based on the PCs at BlockBuster’s offices in Ft Lauderdale. I used a 2400 baud dial up modem to connect the two locations. Shortly after the project went live I hired a VB programmer to rewrite the application, however, since the application was also going to be used internally we were going to have a lot more users connected than I wanted. So I implemented a REST/SOAP-like server using Java and Java WebServer from Sun. It worked brilliantly and was later used by the IVR subsystem.

Finally, I was introduced to Perl. I used Perl to implement two major systems. The first was the card account creation in order to generate plastics and send them to manufacturing and I also used Perl for generating product performance reports (TPS reports).

In the end I was able to implement a fast, flexible, and reliable system that now transacts over 700 TPS every single day(with plenty of headroom) and hosts thousands of merchants and over 500M accounts.

This platform’s most notable accounts include: BlockBuster Video, Walmart, Starbucks, and the USPS.
WildCard Systems was a client of First Data, however, during the early stages of their discovery it was decided that First Data was not going to be able to deliver. Mostly because they were going in a different direction. Since many of the people who were engaged in the conversation were friends it was easy for me move over.

At WildCard I was tasked with designing a different type of open loop stored value card system. I had implemented the first multi-wallet system that was to be used by insurance companies in order to pay or deliver money to the insured. While WildCard eventually circled back to HSA, FSA and eligibility applications they moved away from direct insurance applications.

The authorization system was implemented in two parts. The first part was a java based front end system that would connect to the association, reformat the transaction (the process of message normalization), adapt to network impedance, and then execute the particular transaction request against a set of T-SQL stored procedures and complex data configuration with rules. This front-end system was eventually certified to work with: Visa, Amex,MasterCard, Discover, First Data Resources. The overall platform replaced Visa’s LAC platform.

Early on it was discovered that the state of the art PC was not going to keep up with our needs so I implemented a rudimentary replication engine in java. This application would sync 4 master-master database servers in different data-centers over a dedicated WAN connection. Eventually others in the department as well as Microsoft tried their hand at replication.

I designed a template language that could emit html, pdf, txt, and csv files. This was written in Perl and was intended to limit the roundtrips to the DB. As a domain specific language it was non-trivial to produce reports and the demand was greater than the staff could produce. Eventually all of the data had to be replicated to a farm of 5 database servers in order to produce the reports.

One of the newer projects I worked on was “WebDog”. This internal-use webapp performed a number of functions supporting the operations staff. (1) it was a production migration management system, where developers wanting to submit code for production would write a ticket that had to be approved and the app managed the workflow. (2) it monitored all of the SQL Server databases. (3) It monitored all of the front end processors. (4) the most important thing it monitored was the approval ratio. When the ratio was out of spec we knew there was a release problem. (5) lastly it was responsible for deciding which SQL Server was the current master.

This killer app was conceived on a beach in Nantucket; modeled after Star Trek, deployed on FreeBSD, used MySQL, written in Perl, receiving requests via apache and mod_perl, and templated responses with Mason.

Notable clients included: AAA, Bank of America as well as the Visa Buxx brand.

After leaving WildCard I decided to work on a side project. One of the last discussions we had at WildCard had to do with TPS rates. The existing system was only working at about 25-TPS at 100% CPU Utilization (8 CPU with 16GB RAM). I posited that (1) there was a problem with our SAN. It has been reported that period SAN drives suffered from brown-outs. (2) there many examples based in truth bashing MicroSoft and SQL Server. Oracle was so much more performant. (3) T-SQL was a pig, all of the code was essentially doing hash lookups O(1) using a relational search O(lg(n)).

So I submitted two papers to SleepyCat, the makers of Berkeley DB. The papers represented payment system designs based on BDB and BDB-XML. I received two honorable mentions. I also implemented one of my designs using Java and BDB. I was able to get 1500TPS on a single core, single spindle drive.

**sidebar** by this time in my professional development I had discovered erlang. The notion that if a language like erlang can offer 9-sigma, if implemented correctly, in a phone switch environment then how different could that be in payments. 9-sigma would be a great platform/language to implement payment.

What attracted me to eDiets was a similarity to a side project I was working on, however, one of the projects I implemented for the company was a prototype erlang merchant gateway. This allowed their internal payment system to connect to different acquirer systems. The first prototype was implemented in erlang and later it was replaced with a java implementation as an ATG plug-in. The team was excited about the erlang potential, however, management steared the company toward more java.

I joined MetaVentures to support their existing CRM platform for Verifone magstripe devices. The Perl application communicated device configuration and transaction details to/from the Verifone devices. Since I had payment knowledge I was tasked to design and implement a complete end to end payment system. This included; POS, HSM, merchant gateway, and PCI compliance. The HSM and merchant gateway were implemented in erlang. The POS is a mix of languages including Perl, C, SQL and bash.

While the erlang systems were interesting to construct it was uneventful. Certifying with multiple acquirers was as simple as changing the message templates. They have been running without interruption since they were installed. There are necessary enhancements, however, none of the current team members really want to spend any time on erlang. (to be continued later)

The POS was interesting in that it needed to support a kiosk mode browser in javascript which used websockets to communicate with local webservice daemons that were connected to barcode scanners, scales, customer facing displays, pin pads, and a magstripe reader.

The gateway was certified with RBS, Global, and First Data. And is PCI compliant.
Insight Card Systems implemented a Ruby/Rails platform for account and card management. At specific times of the day it would perform account balance updates to a service provider and the service provider would send transaction details back. The system suffered from a number of problems including reporting performance and reporting accuracy. Even though I was the director of development I was optimizing the SQL and training the programmers on new ways to get more performance out of their platform, and making production operations decisions. Furthermore I implemented proper release process in order to reduce downtime and improve release quality.

As the director I had a number of other roles and assignments. I needed to hire more staff and bring development in-house. (currently outsourced). I also had to redesign a system that had 5-10x capacity with the same hardware that was currently at 100% capacity. And I had to address client expectations and customization.
I started Florida Freelance because of the economic times we live in. I had a couple of contracts that I knew I could work on. The first was a VOIP arbitrage system that generated about 1M minutes a day in call volume. This was an integrated Asterisk switch and a connected dashboard. I was tasked with redesigning the system because the original system was dropping calls, losing calls, performing badly, and could not handle the volume they needed. While this project is not a payment system is does demonstrate my ability to scale.

My second client, a bill.me.later-like company in Stockholm Sweden; hired me based on my experience. They wanted me to contribute to their existing platform and help them design new applications in areas I had detailed experience. Their platform is implemented in erlang, however, I built several interfaces in java and C as part of another plan to unify their message passing and logging. I also performed a complete PCI audit of their HQ and operations centers in Stockholm.

**sidebar** One of the interesting features of erlang is hot-code replacement. The erlang core allows developers to replace modules on the fly without interruption. However, while many erlang programmers think this is a cool feature it is actually a detriment to payment systems. Hot-plugging code causes transactions in flight to become unreproducable due to the version mismatch of sub-modules through the transaction. From an operations POV, if you are going to switch master/slave or HA configurations in order to release new versions… then you might as well restart the app. This way you are assured that the app will restart.

A recent client in Portland Oregon, asked me to perform a number of projects. The first was a one-day design and overall roadmap for their future issuing platform and to see whether I was compatible with the CEO. A few months later they asked me to perform a due diligence on a potential payment vendor’s platform. And finally to design a custom issuing system for them in the EU. This was to include to EMV for chip. Shortly after beginning this part of the project I was tasked to design the same for China Union Pay.

Another client in Atlanta Georgia; has decided to rewrite their erlang gateway and HSM. While the system has been running this entire time it still suffers from the inability to enhance the application. Initially they wanted to implement the new platform in C but I convinced them that Python/tornadoweb/redis was a good choice. They recently certified with WorldPay on the first attempt. The entire project took less than a month.

There was a brief moment when I was having second thoughts about Python. The team was made up of Perl programmers, however, their tech lead was not grocking it and wanted a chance to contribute and python was going to be a lot easier for him to learn and easier still for the others to adopt.

So that’s about everything payments. I look forward to fielding any questions you might have.

 
Leave a comment

Posted by on 2012/05/07 in credit cards, for hire

 

More Credit Card Fraud, Where is the Bank Fraud?

I just wrote an article about credit card fraud… but here’s some food for thought.

Computers have been in banking for a good many years. Probably since the 1960 or even a little earlier than that. But in recent history we hear about credit card fraud and not banking fraud. The systems are typically integrated and supposed to be equally secure… but the attack vector is always credit cards.

I wonder of saying it was credit card fraud (a) allows the banks to charge more for credit cards (b) allows the government and banks to say our banking and reserve system is secure.

The thing to think about… the credit card company (the issuing processor and all entities) they do not need your social security number. For anything.  Your bank does and they do not need you card number(s).

There are many ways to fix this problem (a) laws, (b) banks (c) technology.

 

Credit Card Fraud! Again? Really?

I’m somewhat of an expert when it comes to credit card systems. I have worked for the likes of NaBanco, First Data, WildCard Systems, MetaVentures, Insight Cards, Klarna, NXSystems. I have also collaborated and certified directly with Visa, MasterCard, American Express, and Discover. I have also designed open and closed loop systems including stealth platforms like insurance eligibility. Finally I have participated in several PCI audits as the target and the auditor.

Yet I was still outraged when I received a letter from a major card brand that my account had been compromised; they go on to reassure me that my social security number and some other private details have not been compromised.

Let me be perfectly clear here.  *** This is utter and total bullshit !!!  ***  I’d like a chance to repeat myself but that might be gloating or looking for business.

Firstly; PCI and may other security and privacy measures are not as secure as I’d like. PCI takes the rent-a-cop approach to security. Observe and record. There is nothing in the PCI document that tells the institution to take an active role.

Secondly; The Rules and Regulations for the various major associations does not go any farther than the PCI when it comes to detection or the active prevention of fraud. Again, observe and record. And unless you are doing something that is going to hurt the brand-name the issuers and acquirers can take whatever risks they deem necessary to capture and keep a cardholder.

The CEO of Klarna (Sweden) is always talking about removing friction from the transaction process. His company’s product does not use credit cards and is similar to Bill Me Later (temporary credit is offered on the fly). Part of what makes his product successful is not that his customer’s credit is tied to their SSN but that the laws in the countries that Klarna operates is mindful of how this private information is being used and in fact the it’s not so private. It’s about as common as your cell number.

who are the players in the credit card process

GLOSSARY

(*smiley*) This is the cardholder. The cardholder is on both sides of the picture because the cardholder deposits his hard earned cash into a bank or makes partial or full payments for credit that had been provided. The cardholder also buys goods or services from merchants. Therefore the cardholder is on both sides of the credit equation.

(M) This is the merchant. The merchant provides goods and services to cardholders. The merchant also pays a percentage of each sale to all of the entities to the right.

(MB) The merchant bank is where the final settlement funds are deposited once the transactions cleared.

(GW) The gateway processor is considered a 3rd party service provider. They provide some level of transaction, reporting or security service for the merchant. They may provide other types of business integration or workflow.

(GW Bank) Depending on the acquirers rules the gateway processor has a clearing bank in order to capture their commission from the day’s transactions.

(AP) The acquiring processor is just a technical entity that processes transactions between the merchant and the association. The AP does not actually have to be a bank but they need to be bank sponsored.

(A Bank) The acquiring processor bank performs the clearing function for the acquiring processor, however, more importantly this bank sponsors the AP’s relationship with the association.

(association) Visa and MasterCard are associations of banks. American express is referred to as an association but was a privately held company at one time. Discover was spun off from Sears and is/was also a proper bank.

(IP) Like the AP, the issuing processor does not need to be a proper bank. The IP need only be sponsored.

(IP Bank) The issuing processor bank handles the clearing and settlement on an on-demand basis. Sometimes this entity is extending credit to the cardholder and sometimes this entity is holding the cardholder deposits. It depends on the individual card program.

(Bank) The cardholder bank is where there cardholder interacts with deposits and payments.

Authorization – this is the first part of a 2 or 3 step process (from the merchant). It depends on where the transaction is being performed. If you are buying a book from the book store then this is the first of 2 transactions. It’s just intended to see if you have enough funds. If it’s a gas station or a restaurant then it’s a pre-authorization — because it is absent of a tip.

Settlement – the settlement process takes place at least once a day (from the merchant). It is when the point of sale device tells the issuers what transactions were actually completed. This triggers the clearing and settlement process.

Clearing and Settlement – The association takes all of the settled transactions and groups them together sending like transactions to the individual issuing processors along with a “demand” file which the issuer uses in order to pay the association.

Single Message System – this is when the authorization and the settlement transaction are performed in one transaction. ATM transactions are typical single message system(s).

PS: There are few differences between credit cards and debit cards. I suppose the actuary have a different view of this but it amounts to the same results. It’s still a 15 or 16 digit card number.

The Short Version

What does all of this mean?

The cardholder bank makes money when you deposit money and potentially gives you a fraction back as interested, once they have charged you fees. The cardholder bank also makes money during the clearing and settlement process as “demand”. The bank does pay processing fees of a sort but the majority of the bank’s gross revenue comes from the transaction.

The reality is that the merchant pays the freight on card transactions. And that is passed through to the cardholder.

NOTE: if you want to create an issuing processor from the ground up then I strongly recommend that you get someone to do the IP for you. Get some cardholders and capture the transaction revenue. You can also use your own system (although you might be processing on someone else’s IP at least you are getting instant discounts. I hope that makes sense) This is the reason that Discover can return 5% on all transactions and the similar for Costco-Amex and others.

What does it all mean?

Someone in the diagram above lost or allowed to be stolen; my data. Whether or not that data is used to perform actual fraudulent transactions should not be my problem. I pay to get the card. I pay to use the card. And I get a fraction of the value in interest if I do nothing… except fees for not using it.

This letter that I received should not be a “get out of jail free” card for whichever entity permitted my data to leak. I should be able to sue them individually because any class action lawsuit only benefits the lawyers and not the cardholders. In fact they should just start dumping money on my doorstep in advance of any bad thing that might happen. And more importantly I will be watching my credit scores for the rest of my life… looking over my shoulder waiting for someone to take advantage.

PS: Suzy Orman once said that you should never cancel a credit card. If you do it will negatively effect your credit score. I have a Delta/Amex frequent flier card that I do not use.  They charge me $100/year for membership and I get nothing in return except that they extended me some credit that I have to pay for anyway if I elect to use it.

In the US our laws seem to protect corporate America and not America. What is good for corporate America is not always good for me!

In Summary

We are not safe and we are paying too much.

I almost Forgot

… the reason for writing this post in the first place.  The association that sent me the letter recommended that I check with the various credit bureaus in order to see whether my personal information was in fact being used. True, that is an option, however, the credit bureaus only give me one or two free reports a year. And if you’ve ever used their services they harass you with FUD and other tough sale pitches and tactics in order to get you into a subscription. The wording in their online Apps is so questionable it was obviously intended to get me or anyone else to make a mistake.

Really what I’m suggesting here is that this service needs to be FREE for the individual. Forever.

 

Tags: ,

Dynamic Languages and PCI-DSS

Some security experts, including myself, thought that implementing financial software using dynamic languages would create a security threat for the “company” or the account holder. However, as I sit here this morning contemplating an open source payment platform delivery system I realize that it’s a silly hypothesis.

Forgoing all of the traditional attack/fraud vectors I’m thinking about the code. The PCI-DSS covers the production hardware and database(s) but it also covers the developer’s computers, build machines, staging and QA, and the code repository. The “processor” is expected to treat the securely and equally. (this highest priority goes to the encryption keys and devices).

So if an attacker can get to any of these systems and inject code then you really have a bigger problem than whether the code was Python, perl or Ruby. Of course since Java can be executed anywhere then it can also be compiled anywhere. Reverse engineering Java and then recompiling is no more or less difficult. Of course injecting code into a Java or C based system is more complicated if the attacker is already in… regardless of the programming language, you’re cooked.

As I continue to consider my open source project it’s just a matter of selecting the right dynamic language for it. I want to be productive enough that the extra time can be spent on physical security instead of the false hopes of obfuscation.

 

Tags: ,

New Years Resolution – Reduction

I’ve decided that the word that will describe 2012 is reduction. In that spirit I have noticed that I have a number of articles in my instapaper queue that need to be read. Once they are read I will do my level best to reduce the number of articles that I actually collect. So if I’m scanning my news feed the criteria for a read later is going to be more strict. But let’s review the stories so far.

  • reducing code nesting: We’ve been talking about this since CS101.
  • SQL to MongoDB mapping: I really like mongo but the argument for SQL is too strong. There is no need for an end user mapper… just implement SQL.
  • programming competitions: really?
  • Assembly Language Hello World: It’s not much bigger than a DOS assembler version of the same. It’s not the assembler that I grew up on.
  • DropBox Automator: only if you do not care who reads everything in your account.
  • scripting the un-internet: history repeats itself is not the same as a loop.
  • Digital Wallets: They’ve been talking about digital wallets for years. No one is interested.
  • Interarchy: interesting and possibly helpful. Needs better docs because there are side effects to every action. Would be nice if you were in the app store.
  • Trying to mount a file system: So may bad choices to select from. Since this is sensitive data how many to rey and trust.
  • Django Reusable Apps: It’s just a general outline from 50K feet. Would be nice if there was some sample code or at least a sample project template. (see python’s moder template)
  • Avoid Apress: I don’t think I care enough to read this article. Not sure I know why I saved it in the first place.
  • “good enough”: It’s a maturity thing. At some point some of the details no longer matter. For this reason ideas like PEP-8 and Agile no longer matter.  GTD is more important.
  • Rob Pike: I like GOLANG but this guy seems to be off the reservation.
  • Lua 5.2: This would be better of the BDFL-Lua were more open. They only release about every 18 months and it’s just not that interesting other than it’s small footprint.
  • Show and Tell MongoDB: How many times is the same talk going to be linked to?
  • Burn DVDs on OSX Lion: There are a number of articles and most try to solve the problem. The real issue is that Apple does not include iDVD with new machines. Therefore iLife is not really installed with a new machine.
  • Mongo’s write lock: First Python’s GIL and now this.
  • direvn: Interesting but a bad/incomplete description. Integration with rvm and virtualenv should be addressed better.
  • different by design: Maybe, but it’s not enough to be different… you need to be good too.
  • Credit Reports: credit reports and social security numbers need better consumer protection; whatever that needs to be.
  • Don’t hire remote programmers: I need to read this one for company research.
  • Hire more remote programmers: I need to read this one too.
  • Renegade: I don’t think we agree on the role of a CTO.
  • MySQL to Solr: I’m not going to read this article because I think Solr is not a DB but a search tool like Lucene.
  • For-if anti-patterns: This does not help anything. Check your O() at the door.

(I have about 10 more… I only allocated 30 minutes for this post… so in the interest of reduction; this is it.)

I thought I was done… this one caught my eye and the rest have been deleted before I waste another momennt

  • Pay your programmers $200/hr: I’ll be reading and rereading this one. I’m not sure that I warrant 200/hr but then I’m certain that the electronic traders do not. Not that they are smarter or willing to take risks but that they make mistakes too and the results are much like football games of old without a replay system that can keep up and rules that allow for correction on a grand scale. Even in football; once the next play has been started and the clock ticking there is no looking back.

And two keepers that I have not read yet but are worth a last minute reprieve. The future of retail, and recruiting for a startup.

Happy New Year! Welcome to 2012!

 

OLTP benchmarking is hard to do

I’ve built a number of successful OLTP systems used in the creditcard/prepaid card market place. One of these systems performs at around 12M transactions a day and the other around 900K. The first system has a lot more headroom. The CPU, disk and network are barely breathing. The latter, on the other hand, struggles and over the last few years I have found myself up late thinking about it.

The 12M system is running on Sun hardware running an Oracle database backend. The application was written in C using Oracle’s embedded SQL. This one application runs multiple instances on the same box as the DB and the entire hardware/software stack is duplicated per client. This application connects directly to the internal network where OLTP transactions are routed from the company’s internal POS devices for the closed network cards and from the credit card associations for the open network cards. This application also provides APIs that are called by the other applications for services like the help desk, card boarding and plastics etc. Reporting is performed in perl and connects directly to the database.

The 900K system runs on big honking Dell PCs with a SAN to store the data and ease backups. The stack is a Microsoft SQL server stack with the business logic implemented as stored procedures and the message normalization for transactions coming from the associations written in Java. The number of asynchronous socket connections with all of the associations can be duplicated as needed. Same for the gateway hardware that processes these transactions. The transaction is then sent to the database as a call into the first stored procedure which gets a list of the rules, implemented as other stored procedures, that this transaction is made up of. As control passes from one stored procedure to the next the data it collects and works on is rolled into the parameter call stack in order to prevent rereads from the DB. The actual execution of the stored procedures is not bad and for that matter it was a decent implementation and it met or exceeded many of the design requirements; if I can say so myself. But it was still too slow.

I failed to mention a few details. The 900K system implemented 4-way master-master replication. Each machine was processing every transaction from every source. Just think about when batch fees-processing was running! [update] each node was an 8core system with 4 or 8 GB memory for each code.

So where did we go wrong? Well I have a checklist:

  • The 12M system only had 5 tables, the 900K system had over 100 tables in the auth system.
  • Many of the 900K tables should have been in code either hard coded or preloaded during startup.
  • The transactions in the 900K system were lazy. They only read from the DB when they needed data meaning that there were more roundtrips. And in some cases there was some lock escalation.
  • Some of the indexes used btrees instead of hashes.
  • Some tables simply had too many indexes that did not apply and were never used confusing the optimizer and just taking more time.
  • Using a document approach for an account should have improved performance overall. If the document included all of the account information and the current transaction history all in once place.
  • Logging is a killer. The more logging you do equates to more I/O which clearly steals large fractions of a transaction. Consider Redis. They say that they can something like 1M TPS. But if you log 100 messages into their pubsub then you are only going to get max 10K TPS. Now if you read and write to an MQ several times in a transaction then you will experience other performance robbing events. (we did not use an MQ, however, we did a lot of logging)
  • While modern SQL is getting better there are all sorts of arguments for going NoSQL. This works to an extent but it puts a different burden on the design team. You now have to implement a robust API set that you would otherwise defer to some SQL magic.

I think that covers things. I did a small proof of concept after I left the 900K company. I implemented a system without logging, using a document container for the account, using hash indexes for the tables that were important, limited the number of tables overall, eliminate SQL (thank you BerkeleyDB/SleepyCat). And do all of this on very modest hardware. I managed to get 1400 TPS on a very modest CPU.

Now the things I did to get these numbers are not totally unreasonable, however, they break a lot of rules from the business point of view. Business owners like to be able to perform root-cause-analysis. Especially when something bad happens. So some about of logging is inevitable. SQL is really important for report generation specially when the genius programmers cannot be bothers.

So there is room in my head for yet another full blown system. If you look over to the Box Files section in the sidebar there are some system designs that I’m putting together. I’m hoping that someone might actually pay me to develop them. Any takers?

 
Leave a comment

Posted by on 2011/08/05 in beta, credit cards

 

Tags: , , ,

Who has had experience of using a prepaid card and finding that it has gone over its limit?

I have been travelling in South Africa, Germany, Canada and France recently, using my money-saving, secure and trusty prepaid travel cards (Euro, Dollar and Global Traveler cards). On two occasions, I have discovered that I have used spent money than I had money on the card.

Has anyone else had this experience? And can anyone explain why this happens, and when?

Tony

Richard Bucker • There are several reasons why this happens. As someone indicated that when there is a auth-hold… however, this will prevent the second transaction from going over the limit. This real issue in these cases is when the merchant adjusts the transaction amount (like a tip) after the auth… and based on the MCC there is a percentage that the merchant can adjust.

Then there are the system’s related issues, like load-balancing, latent database replication and maintenance cycles. If you’re not careful and the cardholder is nefarious there are ways around some of these components that allow the CH to appear to have more funds; if even for a short period.

As others mentioned; from a business/brand perspective the associations need to implement some changes. However, the biggest change will come when they more accurately define the differences between an anonymous prepaid card; an identified prepaid card; and a debit card… from a transactional and business perspective.

Losses will only mount as cardholders and merchants learn to game the system.

 
Leave a comment

Posted by on 2011/07/02 in credit cards

 

Tags: ,

A new approach : HamsterDB

Revisiting my favorite subject again, credit card processing, the hamsterDB’s description on the NoSQL website triggered an alarm.

hamsterDB – (embedded solution) ACID Compliance, Lock Free Architecture (transactions fail on conflict rather than block), Transaction logging & fail recovery (redo logs), In Memory support – can be used as a non-persisted cache, B+ Trees – supported

The key words being “lock free”. In any typical CC issuing system you can expect to see transaction times from 50 to 500ms depending on the amount of work the authorization system has to perform, DB latency and locking.

Typical transaction workflow looks like some code that just tries to get some data from the DB, do some work, get some more data from the DB and do some more work. And while performing I/O with the DB you always have to be ready for a failure. Typical failures are deadlocks, consistency because another process updated a record and so on. And when you think about the breadcrumbs and trying to recover from these failures it simply makes the code more complex.

update account set balance=balance-10.00, version=version+1 where ccnumber=? and version=11;

With the hamster approach you can and should get all the data that you need from the DB upfront at the beginning of the transaction. Keep in mind that in some use-cases this data could be prohibitively large so it’s best to completely understand the scope. Then do the workflow as you would normally… leaving you with a set of DB updates/inserts that need to be executed. So execute them.

Now if anything goes wrong you have choices. 1) retry the DB changes from the last step; 2) retry the workflow from step two; 3) retry the entire transaction. It simply depends on the nature of the write failure and what you determined was the best recovery.

And here’s why this is better. Given the performance profile for an authorization (50-500ms) and the timeout that is permissible by the association (10-45seconds depending in the trantype) you can retry this transaction internally almost any number of times in order to get a positive response… providing the error was internal and not hardware, network ete related.

One other thing that did not escape my eye. Kevin Smith (formerly from Riak) is the erlang client maintainer. Optional encryption(great for PCI)

On the downside there is no replication, sharding, python, perl, or traditional C. However, the approach would be interesting for other platforms… almost there.

 
1 Comment

Posted by on 2011/06/23 in credit cards, database

 

Tags: ,

 
One Page Docs

Creating a library one page at a time.

One Page Bugs

Reducing the friction of writing and fixing bugs or features.

Follow

Get every new post delivered to your Inbox.

Join 223 other followers