n-The Recurly API Handles the Subscription. Here's What Still Has to Catch the Event.
Recurly's API lets you create and manage plans, subscriptions, and invoices programmatically, recurly.js tokenizes card details in the browser so raw card numbers never touch your server, and webhooks (Recurly calls them push notifications) fire when a subscription changes state or a payment succeeds or fails. Recurly itself doesn't process the card; it sits in front of a gateway like Braintree, PayPal, or Stripe and handles the billing logic on top. We don't configure your Recurly account. We build what happens in the rest of your business the moment one of those events fires.
What the API, recurly.js, and webhooks each actually do
The REST API is where plans, subscriptions, add-ons, and invoices get created and managed from your own code instead of the dashboard. It's the layer most custom work builds against: signing someone up, changing a plan, issuing a credit, all callable instead of clicked.
recurly.js runs in the browser and handles the card form itself, either through Recurly's hosted fields embedded in your own page or through Recurly's fully hosted payment pages if you'd rather not build a form at all. Either way, the goal is the same: raw card data goes straight to Recurly, not through your server, which keeps most of PCI scope off your plate.
Webhooks are how your own systems find out something changed without polling the API. A new subscription, an upgrade or downgrade, a cancellation, a successful or failed payment, each can trigger a webhook, and what you do with that notification is entirely up to whatever receives it.
Where the sandbox stops and real integration work starts
Recurly's sandbox includes a test gateway and documented test card numbers, so you can trigger a successful charge, a decline, or a specific failure code without touching a real processor while you're building. That gets a basic integration working fast.
Getting from a working test flow to something that actually fits your business is a different job. A webhook has to land somewhere, get verified, and trigger the right downstream action reliably, not just log that something happened. A gateway decision (which processor Recurly bills through, and whether that choice changes anything about settlement timing or fees) has to get made and wired up correctly. That gap between "the sandbox works" and "production handles every edge case the same way every time" is where most of this kind of work actually lives.
What We Build on Recurly's API
Webhook handling that does something, not just logs it
We build the receiver that takes a Recurly webhook, a canceled subscription, a failed payment, a plan change, and turns it into an actual action elsewhere: access revoked, a CRM record updated, a task created for whoever handles the account.
A card form that fits your checkout, not a generic template
We build the recurly.js integration or hosted-page flow to match your actual signup or upgrade screen, so the payment step feels like the rest of your product instead of a visibly bolted-on third-party form.
Already calling Recurly's API and still catching changes by hand?
Tell us which Recurly events you're not acting on yet, failed renewals, plan changes, cancellations, and we'll look at what's worth automating first.
Building on Recurly's API and still stitching the rest together manually?
A webhook firing correctly is only useful if something's actually listening and acting on it. Recurly is just this page's example; n-frames builds the same kind of event-driven automation on top of whatever API your business already has running, any tool, any event.
Let's talk