Building PCI-Free Payment APIs

Someone once told me that, “Payments are not just a payments problem.” 

At first, this sounds weird, but the range of businesses and personalities I talk to who are looking for payment-related solutions have been proving that statement correct. And in this blog post I want to discuss a problem that, surprisingly-not-surprisingly, is a payments problem that affects non-payments teams.

Many merchants, vertical SaaS solutions providers (logistics, manufacturing, hospitality, etc.), and e-commerce platforms come to us looking for ways to integrate new partners or customers into their APIs without adding PCI scope to their systems. Often, these integrations outline receiving sensitive information. 

For example:

1. As a merchant, I want to create a Checkout API to receive orders and payment information from partners, while being able to route the payment freely to my PSP of choice.
2. As a merchant, I want to enable AI Agents to purchase my products programmatically.
3. As a merchant, I want to receive payment information from IVR systems and other agent-assisted channels.
4. As a payment service provider, I want to receive credit card information via API to process pay-ins for PCI-compliant merchants.
5. As a business travel management platform, I want to receive booking and rental orders from expense management platforms and super apps.
6. As a loyalty management and customer engagement solution, I want to enable merchants to enroll consumer cards in loyalty tracking against the networks.
7. As an e-commerce provider, I want to integrate with platforms such as Shopify, Magento, and others, to expand my merchant's reach.
8. As a payfac, I want to offer my own acquirer API and widgets.

Every week, we learn about a new use case where a customer needs to accept sensitive payment information through an API layer, but feels allergic to adding compliance or security scope to their systems. 

For example, in Use Case #1 above, the merchant processes payments with a PSP elected based on optimization rules. Some PSPs do have mechanisms to receive payments programmatically from merchants’ partners, but typically, there are pitfalls:

• The payment information is now stuck inside that PSP, meaning the merchant can't “arbitrarily” choose where they want to process it. When you can get it out of the PSP, there are hidden or unpredictable costs.
• Lack of Customization Options: Stiff API contracts, minimal or zero whitelabeling capabilities, and limited or opinionated AuthN/AuthZ.
• Restricted sandbox environments, often behind paywalls or several approval layers. In many cases, you have to fully document your project to get approval, but you only wanted to do a quick POC to pursue an idea.

All of this difficulty leads to business in a tight spot, having to choose between:

1. Marry the PSP
2. Building In-Scope Layers
3. Deprioritize or Abandon the Project

What if I told you there is a fourth, and much better, option?

Proxies as a Solution 

Proxies are not a new solution in the PCI-descoping business. There are different flavors, definitions, jargons, and providers, of course.

Some are heavily indexed on configuration, if you are into that. Others are a black box: they will make what you need, for a price. Almost like that consulting firm you love working with. And there are a select few who will give your team the developer tools and infrastructure to build the solution you need.

The idea behind all of them is the same, though. When the client makes a request to the server containing sensitive information, it will be intercepted, and the sensitive data will be scrubbed off or replaced with an equivalent identifier (aka “token”), before it reaches the server. That way, the server—and that it represents (edge, firewall, load balancer, application layer, etc.)—is blind to the sensitive data, being rendered “out of scope.”

Notice how Your Server never interacts with the payment information directly. It can process the payment using the tokens created by the Proxy. 

Gotta Go Fast 🚀 

I wouldn't be writing this if I didn't want you to know how we solve this problem at Basis Theory.

We didn't reinvent the wheel, but we made it faster, better looking, highly customizable, and easier to use.

When handling PCI data, every millisecond counts. The Basis Theory proxy allows you not to just secure sensitive payloads—you’ll do so at speed, ensuring tokenization happens without slowing down any checkout or payment flows. Proxy Transforms are AWS Lambda-backed Reactors, which are tuned for low-latency execution and seamless integration with our API.

• Kept Warm for Instant Execution: Reactors are automatically kept warm to avoid cold starts.
• Optimized Internal Routing: Reactors connect directly to our API through internal, low-latency paths, cutting out unnecessary network hops.

Return to Top

Self-Serving All the Things 💁 

You can provision all the resources self-serve, either via management APIs, CLI, or Terraform.

Besides the obvious benefit of not having to talk to a rep to complete your POC (unless you want), this approach grants you:

• Speed to Market: You can provision all resources in minutes rather than waiting on manual onboarding.
• Developer Autonomy: Your team doesn't have to wait on ops, security, or vendor support—they can integrate directly from CI/CD pipelines. This reduces friction between compliance/security teams and product teams.
• Automation & CI/CD Integration: PCI descoping becomes part of the deployment pipeline: spin up proxies per environment (dev, staging, prod), run automated tests, then tear them down. This eliminates configuration drift, a common compliance risk.
• Consistency and Standardization: All teams and departments use the same compliant proxy pattern, enforced programmatically. This reduces the chance of someone handling card data “the wrong way” and accidentally bringing a system back into PCI scope.
• Auditability & Evidence: API calls and Terraform manifests provide a clear record of when and how the proxy was provisioned. It becomes easy to show auditors: “Here’s the code that provisions our tokenization boundary.”
• Reduced Risk of Human Error: No manual provisioning or configuration tweaks by an operator that could accidentally expose raw PANs. Automation enforces the PCI boundary safely every time.
• Faster Innovation with Less Compliance Drag: Teams can launch new payment flows, checkout experiences, or agentic commerce use cases without lengthy PCI impact analysis. PCI complexity is abstracted away, so product teams move faster.

Return to Top

Put a Ribbon on It 🎀 

For the sake of full transparency, the only step that absolutely requires interacting with our team is generating the DNS verification records for your custom domain. But that’s usually out of scope for most POCs and something you only worry about when getting close to go-live.

Once you’re there, you’ll want to “dress up” your proxy so it looks and behaves exactly how you need it. That means two things: shaping payloads to fit your custom contracts, and wrapping everything under your own domain.

• Custom Contracts: Your partners, clients, or legacy systems probably don’t care that you’re running a modern PCI-descope proxy. They just want their data in the exact format they expect. With Proxy Transforms (our managed lambdas), your developers can encode or decode payloads however they need — REST, XML, SOAP, GraphQL, or even that one custom schema your enterprise partner swears by. This makes it painless to honor strict contracts while still keeping PCI data safely contained in our CDE.
• Custom Domains (DNS): White-label the proxy behind your domain so it looks and feels native to your stack. No extra hostnames for customers to question, no vendor domains leaking into sensitive flows—just clean, branded traffic that builds trust and keeps things tidy.

Think of it as putting the final bow on your proxy: same security and tokenization under the hood, but wrapped in a way that fits your brand and your rules.

If you are interested in creating a Securely Descoped API, we have a step-by-step guide in our documentation that you can follow and start testing this right now:

https://developers.basistheory.com/docs/card-payments/receive-cards-api

Where to find me:

• LinkedIn
• Slack Community

Return to Top