[Bug fix] Billing API: Double billing charges on reinstall

[Busfox]

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...

• At the end of the reinstall’s trial period, the merchant will be charged a prorated fee credited for the overlapping billing 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! 

[Code_Black_Belt]

Hi Andrew,

Great update! Two quick questions.

• I understand that the change is not live yet, and that it will be next Nov 5th, am I correct?
• In the second example titled 'When the app doesn’t have trial days...', I understand that the merchant is also charged at the beginning of the cycle (the first 5 on the left), is that right?

Regards,
  Jose
 

[Maris]

Wow, amazing!

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.

[edavis10]

Hey Andrew,

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.

Thanks.

Eric Davis

[Busfox]

@Jose

• Yes, the plan is to ship this change on November 5th. We wanted to surface this plan ahead of time in case there are any potentially impacted workflows or workarounds we did not think of. Your feedback is a gift!
• In the second image, you are correct, the merchant would also be charged on the fifth of the first month when the app was installed. We charge ahead of the month the app will be used.

@Maris

• If the charge gets cancelled due to uninstallation, chances are the merchant does not want to use your app any longer. The alternative is to have a button to cancel the subscription within your app, in which case you would handle the logic within your app to continue service until the end of the cycle.

@Eric

• In your first scenario, since they weren’t charged originally it acts as a normal install. If you create the new charge on the 20th with trial days, they would begin a new trial. If you create the new charge without trial days, they would be billed immediately on the 20th. We didn't want to make any assumptions about trial days issued, as the app has control over that upon creation.
• Scenario 2 also acts as a normal install since the merchant was never charged. If you are creating the new charge with a trial, they will begin the full trial, otherwise they will be charged immediately.

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!

[edavis10]

Hey Andrew,

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...)

[Maris]

@Busfox:
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?

Thanks!

[Code_Black_Belt]

Hello Andrew,

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:

• Dormant stores: they are charged normally as if they were active stores
• Frozen / unfrozen stores: they are not charged when they are frozen but their recurrent charge is automatically resumed when the store is unfrozen.
• Closed / re-opened stores: they are not charged when they are frozen but their recurrent charge remains cancelled when the store is re-opened.

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.

Regards,
  Jose