Manager for customer billing and subscriptions in Rails
I think the real test of this architecture is the refactoring effort involved in moving away from Recurly. Ideally, you'd just need to rewrite your service layer classes, and none of the rest of your application.

The only major issue I see here is you've got a bunch of public methods that are returning Recurly business objects, which could allow you to couple your entire system to Recurly. Without seeing the rest of the code, I would mark all methods that return Recurly business objects as private or protected, and only expose the methods that are transactional in nature --- and even then I would limit the arguments and return values of those methods to primitive values, or business objects written by your team for this application.

There is one minor nitpick, though. The class name Tollbooth::Manager doesn't really communicate what it does. You describe this as a "service class", so why not name it accordingly: Tollbooth::SubscriptionService or Tollbooth::SubscriptionManager. Normally I would steer people away from naming classes "SomethingManager", but this class does indeed appear to manage things, so I think the "Manager" suffix works here.

If the rest of your application needs data provided by Recurly, I would recommend creating your own classes to represent that data, and then map them over from the Recurly objects (also known as Data Transfer Objects). This would provide a layer of decoupling in case you switch subscription providers in the future.