Bart Wesselink - Processing large quantities of online payments

published May 13, 2016, last modified May 17, 2016

Bart Wesselink talks about processing large quantities of online payments, at PyGrunn.

See the PyGrunn website for more info about this one-day Python conference in Groningen, The Netherlands.

I am here on a personal basis, not on behalf of a company, although I am a finance guy at SFX Entertainment, and formerly at PayLogic.

  • Online payments: digital certainty of cash over cash. It is real-time confirmation that you will get your money and can deliver a product.
  • Large quantities: high volume in a short span of time.
  • Unit of measurement is transactions per seconds.
  • Every second of downtime is revenue lost. This can be as high as 3000 euro per second for some companies.

Standard online payment environment has four corners:

  • consumer
  • merchant
  • issuer/consumer bank
  • acquiring/merchant bank

The scheme or payment method can be VISA, which is intermediary between the two banks.

This model has several 'single points of failure'. What we can make redundant, is the PSP/Gateway between the merchant and his bank. Service Level Agreements are useless here: you will never get back anything close to the money you lose. So redundancy is key.

Partially: offer the consumer different ways to pay: credit card, ideal, etcetera. And, when the consumer decides to pay via VISA, you want to have a few options: if one payment provider has problems, then another can fill the gap.

Monitor how well each route is performing. On iDeal (a payment system in the Netherlands) you can now get a message when there is a known problem with a bank.

Credit card plus expiry date is enough for most credit card payments. But there is 3DSecure: extra security for VISA. But: there is more that you need to monitor.

From the first six credit card digits you can learn a lot. There are databases for this, showing card brand, country, card level, etcetera.

Remember: stay compliant to

There are horror stories, like a local payment method that could only handle 1.5 transactions per second.

Lessons learned. Big names does not mean big performance, even for banks. You see sloppy implementations. Do logging and monitoring, lots of them.