Trying to cancel subscription leads to undefined method Stripe_Object::cancel

[Peter Sinnott]

Hi,

I would like to cancel all a customers existing subscriptions before adding any more.

To do so I'm retrieving all the subs and cancelling them individually.

$stripe_customer->subscriptions->retrieve($sub->id)->cancel();

Unfortunately this is failing with the error  "Call to undefined method Stripe_Object::cancel()".

I am using version 1.8.1 of the Stripe PHP library and our API version is 2014-06-17.

Is this error caused by the age of the library/API version or something else I'm doing wrong?

Is the Stripe library generally forwards compatible?

Thanks,

Peter

[Matthew Arkin]

The Stripe libraries tend to be more backwards compatible that forwards compatible. Its pretty hard to design a library without knowing what future versions of the schema may look like. 

Looking at the Stripe-PHP code for 1.8.1, that was pre-multiple subscriptions per customer though (the fact that subscriptions->retrieve($sub->id) works is in part due to the forward compatibly), but v1.8.1 doesn't define a subscription class and thus doesn't define a cancel method.

Since Stripe follows semver you could theorectically upgrade to the latest v1 version - v1.18.0 though that is about 11 months old (but it supports multiple subscriptions). You could also upgrade to v1.11.0 which is the update that added multiple subscriptions. 

Matt

--
You received this message because you are subscribed to the Google Groups "Stripe API Discussion" group.
To post to this group, send email to api-d...@lists.stripe.com.
Visit this group at http://groups.google.com/a/lists.stripe.com/group/api-discuss/.

To unsubscribe from this group and stop receiving emails from it, send an email to api-discuss...@lists.stripe.com.

[Peter Sinnott]

Thanks Matt. I think I'll upgrade to 1.18.0.

I guess there is something in me that thinks it would be better if the older version couldn't setup multiple subs since it can't cancel them. There is a cancel method on the customer but the end point it uses doesn't exist in the current API so its behaviour with newer API versions is undocumented.

Thanks,

Peter

[Jim Danz]

Hey Peter,

That's totally a fair point. The reason for the kludgey half-support
here pertains to the way stripe-ruby attempts to infer API behavior to
whatever extent possible.

When (any version) of stripe-ruby sees the `subscriptions` field on a
customer, it is able to tell that it's a list object, and is able to
see what the `url` for that list is, so it's able to infer where it
ought to POST to create a new subscription (`POST
/v1/customers/:id/subscriptions`).

However subscription "canceling" is a bit of a special case in our
API, so awareness of subscription canceling had to be added to
stripe-ruby by hand (meaning it had to be added both for the legacy
one-subscription-per-customer case, and for the modern
multiple-subscriptions per customer case).

Just a bit of context! Very much agreed that the halfway point that
we ended up here is undesirable. Thanks for raising (and thanks
markin for answering).

Jim

On Wed, Nov 4, 2015 at 3:21 AM, Peter Sinnott