Technical flow
Billing clarity without identity exposure.
Think of PrivacyBilling as an airlock between your app and the payment network.
Stripe handles card identity, we map events to pseudonymous entitlements, and your app checks paid status without storing card-linked data.
1. Processor
Checkout and card vaulting stay in Stripe.
2. PrivacyBilling
Events map to a pseudonymous entitlement record.
3. Your app
Query paid status without pulling card identity in-house.
Who handles what
PrivacyBilling is not a card processor. Sensitive payment data lives in your processor's certified environment (today: Stripe). We operate the subscription and entitlement layer on top—so your application tier is not the system of record for cardholder data.
Hosts Checkout and Customer objects, stores or tokenizes card data under its PCI program, runs fraud checks, and settles charges. This is where card numbers and bank-grade KYC/AML obligations for payment acceptance are meant to live, not in your codebase.
We do not handle card data. We receive processor webhooks and API signals, store subscription state and pseudonymous IDs, and issue entitlements and verification codes to your app. No raw PANs on our servers by design.
Holds your feature data and a site-scoped pseudonymous ID. You query us for “is this user paid?” without mirroring full payment credentials into your database, shrinking breach blast radius and supporting data-minimization practices your counsel can map to GDPR and UK GDPR duties.
We are not a law firm. Compliance depends on your sector, jurisdiction, and what else you collect. This split of responsibilities is a technical pattern many teams use to reduce unnecessary co-storage of payment artifacts and app telemetry.
Currently powered by Stripe. Architected to support:
Card data stays with the processor—not with us, not in your app DB
PrivacyBilling does not replace Stripe. We do not host primary account numbers. Your customers enter card details in the processor's Checkout or Elements flow; the processor vaults and charges under its PCI programme. We subscribe to webhooks and APIs so we know subscription status, then expose “paid / plan” answers keyed by your pseudonymous anonUserId.
Cardholder data, strong customer authentication where required, fraud tooling, and settlement. This is the right place for PAN/token storage under PCI.
Subscription bridge: maps processor customer/subscription IDs to your pseudonym, verifies webhooks, stores entitlement state. No raw card strings on our application servers by design.
Product data plus pseudonym and our API responses. You avoid copying full payment credentials into your stack—supporting data minimization and a smaller PCI footprint for your application tier.
Compliance angle: separating payment systems of record from general application databases is a standard way to scope duties and reduce unnecessary duplication of financial identity next to product logs. Interpretation for your organisation requires legal advice; we document the technical split clearly so you can assess it.
The Centralized Threat Vector
Traditional payment processors force you to bind a credit card to an email address, inherently expanding your enterprise attack surface. Centralizing this telemetry creates a massive structural vulnerability. A single data exfiltration event inside your database immediately compromises your users' strict biological identities.
Zero-Trust Privacy at the Edge
PrivacyBilling is a plug-and-play B2B API that acts as an aggressive edge-proxy, giving you enterprise-grade pseudonymous checkout out-of-the-box. We isolate the transaction entirely out on the API edge (intercepting it before it reaches your Origin DB) and return an encrypted authorization ticket back to your app. You receive the revenue, the user accesses the premium content, and you never have to securely hold their biological identity.
Privacy at the Edge Architecture
App Core
Biological IDs, core usage metrics, application logic. Zero billing data.
API Edge
Isolates PII streams. Maps pseudonymous IDs to Stripe objects. Verifies webhooks.
Ledger
Executes raw monetary events using strict pseudonymous customer signatures.
Seamless Drop-In
Integrating structural separation between payments and your app tier requires minimal engineering overhead. You pass a pseudonym to the API. We coordinate settlement with the processor and return entitlement state.
// 1. Pass a pseudonymous tracking string from your server. No emails required. const checkoutSession = await fetch("https://api.privacybilling.com/v1/checkout", { method: "POST", headers: { "x-client-api-key": "pk_live_your_secret_key" }, body: JSON.stringify({ anonUserId: "user_pseudonym_12345", planCode: "pro_monthly" }) }); // 2. Processor holds card data; we map entitlements. You query by pseudonym. const entitlements = await getEntitlements("user_pseudonym_12345"); if (entitlements.includes("pro_monthly")) { unlockApplicationSuperpowers(); }
The Enterprise Benefits
Security Limit
Zero-Value Targets
Attackers cannot steal card data from your app tier if you never store it there. This pattern reduces a common class of breach impact; it is not a substitute for your own security programme or legal duties.
Funnel Scale
Frictionless Conversions
Remove the single highest drop-off point in SaaS funnels: mandatory account creation. Users can pay and instantly subscribe to your application without ever typing their email or creating a password.
Data minimization
Less identity in your app tier
When you avoid holding subscribers' payment credentials in your own databases, you may reduce certain processing and breach-notification scenarios. You still must meet applicable laws (including KYC/AML where required) and obtain your own legal advice.
“Won't I lose my analytics or fail KYC?”
No. PrivacyBilling orchestrates entirely on top of world-class infrastructure like Stripe. This ensures that all mandatory global KYC and AML compliance checks are executed automatically within the secure banking tier.
You retain visibility over standard subscription analytics (such as MRR, cohorts, and churn) via your payment provider where available, without routing full payment pan data through your application databases for entitlement checks.
Three simple steps
A straightforward integration architecture built for developer velocity.
Sign Up
Create a developer account and instantly generate your platform API keys.
Drop In
Paste three lines of code into your integration tier and define your subscription catalog.
Go!
We immediately handle credit card mechanics, compliance, and subscription isolation.
Radically Developer-Friendly
Evaluate the entire infrastructure layer with zero compliance risk.
Unlimited Sandbox Testing
Develop your entire application locally. We provide full access to the API sandbox absolutely free forever.
No New Environments
You do not need to build out complex staging deployments. When your integration is flawless, simply swap your `pk_test` string for a `pk_live` key and collect real revenue.
No Altering Your Flow
Adopt our infrastructure without changing your core backend. Query us directly for zero-state deployments, or use webhooks to seamlessly map events to your existing ledger.
Frequently Asked Questions
What is PrivacyBilling?
A B2B API that sits between your product and your payment processor: we align pseudonymous IDs with subscription state and return entitlements to your servers. Card capture, vaulting, and PCI-scoped processing are delegated to the processor (for example, Stripe), not reimplemented inside PrivacyBilling or your app database.
Do you store our customers' card numbers?
No. We are not the merchant acquirer and do not host primary account numbers for your checkout. Stripe (or another integrated processor) holds cardholder data under its PCI controls; we work with tokens, customer IDs, and webhooks to know whether a subscription is active.
Why is that important for compliance?
Regulators and frameworks (including UK GDPR and ICO expectations around data minimization and security) care about what you collect, where it lives, and breach impact. Keeping payment credentials out of your application datastore reduces PCI scope for your app tier and avoids duplicating sensitive financial identity alongside product telemetry, making DPIAs and breach scenarios easier to reason about. Your legal obligations remain yours; we provide a technical separation pattern.
How does this limit breach impact?
If your app database is scraped or leaked, attackers should not find a full card vault when you never stored one there. PrivacyBilling maps entitlements to a pseudonym so payment identity stays with the processor. What you still log in your own systems determines residual risk.
Who uses PrivacyBilling?
Teams that need billing identity decoupled from application queries: security-sensitive SaaS, health-adjacent products, and sovereign or high-trust deployments where clear separation of duties matters.
What integrations are supported?
Stripe is supported today; Braintree, Adyen, and PayPal-class processors are on the roadmap. The same architectural idea applies: processor holds card data; PrivacyBilling holds subscription bridge state; your app holds product data.
Ready to integrate?
Developer API access is completely free to integrate. Production scale requires an active merchant subscription tier.
Sign Up for Free API Access