Occurly and Recurly
Teams comparing Occurly with Recurly want strong recurring billing and revenue recovery, plus first-class usage billing and analytics in the same platform.
written for people who already use it
Side by side
Two approaches, stated plainly.
Not a scorecard. Both columns describe how each platform chooses to solve the job, including where Recurly goes further than Occurly does today.
| The job | Recurly | Occurly |
|---|---|---|
| Revenue recovery | A core strength, with sophisticated retry and churn prediction built over years at consumer scale. | Smart retries, sequences and grace periods, with involuntary churn separated from real churn in analytics. |
| Usage-based pricing | Available, with the model centred on recurring subscription billing. | High-throughput metering, commitments and prepaid credits as a primary pricing model. |
| Product access control | Typically enforced in your own application from subscription state. | Entitlements are part of the platform, checked through one API so plans decide what customers can do. |
| Global structure | Multi-currency billing, with multi-entity usually handled per account. | Multi-entity and multi-currency on one platform, rolled up to a reporting currency. |
Why teams look at Occurly
Usually when pricing gets hybrid, or a second entity appears.
The evaluations that end in a move tend to start with the same four requirements.
- Subscriptions and usage priced from one catalog, not two systems
- Entitlements and feature gating available through the same API
- Multi-entity billing with consolidated reporting
- Clean REST API, signed webhooks and a sandbox that mirrors production
Migration
Moving without skipping a cycle.
Recurly accounts carry a long payment-method history, so the tokenization path matters more than the data export here. Because Occurly routes to your existing gateway, those tokens stay where they are and customers are never asked to re-enter a card.
- Week one
We map what you have.
Your catalog, entities, currencies and contract structures, against how they would be modelled in Occurly. You get the map whether or not you go ahead, including anything that has no clean equivalent.
- Weeks two and three
Everything imports into a sandbox.
Plans, customers, subscriptions and invoice history load into an environment that mirrors production. We run parallel cycles against it and reconcile them line by line with your current system.
- Cutover
One cycle boundary, and you are on.
The switch happens on a cycle boundary, not mid-period. Payment methods stay with your existing processor, so no customer is asked to re-enter a card and no invoice is missed.
What comes across
Nothing is left behind on purpose.
The parts of a migration that go wrong are almost always the unglamorous ones: open receivables, part payments and the invoice history reporting depends on. Those are the parts we reconcile first.
- Plans, add-ons and price points import as a catalog
- Customers, subscriptions and their full history come across
- Historical invoices import, so reporting stays continuous
- Open receivables and part payments are reconciled before cutover
- Payment methods stay with your processor, untouched
- Parallel cycles run until the numbers agree
FAQ
Moving from Recurly
Will our dunning performance drop during the move?
Retry schedules and reminder sequences are configured and tested in the sandbox against your own historical failure patterns before cutover, so recovery behaviour is set up before the first live cycle rather than after it.
Do customers have to re-enter payment details?
No. Occurly routes to the processor already holding the tokens, so stored payment methods keep working through the cutover.
Bring us your current setup.
We will map it against Occurly and tell you what a move would take, in writing, including the parts that would not be an improvement.
Other comparisons