You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was working on implementing this today and ran into one issue.
If a customer wants to delete their billing information, the only way to do it with Stripe is to delete the customer from Stripe.
So the user will no longer has a stripe customer #.
Thus it always sets the user back to the free plan when it syncs since the customer is no longer in Stripe.
But if a customer deletes their billing information (thus deleting stripe customer), and the customer still has time left on the current billing cycle....syncing will make the customer forfeit the remaining time they paid for.
Syncing would be fine as long as the next time the customer subscribes to pro (thus creating a new stripe customer) the system should determine if they have time left on the current billing cycle. If so the system should set a trial_start_date at the date the current billing cycle end.
The hack below avoids syncing with Stripe until the current billing cycle end date has arrived. But there is a problem with it.
This issue arises when the customer tries to resubscribe to the plan and they also have time left on the current billing cycle ... since they are no longer a stripe customer (since they deleted their billing info) ... it charges them immediately instead of charging them on the next billing cycle.
So what needs to happen is when they subscribe again, and if they are no longer a stripe customer, the package should set the first billing date to be when AppPlans.endDate is
The text was updated successfully, but these errors were encountered:
@sferoze OK, so you have to delete the customer, which also cancels all subscriptions, and by default no proration refund is given.
One solution would be to issue a refund for the rest of the month as soon as you delete the customer. Then going back to the paid plan would start over with a different billing period, but they wouldn't be overcharged.
Otherwise, yeah I think it would make sense to use the endDate as the first billing date if we are creating a new customer.
I was working on implementing this today and ran into one issue.
If a customer wants to delete their billing information, the only way to do it with Stripe is to delete the customer from Stripe.
So the user will no longer has a stripe customer #.
Thus it always sets the user back to the free plan when it syncs since the customer is no longer in Stripe.
But if a customer deletes their billing information (thus deleting stripe customer), and the customer still has time left on the current billing cycle....syncing will make the customer forfeit the remaining time they paid for.
Syncing would be fine as long as the next time the customer subscribes to pro (thus creating a new stripe customer) the system should determine if they have time left on the current billing cycle. If so the system should set a trial_start_date at the date the current billing cycle end.
The hack below avoids syncing with Stripe until the current billing cycle end date has arrived. But there is a problem with it.
This issue arises when the customer tries to resubscribe to the plan and they also have time left on the current billing cycle ... since they are no longer a stripe customer (since they deleted their billing info) ... it charges them immediately instead of charging them on the next billing cycle.
So what needs to happen is when they subscribe again, and if they are no longer a stripe customer, the package should set the first billing date to be when
AppPlans.endDate
isThe text was updated successfully, but these errors were encountered: