How to Assess a Developer's Stripe Billing Experience

To assess a developer's Stripe billing experience, ask what happens after checkout: renewals, failed payments, cancellations, plan changes and duplicate webhook events. Engineers who have run billing in production answer with specific events and failure cases. Engineers who have only added a checkout button describe the happy path.

Plenty of full stack CVs list Stripe. Far fewer candidates have owned a subscription system once real customers started renewing, changing plans and letting their cards expire. This guide gives you 8 questions, what a strong answer includes, and the red flags to watch for. It's written for founders, CTOs and hiring managers. You don't need to be a payments expert to use it, because you're listening for specifics, not checking syntax.

I own end-to-end Stripe billing at Emergi Mentors: plans, Checkout, cancellations, usage metering and webhooks. I also built Starter, Pro and Fleet subscription tiers for Wheelyst and Free and Pro plans for PrepAI. These are the questions I'd expect a serious team to ask me.

Why does "Stripe experience" on a CV need checking?

Stripe is easy to start and hard to finish. You can build a working checkout in an afternoon from the docs or with an AI coding tool. Subscription billing is mostly about what happens later, when nobody is watching: a renewal at 3 AM, an expired card, a cancellation from the customer portal, an upgrade halfway through the month.

Stripe tells your app about these through webhooks. Its documentation says a subscription integration needs a destination that handles webhook events, because most subscription activity happens asynchronously. So "integrated Stripe" can mean anything from a payment link to owning the whole subscription lifecycle. The interview's job is to find out which.

What are the best questions to assess Stripe billing experience?

1. "A customer pays, then closes the tab before the success page loads. Do they get access?"

A strong answer: yes, because access is granted by a verified webhook such as checkout.session.completed or invoice.paid, not by the redirect. The success page only shows the result.

Red flag: the paid plan is unlocked when the success page loads. This is the most common billing bug in quickly built SaaS products. It leaves paying customers stuck on the free plan.

2. "What happens if Stripe sends the same webhook event twice?"

A strong answer: Stripe can deliver the same event more than once, so the handler must be safe to run twice. Common approaches are storing processed event IDs or writing updates that give the same result when repeated. Experienced candidates also mention that Stripe doesn't guarantee events arrive in order, so they fetch the current subscription from the API instead of trusting the order of arrival.

Red flag: "Stripe only sends each event once."

3. "How do you know a webhook really came from Stripe?"

A strong answer: verify the Stripe-Signature header with the endpoint's signing secret, using Stripe's official library. Good candidates know verification needs the raw request body. Many frameworks parse JSON first, and that breaks verification. They also keep separate secrets for test and live mode.

Red flag: no verification at all, or "nobody knows the URL".

4. "A renewal payment fails. Walk me through what the customer and the app experience."

A strong answer covers the whole path:

• Stripe sends invoice.payment_failed.

• The subscription moves to past_due.

• Stripe retries based on Smart Retries or your retry rules.

• The customer is asked to update their card.

• After the final retry, the subscription becomes canceled or unpaid, depending on your settings.

The app changes access based on that status. The best candidates also point out that the grace period during past_due is a product decision, not just a technical one.

Red flag: "Stripe handles that," with nothing changing on the app's side.

5. "A customer upgrades from monthly Starter to annual Pro mid-cycle. What do you need to decide?"

A strong answer lists the decisions:

• How proration works.

• Whether the change happens now or at the end of the period.

• Whether to bill now or on the next invoice.

• How downgrades differ (they often take effect at period end).

The candidate then explains how the database picks up the new plan, usually from customer.subscription.updated.

Red flag: "I'd just update the subscription with the new price."

6. "Where do you check whether a user can use a paid feature?"

A strong answer: on the server. Check the subscription state your database keeps in sync through webhooks, or Stripe's entitlements, on every protected API route. Hiding a button in the interface is only cosmetic.

Red flag: the check only happens in the frontend.

7. "Your webhook endpoint was down for an hour. What happens, and what do you do?"

A strong answer: in live mode, Stripe retries failed deliveries for up to three days, waiting longer between each attempt, so most events catch up once the endpoint is back. You can also list the events that failed to deliver and process them yourself. Good candidates add that the endpoint should return a 2xx response quickly and push heavy work to a queue, and that someone should get an alert when deliveries fail.

Red flag: they don't know retries exist, or their handler does slow work before it responds.

8. "How did you test billing before going live?"

A strong answer: Stripe's test mode, the Stripe CLI to forward and trigger events locally, test clocks to simulate renewals and trial endings, and test cards for declines and 3D Secure.

Red flag: "I tested a successful payment and it worked."

What does a strong answer sound like overall?

Across all 8 questions, look for the same patterns:

• They talk in subscription states (trialing, active, past_due, canceled), not pages.

• They name specific events instead of saying "Stripe notifies us".

• They can describe a real billing bug they found or fixed.

• They treat choices like the grace period and downgrade timing as product decisions to agree with the team.

• They're honest about gaps. "I haven't used Stripe Connect, but here's how I'd approach it" is worth more than a confident bluff.

Should you give a Stripe take-home task?

Keep it short and realistic. A 60 to 90 minute code review beats a multi-day unpaid project. Give the candidate a small webhook handler with planted problems: no signature check, access granted on the success page, and nothing to stop a duplicate event being processed twice. Ask them to review it the way they would a teammate's pull request.

A code review is close to the real job, it shows how they communicate, and it respects their time. Another option is to ask them to sketch the data model. Which Stripe IDs and subscription fields would they store, and why? If the task needs more than a couple of hours, consider paying for it.

How can you verify Stripe experience on a CV or portfolio?

Read for scope, not keywords. "Integrated Stripe" tells you little. "Owned subscription billing: plans, Checkout, cancellations, metering and webhooks" tells you what the person was responsible for. Look for live products with paid plans you can see, then ask two follow-ups: "What was the hardest billing bug you fixed?" and "What would you change about that system now?"

You can see how I describe my own billing work, and the products behind it, here: https://osamahabib.com/services/subscription-platform

If you're checking an existing codebase rather than hiring, start with my pre-launch checklist: https://osamahabib.com/blog/vibe-coded-saas-stripe-billing-checks. If you're hiring without a technical background, this guide covers the general signals: https://osamahabib.com/blog/how-to-hire-a-nextjs-developer

Frequently asked questions

How do I know if a developer has real Stripe subscription experience?

Ask what happens after checkout: renewals, failed payments, cancellations, plan changes and duplicate webhooks. Production experience shows up as specific events, subscription states and bugs they have fixed, not a description of the checkout button.

What is the most revealing Stripe interview question?

"What happens if Stripe sends the same webhook twice?" It tests whether the candidate knows webhooks can repeat and arrive out of order, and whether their handler is safe to run more than once.

Does a full stack engineer need a Stripe certification?

No. Stripe offers certifications, but hands-on production experience with subscriptions, webhooks and failure cases is a stronger signal. Ask about real systems the candidate has run.

How long should a Stripe take-home task be?

Short. A 60 to 90 minute code review or design exercise based on a realistic webhook handler shows more than a multi-day project and respects the candidate's time.

Can a non-technical founder use these questions?

Yes. You don't need to judge code. Listen for whether the candidate talks about renewals, failed payments and duplicate events with specific examples, or only describes a successful checkout.

Hiring an engineer to own your billing?

I'm open to full-time remote Full Stack Engineer roles. I own Stripe subscription billing in production, and I build Next.js, FastAPI and Node.js products end to end. If your team needs someone to own billing and the product around it, download my CV at https://osamahabib.com/docs/Osama_Habib_CV.pdf or get in touch at https://osamahabib.com/contact.