How to become PCI compliant for only $2.5k a year

A smart, secure, and cheap way to stop fearing compliance.

You decided to build a payments company. You’re ready to move money, until someone mentions PCI DSS and everything stops. You can’t process cards without it, and you can’t get it without processing cards (aka making money). The classic chicken and egg of fintech.

Then the meetings start. People throw around acronyms like QSA, SAQ, ROC and CVV while quoting security audits that cost $30k a year. You nod, but deep down you’re wondering if anyone actually understands what they’re talking about.

Spoiler alert: most don't, and just repeat what they overheard from someone in the security or technical department. But none of them actually went hands down to actually read the requirements. So I am here to save you a few bucks and headaches.

The truth is, PCI isn’t as mystical as it sounds. It’s just a set of rules on how to handle card data safely. And if you design your system the right way, you can be fully compliant for less than $2k a year. No consultants, no heavy teams, just smart engineering and a tool called Bluebox.

Now, lets get some background story.

PCI DSS, the Payment Card Industry Data Security Standard, was created in the early 2000s after a series of major card data breaches. Every card network had its own fragmented security rules, and breaches kept spreading across merchants and processors. Visa, Mastercard, and other brands agreed to create one unified standard that defined how everyone should store, transmit, and protect cardholder data.

PCI is not a government regulation but a private contract. When you process cards, you agree to follow these security standards as part of your relationship with your acquirer or PSP. If you fail, you can lose the right to process cards or face penalties.

Before diving into how to achieve compliance, it helps to understand what PCI actually protects.

Card data includes several components:
• PAN, the long number printed on the front of the card
• Cardholder name, the name of the customer
• Expiration date, the month and year when the card expires
• CVV or CVC, the short security code printed on the back
• Track data and PIN block, used by magnetic stripes or chips in physical transactions

Not all this data is treated equally. The PAN, name, and expiration date can be stored if encrypted and protected. The CVV, PIN, and track data cannot be stored permanently under any circumstance. However, there is one gray area that often creates confusion. The CVV can be stored temporarily for the time strictly necessary to process a transaction. This may be just milliseconds, or in some systems, a few minutes. What matters is that it is automatically deleted once the transaction is completed.

Bluebox was designed to handle this exact situation. When the CVV is received, it is encrypted immediately and replaced by an alias that your API or internal service can process safely. When the outbound request leaves your system, a Lambda function inside Bluebox replaces the alias with the real CVV, sends it to the PSP or acquirer, and deletes the data securely. DynamoDB manages this lifecycle through a time-to-live setting that erases each record after one minute, or any period you define. This ensures that even temporary storage of sensitive information remains compliant and fully auditable.

Now, to understand how to get certified, it is important to know how PCI defines levels of compliance. These depend on how many card transactions you handle and how directly you interact with card data.

Level 1 applies to merchants or processors that handle more than 1M transactions per year. It requires a full audit by a Qualified Security Assessor (QSA) with on-site inspections, penetration testing, and security documentation. Maintaining certification can cost between $25,000 and $75,000 annually (depending on the scope to be analyzed).

Levels 2, 3, and 4 apply to smaller companies that can complete a Self-Assessment Questionnaire, known as SAQ. The questionnaire you use depends on how your system handles card data.

• SAQ A applies if everything is outsourced to a PSP. (if you are a merchant for example)
• SAQ A-EP applies to e-commerce environments where your server controls part of the payment page.
• SAQ B and C apply to companies using physical terminals. (retail)
• SAQ D applies when your systems store, process, or transmit card data, even temporarily. Usually this is the one any prospect PSP, and the one we used early on Rebill. (SAQ D Service Provider)

Even for SAQ D, you must complete quarterly vulnerability scans and penetration testing. Companies like SecurityMetrics make this process simple and affordable. They provide a complete SAQ D package with vulnerability scans, an annual audit review, guided online forms, and a compliance certificate for around $2,500 per year. This program gives startups a realistic way to reach full PCI compliance without the cost of a Level 1 audit.

The key to staying in this manageable scope is designing systems that isolate cardholder data from your application. When a user enters their card number in a checkout or app, the data originates in the client, not on your backend. If that information is sent directly to a PCI-certified PSP endpoint, your system never touches it and remains outside the strictest PCI scope.

This is why every PSP provides SDKs or hosted fields. They handle the collection and encryption of card data in the browser or app and send it directly to their infrastructure. Your backend only receives a token that represents the card. The token can be stored, logged, and reused without risk because it holds no real card information. All communication must happen over HTTPS with TLS 1.2 or higher to ensure encryption in transit.

If you ever process or store cardholder data yourself, PCI requires strict technical controls that include software patching, network isolation, access restrictions, encryption key management, and detailed audit logs. For years, this meant buying hardware encryption modules, building secure rooms, and hiring consultants. That model no longer makes sense in the cloud era.

AWS changed the equation by certifying many of its core services at PCI DSS Level 1. Lambda and DynamoDB are two key examples. This means you can securely process encrypted card data using these services without auditing their internals because AWS already holds the certification. Your responsibility is only to design your architecture correctly and maintain isolation between sensitive and non-sensitive environments.

This change reduced the cost and complexity of PCI compliance dramatically. What once required tens of thousands of dollars can now be achieved with a few bucks in cloud resources if your system is designed with compliance in mind.

In 2018, after spending months studying PCI DSS, I came to a few core principles that guided the design of Bluebox.

• The PAN can be stored if encrypted with strong algorithms
• The CVV can be temporarily stored but must be deleted immediately after use, and this is automated in Bluebox with DynamoDB TTL
• Tokenization reduces PCI scope and limits exposure drastically
• Isolation is more valuable than complexity: the smaller your card data environment, the simpler your compliance

These principles became the foundation of Bluebox.

Bluebox is an open source, serverless proxy that securely replaces sensitive data before it ever touches your systems. It sits between your API and the outside world, intercepts requests containing sensitive values, encrypts them, replaces them with aliases, and stores the originals in an isolated encrypted vault.

From that moment, your systems only see and store the aliases. When your API sends data to a PSP or acquirer, Bluebox restores the real values securely in the outbound request through a Lambda function, completing the transaction and erasing the temporary data.

The flow looks like this.

Inbound traffic
Before: api.yourcompany.com → your API server
After: api.yourcompany.com → Bluebox → your API server

Outbound traffic
Before: your API server → PSP or bank
After: your API server → Bluebox → PSP or bank

Bluebox uses AWS services that are already PCI Level 1 compliant. Lambda handles encryption and data replacement, DynamoDB stores encrypted values, CloudTrail logs all API activity, CloudWatch monitors performance, Config and Inspector validate compliance, Secrets Manager manages encryption keys, and CloudFront serves as the proxy.

This design isolates your systems from cardholder data, making your PCI scope extremely small. The total cost of running Bluebox is about one dollar per month for up to a million records. During an audit, the reviewer only needs to confirm that Bluebox is configured correctly and that your systems never receive raw card data.

This architecture turns PCI from a painful process into an elegant design problem.

PCI is not about checklists or bureaucracy. It is about trust. Every time a customer enters their card number, they expect you to protect it. When you can demonstrate that protection through architecture and not just documents, you are not only compliant, you are credible.

Resources:

• Security Metrics PCI Package: https://www.securitymetrics.com/pci-small-business
• Bluebox.sh: https://github.com/nahuelcandia/bluebox