Stripe integration unanswered questions

There's already some other great advice here that I agree with, so I'll only mention things that I haven't seen mentioned elsewhere.

For context, our system allows companies to create job openings which then get programmatically distributed to a bunch of job boards. The basic process is free for our users, but we offer optional "boosts" for jobs that our users post; they can optionally select multiple options from several different tiers to get a job put in front of more potential candidates, and any given company might have several jobs with different boosts applied at a single time. We create subscriptions for each boost that a company opts into, and our system listens for an invoice.payment_succeeded webhook event that triggers the appropriate data to be inserted into our database to promote the appropriate job.

Q1. Since we want our customers to be able to share billing information with other users on their team, we decided that a Stripe customer should have a 1:1 relationship with the Team entity in our system. When a team is created for the first time, it by default won't have a Stripe customer associated with it. When a user on that team posts a job for the first time and decides to boost it, they'll be required to add a payment method before continuing, and at that point in time we create the Stripe customer and associate it with the team in our db.

However, doing it this way introduced a bottleneck. The sales/support members of our team sometimes want to be able to give special discounts or free boosts to our users -- including those on the free tier -- by using the Stripe dashboard (e.g. manually adding a boost subscription to a job with a 100% off coupon, which then triggers the webhook event sent to our API, which then boosts the given job). Since right now we don't create a Stripe customer for a team until they've added a payment method or have otherwise done something with the billing portion of our app, the capacity for our team members to support a team in the system without a Stripe customer is somewhat limited.

Our integration design process is heavily oriented around around allowing non-engineering users to do anything they want in the Stripe dashboard while having the effects of their actions appropriately reflected in the way that our app behaves, so it's likely that we'll soon switch over to associating Stripe customers with teams right away on creation instead. The Stripe dashboard is pretty great, so I'd keep its utility in mind when doing your integration -- this is probably less of a problem if you don't have to facilitate non-technical personnel interacting with your customers.

Q2. The answer someone else gave about proration is great. Another option if you don't want to prorate them is to set cancel_at_period_end to true for the customer's existing subscription, and then create a new subscription that is set to begin on the same date that the prior one expires.

Q3. Yes, since our base product is free, users can continue to use it independent of whether or not their payment succeeded. However, their jobs won't get put into the paid boost feeds until the invoice has been fully paid. We also have an endpoint that listens for invoice.payment_failureevents` which notifies the user when something goes wrong so they can update their payment info/retry the payment.

Best of luck with your integration!

1. Upon registration I immediately sign the user up to the trial, and as such I create the customer within stripe upon account creation. They can choose later whether they want to pay or not.

2 and 3: Depends. When more information is required I just simply give the users access. If users have indicated to be interested by trying to buy a subscription I want to do whatever possible to leverage on that interest. If payment fails while entering credit card information I do not give access. If users indicate they want to make a bank transfer I immediately grant access, trusting the payment will come later. When a subscription is changed I keep with the existing billing cycle to settle the difference.

Hey Andreas,
A1 - You create the customer in the same process that creates the subscription. You'll first check to see if the customer record in your database has stripe_customer_id. If it does, you'll use that to create the subscription, if not, you'll create the customer, user that to create the sub, then save the customer ID for later use.

A2. - If they are upgrading to a plan, yes you would collect the difference based on pro-ration, which Stripe can calculate for you using the Upcoming Invoice endpoint.

A3 - When your user creates a subscription, services should be automatically provisioned. When a user starts a subscription, they are charged immediately, unless you are using trials, in which case the user is charged at the end of the trialing date.

I cover all of this extensively in my upcoming eBook - https://www.indiehackers.com/product/playbook-thirty-nine/

For use creation, there are 3 options. The first is to create the user in stripe immediately and store the stripe customer id in your database. In this case, billing will start as soon as your trial period is over (if you specify a trial period). In the second case, grant user access to your app (do your own registration only) and only do the stripe customer creation when it's time to pay (e.g. upgrade path, or taking an action that needs a paid subscription). The third option is to do the stripe customer creation, but not charge the customer until a billing event happens (they exceed the free tier).

If subscription changes, you can offer a free trial period again or start the billing immediately. It really depends on your setting in stripe. We have a free trial period defined.

Stripe will bill the client and send a notification if it fails or succeeds. So we use that. Generally a grace period (retry period) is allowed. Also, generally you notify the customer that their usage has changed so they are going to be billed. So a grace period is included anyway.

Also, make sure you think about the tax aspects on your subscriptions. That can be complicated because you have to file the taxes as well!