- Both Basis Theory and Very Good Security (VGS) are PCI DSS Level 1 compliant tokenization platforms, so security certification alone does not separate them.
- Basis Theory positions itself as a developer-first data vault with no per-API-call pricing and broader PII coverage beyond card data; VGS built its reputation on proxy-based tokenization and a larger enterprise sales motion.
- VGS uses a forward proxy architecture that can intercept and tokenize data in transit without code changes; Basis Theory requires direct API integration but gives engineering teams more explicit control over what gets vaulted and how.
- Contract minimums, pricing transparency, and switching cost are where the two vendors diverge most sharply at the evaluation stage.
- Early-stage fintech teams with developer bandwidth tend to converge on Basis Theory; compliance-heavy enterprise teams buying alongside a QSA engagement tend to land on VGS.
Comparing Basis Theory vs Very Good Security comes down to one architectural question before any other: do you want a data vault your application calls directly, or a proxy layer that intercepts sensitive data in transit? Both platforms tokenize sensitive data, hold PCI Level 1 certification, and market to fintech engineering and security teams. Basis Theory fits seed-to-Series B companies that want a transparent API-first data vault for card numbers, PII, and custom sensitive fields, with no per-call pricing. VGS fits mid-market and enterprise fintechs that need proxy-based tokenization with minimal code changes and are buying compliance posture as part of a broader security program.
What Most Buyers Miss When Comparing Basis Theory and VGS
The feature pages look nearly identical because both vendors are solving the same regulatory problem: getting your application out of PCI scope by vaulting raw card data behind a tokenization layer. That surface-level similarity is exactly why engineering teams spend three weeks evaluating and still feel uncertain.
The real fork in the road is architectural. VGS operates primarily as a forward proxy, sitting between your application and downstream processors. Your app sends the raw PAN to VGS, VGS tokenizes it in transit and forwards the alias to the processor. Basis Theory operates as a direct API vault: your client-side SDK or server-side API call sends data directly to the vault, which returns a token your app stores and uses downstream. That architectural difference drives almost every other trade-off in this comparison.
A fintech founder evaluating these two vendors for the first time usually frames it as a security question. It is actually an integration architecture question with compliance consequences.
Choose Basis Theory If / Choose VGS If
| Decision factor | Choose Basis Theory | Choose VGS |
|---|---|---|
| Integration model | You want explicit API calls and developer control over what enters the vault | You want proxy-based interception with minimal code changes to existing flows |
| Data types | Card data plus broad PII (SSN, bank account numbers, custom fields) | Primarily card and payment data; PII coverage is narrower out of the box |
| Pricing model | No per-API-call fees; Basis Theory has publicly stated this as a differentiator | Pricing is quote-based and not publicly disclosed; expect volume-tiered enterprise contracts |
| Stage | Seed to Series B companies building net-new infrastructure | Series C and beyond, or companies with existing proxy-friendly architectures |
| Compliance posture | PCI DSS Level 1, SOC 2 Type II; good for reducing scope | PCI DSS Level 1, SOC 2; strong QSA-ready documentation and enterprise audit support |
| Developer experience | RESTful API, SDKs, Terraform provider, open documentation | Proxy configuration, route management; steeper learning curve for non-proxy architectures |
| Support model | Self-serve docs, community Slack, paid support tiers | Dedicated customer success at enterprise tier; less accessible for early-stage teams |
| Switching cost | Token portability is a stated product principle; migration tooling available | Proxy dependency creates deeper architectural lock-in over time |
How Do Basis Theory and VGS Actually Work?
Basis Theory’s vault-first architecture
Basis Theory treats the vault as the primary object. You call the API to create a token, store that token in your own database, and use Basis Theory’s reactor functions or proxy to send the underlying value to third parties without ever decrypting it in your own environment. The vault holds the sensitive value; your system holds only the token reference.
This model makes it straightforward to vault non-card PII: Social Security numbers, date of birth, bank account numbers, custom fields for lending underwriting data. The token schema is flexible. A Series A lending startup can vault the same infrastructure it uses for card numbers to also protect income verification data pulled from a payroll API, which matters when you are thinking about broader fintech compliance readiness beyond just PCI.
VGS’s proxy-first architecture
Very Good Security intercepts HTTP traffic through its inbound and outbound proxy layers. An inbound route captures raw card data from your checkout form before it touches your server; an outbound route replaces the stored token with the real value when calling a downstream processor. Your server never sees the raw PAN.
For teams that already have a functioning card collection flow and want to reduce PCI scope without refactoring their API layer, this is genuinely compelling. VGS has cited, in customer case studies published on its website, savings of nearly $1M and six months of development time from a single implementation. That reflects the proxy model’s core strength: you configure routes rather than rewrite code. The trade-off is that your network architecture now depends on VGS routes being available, correctly configured, and maintained as your processor integrations change.
How Do the Two Platforms Handle PII Beyond Card Data?
This is where Basis Theory has a structural advantage for companies building beyond pure payment flows. The vault-first design treats any byte string as a tokenizable object. Teams at lending platforms, insurtech companies, and healthcare-adjacent fintechs have used Basis Theory to vault SSNs, driver’s license numbers, and even raw document content alongside card data in a single vault.
VGS’s core product was designed around the payment tokenization use case. Its proxy routes are optimized for card data flows, and while VGS does support some PII use cases, the product depth, SDK coverage, and documentation for non-card sensitive data is thinner than Basis Theory’s. If your threat model includes protecting GLBA-covered financial data, FCRA-covered credit file data, or HIPAA-adjacent records alongside cardholder data, Basis Theory’s breadth is a real differentiator.
For pure PCI tokenization with no PII complexity, the gap narrows significantly and the proxy model’s ease of implementation can tip the decision toward VGS.
What Does Basis Theory vs VGS Integration Actually Look Like?
Basis Theory integration path
A typical Basis Theory integration starts with creating a tenant (their logical isolation unit), generating API keys, and calling the token creation endpoint from either a client-side JavaScript element or a server-side SDK. Basis Theory publishes SDKs for JavaScript, Python, .NET, Go, and Java, plus a Terraform provider for infrastructure-as-code teams. The developer documentation is publicly accessible without a sales call.
The integration effort is real. You are changing how your application handles sensitive data at the point of collection, not configuring a proxy route. For a greenfield build this is straightforward; for a legacy system with dozens of touchpoints where raw card data flows today, the audit-and-refactor work takes engineering time. Basis Theory’s reactors (serverless functions that run inside the vault) can reduce some of this by handling transformation and forwarding logic without exposing values to your servers.
VGS integration path
VGS integration starts with defining inbound and outbound routes in the VGS dashboard, pointing your existing API calls through the VGS proxy URL, and updating your DNS or HTTP client configuration. For teams using a standard card collection form or a single processor integration, this can genuinely be done in days rather than weeks.
The complexity compounds when you have multiple processors, multiple environments, or custom transformation logic. VGS route configuration has its own syntax and debugging surface. Teams that have gone deep on proxy route management report that it becomes its own maintenance burden as integrations evolve. This is a known switching cost: unwinding proxy dependencies means touching every integration point that routes through VGS.
How Does Pricing Compare Between Basis Theory and VGS?
Basis Theory’s pricing page is publicly accessible. Their model does not charge per API call, which the company positions explicitly as a differentiator against per-call pricing models. Current public pricing tiers include a free developer tier and paid plans, though enterprise contract terms require a conversation with their team. The absence of per-API-call fees matters at scale: a high-volume lending platform making millions of tokenization and detokenization calls per month avoids a cost that compounds invisibly in per-call models.
VGS does not publish pricing publicly. Pricing is quote-based and volume-tiered, consistent with an enterprise sales motion. Based on market positioning, VGS contracts tend to be meaningful annual commitments, which creates a real evaluation threshold: early-stage teams may find the minimum contract size uncomfortable relative to their current transaction volume. This is worth confirming directly with VGS’s sales team before investing evaluation time.
Both vendors are infrastructure providers where the cost of a bad choice goes beyond the contract fee. Getting this decision wrong means either a re-architecture project or a compliance gap. The hidden infrastructure costs that compress fintech SaaS margins often include exactly this kind of vendor switching expense.
What Compliance Certifications Do Basis Theory and VGS Hold?
Both platforms hold PCI DSS Level 1 certification, the highest level of PCI compliance for service providers. Both also hold SOC 2 Type II reports. From a compliance posture standpoint, either platform can be used as the basis for reducing your cardholder data environment (CDE) scope in a PCI assessment.
Where they differ is in the supporting material and enterprise audit readiness. VGS has invested heavily in documentation designed for QSA consumption, including detailed shared responsibility matrices, evidence packages, and customer-facing compliance guides. This is a meaningful advantage for enterprise buyers who are running a formal PCI ROC (Report on Compliance) rather than a SAQ-based self-assessment.
Basis Theory’s compliance documentation is solid but more developer-centric in its presentation. For a Series A team doing a SAQ A or SAQ A-EP assessment, this is not a meaningful gap. For a Series D company running a full ROC with a Big Four QSA, VGS’s documentation depth may reduce QSA hours and therefore reduce audit cost.
Neither vendor eliminates your compliance obligations entirely. Tokenization removes raw card data from your environment but does not remove the need for access controls, logging, incident response plans, and vendor risk management. That broader compliance infrastructure is your responsibility regardless of which platform you choose. If you are still building out that foundation, the compliance mistakes that most commonly damage early-stage fintechs are worth reviewing before you finalize any vendor choice.
How Do Support Models Differ Between the Two Vendors?
Basis Theory’s support is tiered. The free and lower paid tiers rely on documentation, a community Slack, and email support. Higher tiers include dedicated support with faster response SLAs. Their developer documentation is genuinely comprehensive and publicly searchable, which reduces support dependency for technically strong teams.
VGS’s support model scales with contract size. Enterprise customers get dedicated customer success managers and implementation support. Early-stage teams purchasing at lower tiers may find the support experience less differentiated. Multiple developer community threads have noted that VGS’s support responsiveness varies by tier, which is a predictable behavior for a vendor with an enterprise-first sales model.
If your team has senior engineers who read documentation and build from first principles, Basis Theory’s support model is adequate. If you are a compliance-forward team that expects a vendor partner to hold your hand through a QSA engagement, VGS’s enterprise support is worth the premium.
What Is the Real Switching Cost for Each Platform?
Switching cost is where the architectural difference becomes financially concrete. Here is an illustrative scenario: a Series B payments company vaults 2 million tokens annually across card data and SSNs. After 18 months on VGS, the proxy routes are embedded in three separate processor integrations, two internal microservices, and a partner API flow. Migrating means auditing every integration point, regenerating or migrating tokens (which requires VGS’s cooperation and their token portability tooling), and testing each route before cutover. That is a multi-sprint engineering project, not a weekend task.
Basis Theory has made token portability a stated product principle. Their documentation covers token export and migration scenarios. The API-first model means your token references are stored in your own database, and migration tools are designed to let you move tokens without exposing the underlying plaintext values. That portability does not make switching free, but it does make it predictably scoped.
VGS’s proxy dependency is structurally deeper. Because the proxy sits in the network path, not just at the application layer, unwinding it requires changes to your network configuration, HTTP client settings, and potentially DNS. For teams that have been on VGS for two or more years, this lock-in is real enough that some evaluate staying on VGS simply because the migration project cost exceeds the savings from switching.
The FintechSpecs Data Vault Decision Matrix
Most evaluation frameworks for tokenization vendors stop at feature checklists. The FintechSpecs Data Vault Decision Matrix takes a different approach: it scores vendors across four dimensions that actually predict implementation success and long-term cost, not just compliance certification.
Architectural fit asks whether the vendor’s integration model matches your application’s data flow. A proxy-first vendor in an API-first application is a mismatch that creates ongoing friction. Score each vendor by how much existing code you need to change to integrate.
Data coverage depth asks whether the vendor can handle every sensitive data type your product roadmap requires over the next 24 months, not just your current use case. A pure card tokenization vendor becomes a blocker the moment you add SSN collection for identity verification or bank account data for ACH origination.
Pricing predictability asks whether you can model your year-two cost today. Per-call pricing creates unpredictable invoices as volume grows. Quote-based enterprise pricing creates commitment risk for early-stage teams. Flat or token-volume pricing is the most predictable structure at scale.
Exit optionality asks how hard it would be to leave in 18 months. Token portability, documented migration paths, and API-first architecture all improve exit optionality. Proxy dependency, proprietary token formats, and undocumented migration processes reduce it.
Score each vendor from 1 to 3 on each dimension for your specific situation. The vendor with the higher total score across your four inputs is the right shortlist choice, not the vendor with the better brand or the longer customer logo wall. The full seven-point fintech vendor evaluation framework , covering financial health, support escalation paths, contract exit terms, and integration risk alongside the four dimensions above , is worth running in parallel before you sign anything.
Which Fintech Use Cases Favor Each Vendor?
| Use case | Better fit | Reason |
|---|---|---|
| Card-not-present payment tokenization, single processor | VGS | Proxy routes reduce code changes; fastest time to PCI scope reduction |
| Multi-processor card routing with token portability | Basis Theory | Vault-first tokens are processor-agnostic; no proxy reconfiguration per processor |
| PII vaulting alongside card data (SSN, DOB, account numbers) | Basis Theory | Flexible token schemas; purpose-built for mixed sensitive data types |
| Lending platform with income and identity data | Basis Theory | Reactor functions can transform and forward non-card sensitive data |
| Enterprise with existing QSA relationship and proxy-compatible stack | VGS | QSA-ready documentation and enterprise support reduce audit overhead |
| Neobank or BaaS platform with high API call volume | Basis Theory | No per-API-call pricing prevents cost compounding at scale |
| Early-stage team, limited engineering bandwidth | Depends on stack | VGS if proxy is viable; Basis Theory if greenfield API build |
Frequently Asked Questions
What is Very Good Security (VGS)?
Very Good Security is a data security company that provides payment tokenization through a proxy-based architecture. Its platform intercepts sensitive data such as card numbers in transit, replaces them with tokens, and forwards the tokenized values downstream. VGS holds PCI DSS Level 1 certification and SOC 2 Type II. The company targets mid-market and enterprise fintech, payments, and financial services companies looking to reduce PCI compliance scope without rewriting application code.
Who owns Basis Theory?
Basis Theory is an independent, venture-backed company. It has not publicly disclosed investor ownership percentages or cap table details beyond standard startup disclosures. It operates as a standalone entity focused on developer-first data vaulting and tokenization infrastructure. For current corporate information, Basis Theory’s official site and press releases are the authoritative source.
Is Basis Theory or VGS better for PCI DSS compliance?
Both platforms hold PCI DSS Level 1 Service Provider certification, so neither has a compliance advantage on that credential alone. VGS has stronger QSA-facing documentation packages, which reduces audit friction for companies running a formal Report on Compliance. Basis Theory’s compliance documentation is solid but more developer-oriented. For a SAQ A or SAQ A-EP assessment, either platform works. For a full ROC with an enterprise QSA, VGS’s documentation depth provides a practical advantage.
What is the difference between proxy-based tokenization and vault-based tokenization?
Proxy-based tokenization (VGS’s primary model) intercepts HTTP traffic in transit and replaces sensitive values before they reach your server. Vault-based tokenization (Basis Theory’s model) requires your application to call the vault API directly at the point of data collection, receiving a token in return. Proxy tokenization requires less application code change but creates network-layer dependency. Vault tokenization requires more integration work upfront but gives engineering teams more explicit control and cleaner exit optionality.
Can Basis Theory or VGS tokenize non-payment PII like Social Security numbers?
Basis Theory supports flexible token schemas and explicitly documents SSN, bank account number, and custom field tokenization alongside card data. This makes it well-suited for lending platforms, insurance fintechs, and any product that handles identity data alongside payment data. VGS’s product is optimized for card and payment data flows; non-card PII tokenization is possible but less deeply documented and less commonly deployed on the platform.
How hard is it to switch from VGS to Basis Theory?
Switching from VGS to Basis Theory is a multi-sprint engineering project, not a configuration change. Because VGS’s proxy sits in the network path, migration requires auditing every integration point that routes through VGS, migrating or regenerating tokens (which requires VGS’s cooperation), and reconfiguring HTTP clients and network routes. Basis Theory publishes migration documentation and supports token portability, which makes the destination cleaner than the departure. Teams considering a switch should budget six to twelve engineering weeks depending on integration complexity.
Does Basis Theory charge per API call?
No. Basis Theory has publicly positioned the absence of per-API-call fees as a product differentiator. Their pricing is based on plan tiers rather than per-call consumption. This matters for high-volume fintech applications where tokenization and detokenization calls occur millions of times per month. VGS does not publish pricing; enterprise contract terms should be confirmed directly with their sales team before assuming cost structure.
Which vendor is better for a fintech startup at Series A?
Basis Theory is the stronger default for a Series A fintech building net-new infrastructure. The public documentation lets engineers evaluate and prototype without a sales conversation, the pricing model is more predictable at early volumes, and the vault-first architecture scales cleanly to multi-processor and multi-data-type use cases that Series B and C companies typically encounter. VGS makes more sense at Series A only if the team has a legacy codebase where proxy-based interception is genuinely faster to implement than an API integration.
What Does the Actual Evaluation Process Look Like?
Most engineering teams doing this evaluation spend the first week reviewing documentation and the second week building a proof of concept. Basis Theory’s public docs support a working POC without a sales call. VGS typically requires a sales-assisted onboarding before you get production credentials. That asymmetry is itself a signal about which vendor is built for developer-led evaluation cycles versus sales-led enterprise procurement.
When you reach the contract stage, ask VGS for their shared responsibility matrix and their SAQ/ROC evidence package before signing. Ask Basis Theory for their token portability documentation and an example migration plan. Both requests are reasonable, and a vendor that resists either is telling you something important about how the relationship will go when problems arise.
If you are also evaluating how tokenization fits into a broader infrastructure stack, the complete map of the fintech infrastructure stack is a useful reference for understanding where a data vault sits relative to your identity, fraud, and payment layers.
The Single Most Important Insight from This Comparison
The vendors are not interchangeable, but the reason most buyers think they are is that both use the word “tokenization” to describe architecturally different things. VGS tokenizes data by intercepting it in transit through a proxy. Basis Theory tokenizes data by vaulting it through a direct API call. That difference determines your integration path, your switching cost, your pricing behavior at scale, and your data coverage ceiling.
Pick the architecture that fits your current codebase and your 24-month data roadmap, then confirm the pricing model does not create a budget surprise at your projected API call volume. The compliance certifications are table stakes. The architecture is the decision.
One final point on switching cost that rarely surfaces in vendor evaluations: the team that implements your tokenization vendor is usually not the team that inherits the maintenance burden 18 months later. Whatever you choose, document your token schemas, your reactor or route configurations, and your detokenization patterns in a format your future self can read. That documentation is cheap insurance against a vendor relationship that outlasts the engineers who built it. If your team is still defining infrastructure choices at this stage, reviewing the most critical mistakes when choosing fintech infrastructure can surface blind spots before they become contract regrets.
