I'm going to integrate an extension with License API and it will have monthly fee (subscription charged per month). As I understand so far I will need to make verify the license call and check createdTime value, and if it is greater than 1 month I will need to show link to web store. And after if user will pay subscription in next call createdTime will be changed to current date (so, createdTime will show last payment date, will not?), am I right? I've searched the answer in documentation but so far could not find any info about it..
According to documentation, the createdTime value contains:
The date that the license was created, returned as a Unix timestamp. You can use to limit functionality of a free trial to a specific period of time.
The createdTime value indicates the moment the user first installed the extension and it never changes, even if the user uninstalls and re-installs the extension, or changes from free trial to paid subscription.
You can check the accessLevel value to see if the user has paid the subscription or not: "FULL" indicates that the subscription is paid and active, "FREE_TRIAL" indicates that the user hasn't paid. In the latter case, you can compare the createdTime value to the current date to check if the user is still within the free-trial period or not.
Related
I'm using Stripe Checkout flow to collect the users' payment details and automatically collect the subscription. I have also implemented webhooks to listen to checkout.session.completed so that I can edit the subscription. What I want is as follows:
Say, the user registers on January 15th. I'm using metered billing, so the user pays $0.00 on the first invoice.
In webhooks, I apply a trial period of 7 days to the subscription like so stripe.subscriptions.update([id], {trial_end: [seven_days_into_future]}). So the billing anchor date on the subscription becomes the 22nd of each month.
However, I would like to set the billing anchor date as the first day of each month. So I would like the user to receive the first invoice for January 22-31 (prorated), and then get invoices for full calendar months onwards.
How do I achieve that?
I cannot set the billing_cycle_anchor to the desired date because it accepts only now and unchanged values...
If you're working with already created subscriptions, then you'll need to add trial periods to shift the billing_cycle_anchor:
https://stripe.com/docs/billing/subscriptions/billing-cycle#using-a-trial-to-change-the-billing-cycle
If you know exactly how you want to structure your trial and billing_cycle_anchor at the time the subscription is being created, then you can future-date the billing_cycle_anchor during creation:
https://stripe.com/docs/billing/subscriptions/billing-cycle#new-subscriptions
TL;DR If this question doesn't make sense, please check the following video explanation: https://www.youtube.com/watch?v=9o2KhiBf1lY
I created a Chrome extension and followed the directions here: https://developer.chrome.com/webstore/one_time_payments
In the drop-down, I changed it to a subscription system with a free trial.
And my Chrome extension successfully uses the License API to check the payment status.
But now I'm wondering:
Where do my users go to pay for the full version?
How long is the free trial configured for?
You might be thinking that I have to use the Payments API, but the documentation says:
If the trial is expired, you can direct the user to the web store listing to purchase the item.
Why does it say to direct the user to web store? If I go there, it just says to install the chrome extension, there's no option to pay for it.
And how can it know when the free trial has expired? I never configured a value for it and there's no "free trial duration" specified in the docs.
Meanwhile, the Payments API makes it clear that it's for in-app purchases with SKUs. If this is the only way to accept payment, what's the purpose of that pricing configuration that I set up above?
Thank you for your help.
You have all the answers in the documentation. Read it carefully.
You decide the length of the trial period. In your extension's code, when you check the user's license, it will reveal when your extension was first installed. Compare that with the current date to determine if the user is still within the trial period or not.
The trial and the paid extension are the same, both installed from Chrome's Web Store. If the purchase button doesn't appear to you may be because you are the developer.
In the documentation you have sample code to request the license and check the trial period.
What will be the best pratice to compute monthly allowance of our service when using a Stripe monthly subscription?
I can see 2 strategies:
Add usage to a monthly usage hash (ie. {month_1: 342, month_2: 20}). Calculate current month based on the Stripe subscription start date. Kind of ignore variance in Stripe subscription actual renewal dates, and require manual intervention to block a customer if renewal doesn't go through.
Have a monthy_allowance (credit counter still avaiable for the current month) variable that is replenish when Stripe fires the successful subscription renewal web hook. It's more tie to the actual subscription status, but I can see being an issue as it seems harder to test and subject to bugs if the web hook doesn't properly receive the event. Can be an issue if some customers got locked out until we manually allow them back in.
I suppose it doesn't really matter in this question, but we are using Ruby on Rails with MongoDB as backend.
If you're talking about having some kind of 'usage credit' that your users will 'use up', and that is replenished when a Subscription charge is made, I think you could likely handle this by just having a bucket (like, a counter) that you draw down when they use something, and you fill up when the Subscription is successfully paid, and where you block them (or provide a way to buy more) when the bucket hits zero.
Does that make sense?
I have a number of users who are currently subscribers to a monthly subscription.
For business reason, I want to be able to
1) Charge the customer when he decides to subscribe to our plan
2) Let the subscription become effective a number of days after the purchase
Currently a charge is immediately attempted when a subscription is added to a customer in stripe.
I want to stick to the stripe subscription because a) I still want to have stripe to manage subscription for me in future dates, and b) I have written a lot of code for the subscription model.
Is it feasible at all to demarcate the charge/invoice and the subscription start date?
You can control the time when the subscription actually starts (i.e. when Stripe will start billing the customer) by using the trial_end parameter in your subscription creation request. Simply set the value of the parameter to the timestamp of the exact time you wish Stripe to start automatically billing the customer.
If I understand your desired payment flow correctly, you'd want to do something like this when a customer signs up:
Collect and tokenize the customer's payment information (using Elements or Checkout).
Using the resulting token, create a customer object and save the resulting customer ID in your database.
Create a one-off charge using the customer object for the first payment.
Create a subscription using the customer object and the trial_end parameter set to the time you want Stripe to start automatically billing the customer.
See https://stripe.com/docs/subscriptions/trials for more information about using trial periods.
This is possible now through Stripe Subscription Schedules. With that, you can create a one phase schedule that starts in the future. By default, this will start the subscription on the date you want, automatically renew, and charge the customer on the start date. Also by default, it will immediately perform a transaction to pay for the subscription.
I found the required iterations to be a bit confusing. Essentially that is a multiplier against how many times the original price's interval repeats before moving on.
If all you want to do is start a subscription price in the future, use the Subscription Schedule API call. Create an items array of 1. Set the price_id of the price, the iterations on that item, and the start_date to the unix timestamp you want to start the subscription.
Stripe has different use cases for subscription schedules. The first one they list is exactly this purpose, starting and charging a subscription on a future date. Look through them if you want to adjust some more, like making the first phase a trial period instead.
I have a web service which publishes and hosts certain information for my users. Each user's editing interface is separate from the information they've published. I'm billing for it using Stripe subscriptions, but I'm having trouble coming up with a workable way of handling unpaid subscriptions. Here's the logic I want to implement:
Upon the first failed billing attempt, my app should lock down the user's editing interface; instead, it should present them with a page with options for resolving their payment problem. However, information they've published will still be published, so a late payment doesn't interrupt things for their visitors.
Upon the last failed billing attempt, 15 days later, my app should remove information they've published as well. At this point, the user's editing interface is replaced with one that allows them to either re-activate their account with a new credit card, or completely delete the account.
If the user chooses to re-activate the account, they should not get a trial period
If the user re-activates, they should also have to pay for the 15 days they previously skipped out on, either by having their first billing period shortened by 15 days or by having a charge equal to 15 days' service added to their first bill.
#1 and #2 are very easy to implement if I watch for the right webhooks—just redirect requests for a delinquent customer, or a customer with a deleted or unpaid subscription, to a "fix this problem" page. #3 is pretty easy too—just create the subscription with trial_end set to now.
It's #4 that's tricky. How do I determine exactly how long the user's last invoice went unpaid before their subscription was canceled? How do I shorten the first billing period of the new subscription? Alternately, how do I pro-rate the customer's last invoice total to represent the portion that I actually provided to them, so I can add that amount to the new invoice? (I know I can create an Invoice Item to charge for the amount before I start the new subscription, so at least that's a possibility.)
Finally, does Stripe's "Mark Subscription Unpaid" option help with any of this? It looks like it keeps creating invoices but doesn't try to charge for them; I don't think that's what I want here.
You can definitely do all of that with Stripe's subscriptions. As you mentioned, the first two questions should be solved with webhooks. You would listen for invoice.payment_failedon your end to detect when a payment fails and immediately block you UI asking your customer to update their card details.
To update their card details you can use Stripe Checkout and just not set the data-amount parameter so that it doesn't display a price to your customer. Here is an example for this:
<form action="/charge" method="POST">
<script
src="https://checkout.stripe.com/checkout.js" class="stripe-button"
data-key="pk_test_XXXX"
data-image="/square-image.png"
data-name="Demo Site"
data-description="Update Card Details"
data-panel-label="Update Card Details"
data-label="Update Card Details">
</script>
</form>
Each time your customer tries to update his card, you would use the Update Customer API and pass the new card token in the card parameter. This will delete the default card on the customer and replace it with the new one. It will also try and pay the latest invoice of each subscription in the "Past Due" state. In your case it means that the latest invoice still in retry mode will be attempted to be paid. This does not count as a retry and can be seen as independent. If it succeeds, you just reenable the UI otherwise you continue asking the customer to update his card details.
When you reach the fourth failed payment you will get a customer.subscription.canceled if that's what you set up in your retry settings in the dashboard. You can detect that it's an automatic cancelation by checking the request key on the event and making sure it's null. In that case you block the UI/account completely for your customer.
For the last 15 days, if I understood your flow correctly, the customer hasn't really been able to use your application since you locked down the UI partially. But if you still want him to pay for that amount, you should store in your database that the customer owes you $X for the 15 days he couldn't use the subscription.
Later on, your customer finally comes back and want to reenable his account. At that point you inform him that the payment flow will restart from today and that you will charge him for the extra 15 days he missed before. To do that, I would use Invoice Items which will allow you to add an extra amount to the first invoice automatically. You would follow those steps:
Create the invoice item for $X for your customer.
Create a new subscription to your plan setting trial_end to "now" in case you have a trial period set by default on your plan.
This will automatically create the first invoice for the plan amount and add the invoice item created before.
Another solution here would be to reopen their latest closed invoice that wasn't paid and use the Pay Invoice API. When this happens you know your customer paid you for a full month now instead of just the 15 days he owed you. In that case you would create a new subscription and set a trial period of 15 days so that he starts paying again after that trial.
I wouldn't use the "Mark as unpaid" option here because you completely lock the customer out of your application. This feature for me is to be used when you let your customer use your application and plan to charge him in a few months for each of the invoices. This would be used for an electricity provider for example who would keep your electricity on for multiple billing cycles and continue to try charging you for each invoice.
The amount your customer really owes you in that case is dependent on the number of retries you allow and the days between each retry. What you can do here is use the created value on the invoice and compare it to the current time when you get the customer.subscription.canceled to determine how much time passed and calculate the proration of how much your customer owes you at that point.