Cashier itself only works with Stripe payments. Looking at the Billable contract code, it seems to be heavily based on Stripe. For example, it has a method called getStripeSubscription(). I would say it's not really a contract; it's an implementation using Stripe.
While you could implement this Billable contract, you'd need a whole lot of "dummy" (empty) methods that don't make any sense. This doesn't seem like a good fit.
It might make more sense to define your own Billable interface, with the methods that your application requires for its payment process. You'll have to think about whether this even makes sense though -- are the payment methods similar enough in their fundamental actions?
In case it's helpful, I can share my setup (which is not perfect but does work). Bear in mind that your needs may be different...
I have a BillingInterface with only one method:
<?php namespace BBapp\providers\payment;
use BBapp\providers\payment\SubscriptionPlan as Plan;
use BBapp\models\User;
interface BillingInterface {
public function startSubscription( Plan $plan, User $user, $token );
}
...where $token is the authentication token from Stripe, Paypal, etc.
I have a SubscriptionManagerInterface that defines actions on existing subscriptions:
<?php namespace BBapp\providers\payment;
use BBapp\models\Subscription;
use BBapp\providers\payment\SubscriptionPlan as Plan;
use BBapp\models\User;
interface SubscriptionManagerInterface {
// Stop the subscription payments (can be resumed, will cancel at term end)
public function stop( Subscription $subscription );
// Resume the subscription after it was stopped
public function resume( Subscription $subscription );
}
Each of these has a Stripe implementation. I will also add Paypal when I get time, but for now it's just Stripe.
As for the logic for querying subscriptions -- e.g. "does this user have an active subscription?" -- well, I just shove it all on the User model: $user->hasActiveSubscription(), etc. It works fine. You could of course add more abstraction if you feel the need.