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.
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.
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.
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.
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.
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.
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 →Yes. Recurly's sandbox environment includes a test gateway and a set of documented test card numbers that trigger specific outcomes, a successful charge, a decline, a particular failure code, so you can build and verify an integration before any real money or real cards are involved.
recurly.js is Recurly's client-side library for collecting card details in the browser without that data passing through your own server, which is what keeps most PCI compliance scope off your plate. You need either recurly.js (building your own form with its hosted fields) or Recurly's fully hosted payment pages; the API alone doesn't give you a way to safely collect a card number yourself.
A subscription being created, upgraded, downgraded, or canceled, and a payment succeeding or failing, are the main events that trigger a webhook. Recurly calls these push notifications; what you build to receive and act on them is up to you.
Recurly isn't a payment processor on its own. It connects to a gateway, Braintree, PayPal, Stripe, and others are supported, and handles the subscription, invoicing, and dunning logic on top of whichever one actually moves the money.
They're Recurly's own fully hosted checkout screens, an alternative to building a card form yourself with recurly.js. You send a customer to a Recurly-hosted URL instead of embedding the payment form in your own site.