If you cancel a subscription to a free plan. Then try to update your subscription back to that plan - the canceledDatetime on the customer's subscription does not get cleared. If you do the same thing on a plan that has payment info - the canceledDatetime does get cleared. This seems like a bug :(
As a side note - I was under the impression that you could only
be subscribed to a single plan for a given product - but the system
doesn't seem to cancel other plans when you subscribe to a new
one.
#1 Posted by Marc Guyer Support staff on 02 Dec, 2009 12:01 AM
This certainly does sound like a bug. We'll get right on it.
You are correct. An unique customer can only be subscribed to one plan at a time. What makes you think otherwise? Can you describe the flow and the expected/actual result?
#2 Posted by Dirk on 03 Dec, 2009 02:24 PM
If I use the ruby API - I update that customer's subscription. If I do this three time (update the subscription but do not cancel a subscription) - the subscriptions array - will have three different subscriptions in it. But if you look at the details of the subscriptions - none of them have a cancelDatetime. I assumed that when you moved to a new subscription(plan) for a product it would mark the old one as canceled automatically. We ended up adding a helper method to make sure we cancel before we update - but it seems like the server should do that.
#3 Posted by Marc Guyer Support staff on 03 Dec, 2009 04:29 PM
Ok, so we've fixed that bug. "Reactivating" is an organic thing that occurs when you update a subscription. The buggy logic was only reactivating when the payment information for a subscription was updated. That left "free" subscriptions blowing in the wind. Free subscriptions can now be reactivated by updating any piece of subscription data (just set the planCode).
As for the behavior regarding subscription changes, what you're seeing in the XML is a history of subscription data. The only "current" subscription record is the first one (the latest one). So, in other words, the other subscription nodes are ignored except for the purposes of historical information. When a subscription is updated (new plan, new CC, etc), the previous subscription isn't canceled, we just create a new (now current) subscription record. Does that make sense?
Marc Guyer closed this discussion on 05 Apr, 2010 08:08 PM.