Prior to November 5th, 2018, if a merchant were to install an app with a RecurringApplicationCharge, uninstall it and then reinstall, all within a 30 day window, there may be overlapping billing days for the app. As a result, the merchant could be subject to paying twice for the same app.
We’ve addressed this bug with our most recent update to the Billing API described below:
When the app has trial days...
When the app doesn’t have trial days...
The merchant will resume the original billing cycle and the merchant will not be charged until the end of the 30-day window
If you have any questions or concerns, don't hesitate to comment in the thread below!
Great update! Two quick questions.
Thank you so much for this improvement - it will solve much of the earlier frustrations for customers.
Another question - when the recurring charge is cancelled in mid-term, could it be possible to keep it active until its billing cycle end? Of course, only in case when it has been paid, and if there was no upgrade/downgrade happening. In case of upgrade/downgrade the change should be instant.
That would allow to keep using the app to the fullest - by the end of the paid billing cycle.
Thanks this will solve a lot of questions I get from merchants.
There still is a bit of ambigiuty with the chart though, could you review this these examples and let me know how the billing system will behave?
Assume this is after this change rolls out.
### First example:
1. Store installs on the 1st.
2. Store approves a 14-day trial, ending on 14th so the 15th is the first billable day.
3. Store uninstalls on the 5th (5 days into trial).
4. Store reinstalls on the 20th.
5. Store approves the charge with no-trial (since it's past the 14th)
What would happen in this case?
My opinion is that since the trial is a 14-day trial and not 14 dayS (empasis on days, as in 14 "day chunks") they would:
a. have a new billing cycle created on the 20th
b. would be charged right away (no trial on second charge setup, #5)
c. there would be no proration
Alternatively, what if step 5 changed to:
5b. Store approves the charge with the standard 14-day trial
What would happen with the charges and billing cycle?
### Second example:
(not resetting the item numbers for ease of referencing specfic steps, but consider this a different store who never installed)
6. Store installs on the 1st.
7. Store approves a 14-day trial, ending on 14th so the 15th is the first billable day.
8. Store uninstalls on the 5th (5 days into trial).
9. Store reinstalls on the 10th.
10. Store approves the charge with a 4 day trial (since it's 4 more days until the 14th)
What would happen here?
I'd think they'd still keep their billing cycle which starts on the 15th and there'd be no proration.
- - -
The root of my questions is some questionable behavior I've seen where a merchant will install for 1 day in December (starting the trial), uninstall the next day, and try to reinstall in January in an atempt to restart their trial or continue their trial where they left off. Basically dipping into the trial like a bank balance so they never actually have to pay.
This is extremely problematic when there's large and expensive data imports and syncs that have to happen during the install.
I've countered that by fixing the trial to a date and adjusting any reinstall Charges trial days remaining to use that date (step 5 and step 10 above).
Feel free to use these examples in the official docs if you'd like. Better docs with examples will help all app developers, merchants, and maybe even billing support.
This change does not affect how trials work in the sense that it does not prevent merchants from starting a trial, cancelling, then starting a new fresh trial if there is no logic in your app to prevent such behaviour. It is the app developer's responsibility to guard against this behaviour if they so choose.
Thanks for the questions and feedback folks! Keep it coming!
Great, this sounds exactly like what I was expecting.
So your example of "When the app has trial days..." was for a store that was already actively paying, uninstalled, reinstalled with a new trial, and that all happened within one biling cycle.
The part that caused me to raise the question was that it wasn't clear if the un/reinstall process happened after they were active/paying or if during the trial (the phrase "if a merchant were to install an app with a RecurringApplicationCharge").
Overall, this is a great change and I'm happy for how it sounds. I'm sure merchants will be too because it makes sense.
(You got to love how complex billing logic gets...)
If the charge gets cancelled due to uninstallation, chances are the merchant does not want to use your app any longer.
This a bit contradicts how I understood the initial premise of the new feature.
Did I misunderstand that if the customer uninstalls the activated app (with the chance that they don't want to use our app any longer), and then installs the app after 2 hours (which sometimes happens)... Then the Shopify will have the earlier charge active, and it will stay active until the end of the current active billing cycle.
Is that not so?
Could you clarify if the situation has changed regarding "cancelled" plans?
This is not documented but, as far as we know, this is how recurrent charges behave:
Could you give us more information on this? It is very difficult to test from our side and we have to rely on what merchants and Shopify support state when they contact us for refunds.