Processing Payments in the Cloud

Andrew Barratt, Managing Principal, Solution Validation, Coalfire

Avocado and Toast
Peanut Butter and Jelly (or Jam for the Brits!)
Steak and Cheese
Milk and Cookies
Tea and Biscuits
Beer and Football

Some things work so well together that even suggesting they don’t now seems almost ridiculous. But I wonder, who were the pioneers that fought back when questioned about the jelly on the PB? The savory with the sweet. The steak wrapped in cheese . . . those crazy hipsters spreading avocado on toast.

Yet, now these are the norm, and so it’s time to embrace yet another: Payments and the Cloud. My teams work with some of the biggest payment processors in the world, and for years we saw reluctance, cloud inertia, and concerns over security and compliance. Some of these fears were reasonable at the time, such as concerns over outages and uptime – concerns that are reasonable when stepping into any commercial outsource-type of relationship.

However, the big public cloud providers have stepped on up; they can now move faster and provide significant security leverage to their customers and have invested heavily in compliance certification to prove they keep their security promises.

But why are Payments such a good fit for cloud, or to go one step further, serverless applications in the cloud? Interestingly, the answer is less about the technology and more about the business. Payment processing, in particular, card payments, monetary exchange, or transfer, are all transactional and generate revenue for the parties involved at the point of successful transaction, whether as a fixed fee per transaction or as a percentage of the overall value.

Historically, payment processors of all descriptions have required huge amounts of infrastructure to scale and compete; often, their onward transaction costs decrease with volume courtesy of economies of scale. However, this often leads to infrastructure being over-provisioned and the associated capital costs, maintenance, licensing, etc. all become fixed capital expenditure costs that bear no relation to the amount of revenue being generated. 

This is where serverless applications in the cloud can step in. Like the jelly on the peanut butter, suddenly, once the leap of faith has been taken, the results are quite sweet!

A payment processing app built to be serverless (such as a payment processing application built to run on Amazon Web Service’s [AWS] Lambda and using some DynamoDB for storage, for example) only really incurs any cost when it is in use.

This is where it gets interesting – suddenly, our revenue generation aligns with our costs. More importantly, our costs go down – when our revenue goes down. So instead of having to have a data center full of equipment that costs you money when it’s not in use, you can leverage the hyperscale infrastructure of a cloud provider like AWS and invest the difference in new, innovative payment solutions.

And to take another cookie with the milk, public cloud providers like AWS have invested so much in security and compliance that the compliance requirements left for you to manage can be significantly smaller and more trivial to manage.

Working at Coalfire, we get to see people take those leaps every day; and my colleagues in our Cloud team ensure those public cloud providers keep making it simpler! My financial services team helps banks, payment processors, and other financial services organizations understand both the risks and the new options available with the cloud providers we work with.  I’m curious to see what two things could go together better in the future.

Andrew Barratt


Andrew Barratt — Managing Principal, Solution Validation, Coalfire

Recent Posts

Post Topics



Accounting Agency AICPA Assessment assessments ASV audit AWS AWS Certified Cloud Practitioner AWS Certs AWS Summit bitcoin Black Hat Black Hat 2017 blockchain Blueborne Breach BSides BSidesLV Burp BYOD California Consumer Privacy Act careers CCPA Chertoff CISO cloud CMMC CoalfireOne Compliance Covid-19 credit cards C-Store Culture Cyber cyber attacks Cyber Engineering cyber incident Cyber Risk cyber threats cyberchrime cyberinsurance cybersecurity danger Dangers Data DDoS DevOps DevSecOps DFARS DFARS 7012 diacap diarmf Digital Forensics DoD DRG DSS e-banking Education encryption engineering ePHI Equifax Europe EU-US Privacy Shield federal FedRAMP financial services FISMA Foglight forensics Gartner Report GDPR Google Cloud NEXT '18 government GRC hack hacker hacking Halloween Health Healthcare heartbleed Higher Education HIMSS HIPAA HITECH HITRUST HITRUST CSF Horror Incident Response interview IoT ISO IT JAB JSON keylogging Kubernetes Vulnerability labs LAN law firms leadership legal legislation merchant mobile NESA News NH-ISAC NIST NIST 800-171 NIST SP 800-171 NotPetya NRF NYCCR O365 OCR of P2PE PA DSS PA-DSS password passwords Payments PCI PCI DSS penetration Penetration Testing pentesting Petya/NotPetya PHI Phishing Phising policy POODLE PowerShell Presidential Executive Order Privacy program Ransomware Retail Risk RSA RSA 2019 Safe Harbor Scanning Scans scary security security. SOC SOC 2 social social engineering Spectre Splunk Spooky Spraying Attack SSAE State Stories Story test Testing theft Virtualization Visa vulnerability Vulnerability management web Wifi women XSS