How to export your data from Stripe Billing

How to export your data from Stripe Billing before you leave

Before a renewal, a fee change or a move to self-hosted billing in Lago or Kill Bill, you can pull subscriptions, customers and invoices out of Stripe Billing through the Stripe API, but stored card data moves only through Stripe's encrypted export to a PCI DSS Level 1 processor, and Link credentials cannot be exported at all. This page is a guide to the documented paths, so it does not promise what your account can export today. Confirm current export limits, file formats, eligibility and turnaround times with Stripe before you set a cutover date. The sections that follow cover the card data decision, the objects to inventory and the order of steps that avoids double charges.

The first decision is whether card data needs to move at all. Lago states that it needs a separate payment processor, and it names Stripe, Adyen and GoCardless as supported gateways. If Stripe stays as your processor, saved payment methods can remain in Stripe and your billing engine can reference existing Stripe customer IDs, so no card export is needed. Ask Lago or Kill Bill's integration maintainers to confirm that the plugin or connector reuses existing payment methods. If you change processor, the card path is Stripe's encrypted export to a receiving processor that must hold PCI DSS Level 1 status, and you should obtain that processor's compliance evidence before Stripe releases any file. If you instead choose a self-hosted in-house vault, such as the one documented for Hyperswitch, the Hyperswitch docs state that you become fully responsible for PCI DSS certification and data handling. DeployOpen prepares controls and evidence for assessments, but independent auditors issue the attestation. For Link, plan for customers to re-enter their wallet details on the new payment page.

Inventory before you export. List customers, products, prices, active subscriptions, open and paid invoices, credit notes, and any metered usage that has not yet been billed. Pull each object through the Stripe API into your own store, and keep the original Stripe IDs as external references so that reconciliation and support lookups still work after cutover. Run a reconciliation report that compares invoice totals and subscription states between Stripe and the new system for a sample period. Freeze plan changes during the final sync window, and turn off Stripe-side invoice emails only after the new system has produced and delivered its first invoices. Whichever path you take, record who approved each export, where the files are stored, and when they will be deleted, because those records are the evidence your compliance team will ask for.

Which Stripe Billing data you can export through the API

This table lists the Stripe Billing data types a billing team usually needs to move, the documented export method for each, the format returned and what to confirm with Stripe before you start. Card data is the exception: it leaves only through Stripe's encrypted export to a PCI DSS Level 1 processor, so plan that route early. Use the confirmation column to build your export checklist before any cutover date is set.

Data type	Export method	Format returned	What to confirm with Stripe
Customers	API retrieval, paginated list calls	JSON objects per customer record	Pagination behavior, rate limits, and whether deleted customers remain retrievable
Products and prices	API retrieval of products and price objects	JSON objects with IDs, currencies and recurring intervals	How archived prices appear, and how price IDs map to your new plan catalog
Subscriptions	API retrieval, filtered by status where needed	JSON objects with items, status and billing cycle fields	Whether canceled subscriptions and their history stay available, and for how long
Invoices and credit notes	API retrieval of invoice and credit note objects	JSON objects, with hosted or downloadable PDF links where enabled	Retention of historical invoices, tax fields, and access to PDF files after export
Payment method references	Encrypted export to a PCI DSS Level 1 processor only	Encrypted export file delivered to the receiving processor	Eligibility of the receiving processor, file format, timing, and any fees for the export
Usage and meter records	API retrieval of meter and usage summaries	JSON summaries by meter, customer and period	Whether raw event history is kept, how far back it goes, and whether summaries can be re-run

What cannot leave Stripe Billing and the workarounds

Stripe Billing data moves in layers. Subscriptions, invoices and customer records can usually be pulled through the API, but card credentials, wallet accounts and Stripe's internal risk models follow different rules. Each item below needs a decision before the cutover date is set.

Raw card numbers outside the encrypted export

Full card numbers and expiry data leave Stripe only through its encrypted export path, and only to a receiving processor or vault that is PCI DSS Level 1 compliant. Any plan that assumes you can copy card numbers into a CSV or a self-hosted database is out of scope. Confirm with the target processor which export format it accepts, who pays for the export, and whether the file is generated in batches with a processing window.

Link wallet credentials

Stripe Link stores payment credentials tied to the consumer's own Link account, not to your merchant account. Those credentials cannot be exported and will not work at a new processor. The practical workaround is to ask Link users to add their payment method again at checkout after the switch. Confirm with your target processor how it will collect and store new credentials for these customers.

Customer re-entry of saved cards

For customers whose cards cannot be exported, the usual workaround is a re-collection step: an email or in-app prompt that sends them to a hosted payment page to save a new payment method. Plan the timing so subscriptions do not fail on renewal day. Ask the target processor whether it supports account updater services that refresh expired or replaced card numbers, and what that service costs.

Stripe fraud and risk signals

Radar scores, dispute history and other risk signals are generated inside Stripe and are not included in the billing data you export. Keep a record of chargeback counts, refund reasons and flagged customers in your own reporting before the cutover. Confirm with the new processor and its fraud tooling whether it will start from zero, and set review limits for the first months of new volume.

Historical invoices as PDF records

Stripe hosts invoice PDFs and receipts, and those files may not be reproducible in a new billing system with the same numbering. Download the PDFs and store them with the invoice identifiers in your own archive before the account is closed. Check whether your tax, audit or retention rules require the original documents, and confirm the retention period with your finance and legal teams.

The order of steps for a complete Stripe Billing export

This sequence moves subscriptions, invoices and, where the target allows it, card credentials out of Stripe in an order that keeps each record verifiable and leaves a rollback path until the numbers match.

Inventory data, contracts and open obligations
Finance and billing operations list every object that must leave Stripe Billing: customers, products, prices, subscriptions, invoices, credit notes, tax settings, and any payment methods saved for recurring charges. Legal confirms the Stripe terms that govern data export and the contracts with the target processor and billing platform. Done means you have a written inventory with an owner for each object type and a list of what cannot move, such as Link credentials, which must be re-collected from customers.
Confirm the target accepts card export
Before any card data leaves Stripe, confirm in writing with the receiving processor or vault that it is PCI DSS Level 1 compliant and can accept an encrypted batch or single card export from Stripe. Ask which export formats it supports, how it handles failed records, and whether it requires a key exchange or test batch first. Done means the receiving party has signed off on the format and you hold their written confirmation. If the target cannot accept card data, plan to request new payment method details from customers instead.
Freeze plan and price changes
Ask the product and pricing team to stop edits to products, prices, coupons and subscription items in Stripe for the duration of the export. Schedule a cut-off time and record it so every later count is taken against the same snapshot. Done means a change log shows no edits after the cut-off, and the team confirms in writing that the freeze is in effect for every environment that touches live billing.
Run the API export of customers and subscriptions
Using the Stripe API with a restricted key, export customers, products, prices, subscriptions and their items to structured files, paging through every result set and keeping the raw responses. Store the files in an encrypted location under your control, with access logged. Verify the output by comparing object counts per type against the Stripe dashboard at the cut-off time and by spot-checking a sample of subscriptions for status, currency, billing anchor and tax fields.
Run the API export of invoices and balances
Export invoices, credit notes, payment intents tied to invoices, and customer balances with their open and paid amounts. Keep line items and tax lines, since the target system will need them to recreate history and produce accurate receivables. Verify by confirming invoice counts per status, summed totals per currency, and the list of open or uncollectible invoices, then saving those figures as the baseline for reconciliation.
Run the encrypted card export if supported
If the receiving processor confirmed support in step two, request the encrypted batch export through Stripe's export process and run it against the frozen snapshot. Keep the export key and file manifest separate from the data. Verify receipt by checking the manifest record count against the number of saved payment methods you expect, then have the receiving side confirm how many credentials it imported and how many it rejected. Rejected records move to the customer re-collection list.
Reconcile counts, totals and open balances
Load the exported data into the target billing environment in a staging instance, then compare record counts, currency totals, open invoice amounts, customer balances and active subscription counts with the baseline from the earlier steps. Investigate every difference until it has a documented cause. Done means finance and billing operations sign off on a reconciliation report that lists zero unexplained variances.
Keep the rollback window until sign-off
Do not turn off Stripe Billing or change live collection until reconciliation is signed off. Keep Stripe subscriptions active and the export files retained during this period so you can return billing to Stripe if the target shows a fault. Record the date the sign-off was issued and the person who approved it, then disable the Stripe subscriptions that have moved and retire the export keys. Done means the rollback path is closed by a written decision, not by the passage of time.

Why card data moves only through an encrypted export

Card numbers are cardholder data, so they get different treatment from subscriptions, plans and invoices. The documented path moves card data only to a PCI DSS Level 1 processor, through an encrypted export, and only after the receiving party has agreed to accept it. Do not request an export and then look for a destination. Before you start, confirm with the target processor that it will accept the encrypted file, which format and delivery method it expects, and how long it takes to process the import. Treat that written confirmation as a precondition of the migration plan, not as a later step.

Responsibility follows the data. The receiving party carries PCI DSS obligations for the card data it holds, and the exporter still has to protect the data while it is in transit and record what was sent. Self-hosting a card vault changes the picture. The Hyperswitch documentation states that in its self-hosted, in-house PCI model the merchant is fully responsible for PCI DSS certification and data handling. If you run your own vault, that certification work becomes part of your program, with its own scope, controls and assessor. Hyperswitch's in-house PCI model documentation sets out what that means before you commit to it.

Ask the target processor for its current attestation documentation before you rely on it. Request its PCI DSS attestation of compliance, confirm the assessment date and that it covers the exact service that will receive your export, and ask for the responsibility matrix that shows which controls it owns and which fall to you. Check whether any compensating controls or scope exclusions apply. Store these documents with your migration evidence, and set a reminder to request an updated copy at the next assessment cycle. If the processor cannot provide these documents on request, do not start the export.

Where exported records land in Lago, Kill Bill and a payment orchestrator

Lago is the destination that changes the least on the payment side. Stripe remains the payment gateway, and Lago calculates what to charge and when, then sends those charges to Stripe. Exported customer, subscription and invoice records map to Lago's customers, subscriptions and invoice history, while card tokens stay with Stripe and are referenced through the existing customer relationship.

Customers and subscriptions: Stripe customers map to Lago customers, and active subscriptions map to Lago subscriptions, with the Stripe customer identifier kept as the link for payment collection.
Plans and metrics by hand: Stripe products and prices have to be rebuilt as Lago plans, and usage meters as billable metrics, because the exported objects do not carry Lago's pricing logic.
Invoice history: Past invoices can be kept as reference records, but confirm how historical invoices and their numbering are imported without creating a second invoice run.
Gateway configuration: Confirm which Stripe credentials and webhook endpoints the self-hosted deployment needs, and that the Stripe connection matches your payment setup.

Before import, ask Lago to confirm in writing which objects its API accepts, how existing Stripe customer identifiers are handled, and how the first Lago invoice run avoids overlapping with the last Stripe invoice.

What to plan before the Stripe Billing contract ends

Leaving Stripe Billing is mostly a sequence of decisions rather than a single data pull. The cards below cover the contract terms, the data inventory, test runs, parallel operation, records retention and finance sign-off, and each one should be settled before the migration window opens.

Notice period and renewal date

Find the notice period, the renewal date and any auto-renewal clause in your Stripe agreement before anything else. These dates set the latest point at which you can stop billing without being charged for another term. Ask your Stripe account team to confirm them in writing, and note whether a data export request needs to be filed separately from a cancellation notice.

Data inventory and export method

List every data set you need: customers, subscriptions, products and prices, invoices, credit notes, refunds, and payment method references. For each one, decide whether it leaves through the Stripe API or through a Stripe-managed export. Card data cannot be moved by API, so plan for it separately and confirm with the receiving processor what it will accept.

Test export into a non-production target

Run a full export into a sandbox or staging copy of the target system before the real cutover. Compare record counts, currency amounts, tax lines and subscription periods against Stripe. Illustrative example: a mismatch in proration on one subscription type will show up here and not on the production invoice run. Record each difference and its owner.

Parallel running window

Decide how long Stripe and the new billing system will both run, and which one generates invoices during that period. Running both at once risks double charges if two systems try to collect on the same subscription. Agree the switch-over rule, such as which system owns renewals on a given date, and write it down before the first parallel cycle.

Historical invoice retention

Decide where closed invoices, tax records and receipts will be kept, and for how long your tax and audit obligations require. Stripe-hosted invoice links may stop working after the account closes, so store PDFs and line-level exports in your own archive. Confirm the retention period with your tax advisor and your auditor, not with the software vendor.

Reconciliation sign-off in finance

Name the people in finance who approve the reconciliation between Stripe balances, the new ledger and bank settlements. Set the approval steps for each parallel cycle and for final cutover. Without a named approver, differences tend to sit open after the old account closes, so agree who signs off on each exception and how it is recorded.

Questions teams ask before exporting from Stripe Billing

How much effort does a full export from Stripe Billing take?

The effort depends on how many records you move and how much of your billing logic has to be rebuilt on the target side, not on the export call itself. Customers, subscriptions, invoices, plans, prices, meters and credit balances each need a mapping and a reconciliation step. Teams with a small catalog and a few thousand active subscriptions usually have less to rebuild than teams with many plan variants, proration rules and metered products. Ask any implementation partner to size the work from your actual object counts and your target platform, such as Lago or Kill Bill, and to state the assumptions in writing.

Can our team export Stripe billing data without outside help?

A team with API experience and a clear data model can often pull subscriptions and invoices through the Stripe API themselves, but the risk sits in the details: pagination, rate limits, currency handling, tax lines and the link between Stripe customer IDs and your new system. Internal staff usually own the business rules, while engineers own the scripts and the checks. Many teams keep the export in-house and bring in outside help only for the cutover or for the reconciliation that finance will sign off on. Decide early who signs the final reconciliation, because that person needs to be in the loop from the start.

What do finance and engineering each need to provide?

Engineering needs API credentials with the right read scopes, a staging environment for dry runs, and time to build and test the extract and import logic. Finance needs to confirm which invoices are final, which credits and refunds still apply, how revenue is recognized and which ledger accounts the new system will post to. Both teams should agree on a cutoff date, a freeze procedure for plan changes during the export window, and a list of open disputes. Without that agreement, the export will be technically complete but financially unreconciled.

Can card numbers move out of Stripe to a new billing platform?

Card numbers can only move to a destination that is PCI DSS Level 1 compliant, and Stripe's encrypted export path is designed for that case. Spreedly documents the same model for vaulted payment methods, with single card exports or encrypted batch files processed by a compliant third party, generally within two weeks, and one free export per merchant per receiving service. Lago and Kill Bill do not store raw card data themselves; they connect to a payment gateway. In most setups, the safer plan is to keep cards at the processor and point the new billing system at existing payment method IDs. Confirm the destination's compliance status and the export terms with the provider before you plan around them.

What happens to Link customers and their saved credentials?

Stripe Link credentials are tied to Stripe's own accounts and cannot be exported in a form another platform can use, so plan to ask those customers to re-authenticate or to add a new payment method after the switch. Confirm this with Stripe's current documentation for your account type before you tell customers anything. Map which subscriptions depend on Link-saved methods, because failed renewals after cutover are a common source of involuntary churn. Send notice early and keep Stripe active for a defined overlap period so renewals do not fail during the transition.

How do we verify the export is complete and correct?

Verify by counts, totals and sampling, and sign off against a fixed snapshot. Compare the number of customers, active subscriptions, open and paid invoices, and metered events between Stripe and the target, then compare currency totals, tax amounts and credit balances per period. Sample a set of accounts across plan types and edge cases such as mid-cycle upgrades, trials and discounts, and reconcile each one by hand. Keep the extract files, the mapping tables and the reconciliation report as evidence for auditors and for your own change records. Run the checks again after the cutover window to catch late webhook events.

When does a fixed-scope engagement make sense for this export?

A fixed-scope engagement makes sense when the export has a defined boundary, such as a set of plans, a target platform, an agreed cutoff and named acceptance tests, and when your internal team lacks the time or the payments experience to run it. DeployOpen plans, implements, integrates, documents and supports self-hosted platforms in your own infrastructure, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not issue audit reports or certifications; those come from independent assessors. Ask for a written quote that lists the object counts, integrations, environments and acceptance criteria it is based on.

How DeployOpen scopes and delivers a Stripe Billing exit

DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Stripe Billing exit, we start with a written scope that separates what can be exported through the API from what must stay with Stripe or move through a PCI DSS Level 1 processor's encrypted export.

How we scope

Inventory which Stripe objects, subscriptions, invoices and customers, the written scope will cover before any export starts.
Confirm with your processor and legal team whether card data can move, and under which encrypted export process.
Agree in writing which Link credentials and saved payment methods must be re-collected from customers instead of exported.

How we build

Build export scripts against the Stripe API with pagination, rate limits and retry handling for your data volumes.
Map exported subscriptions and invoices to the target billing platform, such as Lago or Kill Bill, and document each field mapping.
Test cutover in a non-production environment to confirm no customer is charged twice during the switch to the new invoice run.

How we hand over

Deliver the export scripts, mapping documents, reconciliation reports and a runbook for the cutover window.
Document the order of steps, rollback points and the owner for each decision, so your team can repeat or audit the export.
Hand over access, configuration and infrastructure documentation inside your own accounts, with knowledge transfer to your engineers.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Plan post-cutover reconciliation of payments, invoices and refunds for the period when both systems run side by side.
Review the target platform's release notes and pinned versions with your team before each upgrade.

How to export your data from Stripe Billing