Plan change only half completed?
I just changed a customer from a free plan to a paid plan using the "/customers/edit/" API call. Now both the API and the admin interface shows the customer is on the new plan.
BUT two issues now.
First, the fields in the admin still show:
-
TIME AS A CUSTOMER : 7 days
-
TIME ON THE CURRENT PLAN : 7 days
-
CHANGED PRICING PLANS : 0 times
Second, there is now an invoice scheduled to go out in 30 days for the new plan, but none shows for what should have been an immediate charge since the plan is set as "bill immediately on signup".
This is very confusing. What's the actual status of this customer, why didn't they get billed immediately, and why is the admin interface reporting conflicting data?
Thank you for any light you can shine on this.
P.S. The customer in question is this:
https://cheddargetter.com/admin/customers/get/id/b1c6f9ec-892b-102d...
Discussions are closed to public comments.
If you need help with Cheddar please
start a new discussion.
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
Support Staff 1 Posted by Marc Guyer on 02 Apr, 2010 02:56 PM
Great question. This is intended behavior and can be a little confusing. Changing from a free plan to a paid plan is not considered to be a plan change. CG behaves the same when a customer signs up for a paid plan to begin with as it does when a customer moves to a paid plan from a free one. I've attached a screenshot of the pricing plan interface where this is explained. I think that the best way to think of it is that a customer is new when they begin to pay.
I may be misunderstanding your second point. The customer was billed immediately for invoice 13 upon changing to Plan 1 this morning.
Support Staff 2 Posted by Marc Guyer on 02 Apr, 2010 03:08 PM
Ah, I see the problem with invoice 13 now. The change to Plan 1 occurred this morning at 2010-04-02T06:50:52+00:00. Invoice 13 should have been transacted at that time. Our recurring transaction engine caught it this morning at 2010-04-02T13:02:50+00:00. That looks like a bug so we'll look into that today and get back to you.
Support Staff 3 Posted by Marc Guyer on 02 Apr, 2010 03:09 PM
Oops, that was the wrong screenshot. Here is the correct one.
4 Posted by Dan Kamins on 02 Apr, 2010 06:46 PM
Thanks Marc. Let's assume the first invoice should have been issued immediately and such bug will be fixed.
I still think the rest of your answer might actually have left me more confused than before!
Isn't changing plans the very definition of a plan change? I don't get this distinction. Plus this still results in a new subscription entry being created & returned (first) in the XML, doesn't it?
Behaves the same way how? Just for the pro-rating logic related to the screenshot/options? In other ways?
Not sure what this means. Why are they "new"? They now have 2 entries in their "Subscription History" (free + paid), but still show 0 changed plans and the admin interface implies they've been on their current paid plan since the beginning, which is likely to confuse any admin looking at their customer record.
This is very strange and appears to me to be a bug in your admin interface, for I don't think these values or notions exist in the XML API. Perhaps I'm still not understanding something?
Support Staff 5 Posted by Marc Guyer on 02 Apr, 2010 07:51 PM
Ah, upon a reread, I realize that I did not explain this well (Fridays...). I suppose most of the confusion is with the "Time on the current plan" number. That does appear to be a bug in the GUI that has been fixed in our current dev code. That should be pushed this weekend or early next week.
The "Changed pricing plans" number has also been long since fixed in our dev code. Again, that'll be out with this next upgrade.
So, I guess that leaves the question about switching from a free plan to a paid plan. CG follows the rules in the left column of the "First Bill on this Plan" section of the pricing plan config (screenshot above) when a customer first signs up for the plan from scratch or if the customer switches to this plan from a free plan. That is what I meant when I said "CG behaves the same when a customer signs up for a paid plan to begin with as it does when a customer moves to a paid plan from a free one." In other words, prorating is unnecessary if the customer hasn't been paying you anything yet. When the customer switches from a free plan to a paid plan, they are immediately billed for the first month on the paid plan.
Does that clear things up a bit?
6 Posted by Dan Kamins on 02 Apr, 2010 07:55 PM
Perfect. Thank you very much.
Marc Guyer closed this discussion on 02 Apr, 2010 08:47 PM.
Support Staff 7 Posted by Marc Guyer on 02 Apr, 2010 09:02 PM
Forgot to let you know earlier: We cannot replicate the invoice 13 issue in development so that should be fixed with the next release as well. Thanks for the report!
Dan Kamins re-opened this discussion on 02 Apr, 2010 09:14 PM
8 Posted by Dan Kamins on 02 Apr, 2010 09:14 PM
I don't know if this is relevant, but I had changed that plan to bill immediately (rather than after a month I think) shortly before the user upgraded plans. So it might be possible some old version of it was cached in the part of your system that issues the invoices?
Support Staff 9 Posted by Marc Guyer on 02 Apr, 2010 09:31 PM
No, not possible (no caching in this case). We are able to replicate on the current production system.
If I recall, I think the bug was a >= vs. > with the billingDatetime of the new invoice on plan change. It happened when the (1) plan change occurred and (2) the invoice was created and (3) the transaction system checked to see if it was time to run the next invoice -- all within the same second. That didn't replicate often in dev (slow laptops) but did more often on our production servers (fast).
"It's always some mundane detail..."
Marc Guyer closed this discussion on 02 Apr, 2010 09:31 PM.