Move from Stripe Billing to yRecurring.
Leaving Stripe Billing does not mean leaving Stripe. yRecurring runs on your existing Stripe account, so the cards, the customers and the payouts stay exactly where they are; only the subscriptions move.
See how Stripe Billing and yRecurring compare →What is different about leaving Stripe Billing
The cards are fetched, not exported
Stripe is one of the gateways yRecurring reads directly. Connect the account, choose Fetch from gateway on the saved payment methods import, and cards and bank mandates come across matched to customers by email, with each customer's default card still marked as the default.
API amounts are in the smallest unit
If you pull prices or invoices through the API, unit_amount is in cents (or whole yen for zero-decimal currencies such as JPY). The import takes major units, 50.00 rather than 5000, so convert those columns before you upload.
Schedules and pending updates stay in Stripe
A subscription schedule that moves a customer to a new price at a later phase runs on Stripe's side. The export carries today's price; recreate any planned change on the yRecurring subscription after the import.
1. Export from Stripe Billing
The Export button on the Customers, Subscriptions and Invoices pages of the Dashboard (all columns, date range set to all); prices and charges through the API.
- Customers
- Subscriptions
- Invoices
- Prices and charges through the API
As documented by Stripe Billing on 24 September 2026: their export guide.
2. Saved cards
Nothing to move. Connect the same Stripe account to yRecurring and import the saved payment methods as Stripe token references; the customer keeps paying with the card already on file. If you also want to leave Stripe as the processor, that is a separate, later job: Stripe transfers card data to another PCI compliant processor on request.
Source: Stripe Billing documentation, read 24 September 2026. How yRecurring imports them: migrating saved payment methods.
3. What carries over
| In Stripe Billing | In yRecurring | Notes |
|---|---|---|
| Customer (cus_): email, address, tax ids | Customer Keep the cus_ id as the external id and as the gateway customer id. The card fetch matches on email, so fix duplicate emails first. | Keep the cus_ id as the external id and as the gateway customer id. The card fetch matches on email, so fix duplicate emails first. |
| Product (prod_) | Product Plans, add-ons and one-off products share one catalog. | Plans, add-ons and one-off products share one catalog. |
| Price (price_): unit_amount, currency, recurring interval | Price Flat and per unit prices import from the file. Tiered prices, and prices using transform_quantity (package pricing), are rebuilt in the price builder. | Flat and per unit prices import from the file. Tiered prices, and prices using transform_quantity (package pricing), are rebuilt in the price builder. |
| Subscription (sub_): status, quantity, current period start and end | Subscription The first subscription item becomes the plan price; a trialing subscription keeps its trial end as the period end. | The first subscription item becomes the plan price; a trialing subscription keeps its trial end as the period end. |
| Further subscription items (si_) | Add-ons on the subscription Attached in the app after the import. | Attached in the app after the import. |
| Invoice (in_) | Invoice Historical, one summary line with the total. | Historical, one summary line with the total. |
| Charge or PaymentIntent (ch_, pi_) | Payment Recorded against its invoice, with the Stripe id as the reference. | Recorded against its invoice, with the Stripe id as the reference. |
| Credit note (cn_) | Credit note Historical, against its imported invoice. | Historical, against its imported invoice. |
| PaymentMethod (pm_) | Saved payment method Fetched straight from your Stripe account; no file needed. | Fetched straight from your Stripe account; no file needed. |
Records go in dependency order: customers and catalog, then subscriptions, then invoices and the payments that settle them. Each row keeps your old system's id, so running a file again skips what is already there instead of copying it; customers, products and prices can be set to update instead. What you can import.
What stays in Stripe Billing, and what to do instead
Recreate each coupon in yRecurring and issue its codes, in a batch if you had many, then apply them to the subscriptions that carried a discount.
Create a meter for each Stripe meter (sum, count, max or last), report usage to yRecurring from its first billing period, and let Stripe bill the period that is closing.
Tax calculations stay in Stripe. Set up your rates in yRecurring, or connect Avalara AvaTax from Grow, before the parallel cycle.
Point the links on your site and in your app at yRecurring's customer portal and hosted pages before the cutover.
4. The cutover, in five steps
- 01Export
Export customers, subscriptions and invoices from the Dashboard with every column, then fetch the saved cards from the connected account.
- 02Connect
Start the free trial and connect the same payment account you charge through today.
- 03Dry run
Upload the files. The import maps the columns, cleans the values, and shows every row it would create before it writes one.
- 04Parallel cycle
Run one billing cycle in test mode beside Stripe Billing and compare the invoices line by line.
- 05Switch
At a renewal, turn charging on here and cancel the Stripe subscriptions without a final invoice or proration.
Questions about leaving Stripe Billing
See how Stripe Billing and yRecurring compare → What you pay today, next to a flat plan: the fee calculator →
Do I need to cancel the Stripe subscriptions?
Yes, at the cutover: import them into yRecurring with their renewal dates first, run a cycle in test mode, then cancel them in Stripe on the day you switch charging on, so the same renewal is never billed by both.
Do payouts or webhooks change?
Payouts do not: payments still land in your Stripe balance and pay out on your schedule. Subscription events your app listens to, such as customer.subscription.updated, stop once the Stripe subscriptions are canceled, so move those listeners to yRecurring's signed webhooks before the switch.
Why is this move quicker than the others?
The payment side is already connected. There is no card transfer to wait for and no update links to send: the cards are fetched from the account you already use, and the rest is three exports and a dry run.
Will my customers get emails during the import?
No. Imported invoices, payments and subscriptions are historical records; the importer never sends a customer email for them. The first message a customer gets from yRecurring is the first invoice or receipt you choose to send.