The context

I built a Lovable app in 20 minutes to see what's possible. With no technical instructions. Here's a component from the code. It's the Stripe checkout for that app. The user clicks "Upgrade", a panel opens on the right, the Stripe form is embedded inside, you pay, it's smooth. Demo perfect.

So the code was generated by an AI agent. 50 lines. It works.

It also has 5 problems, including 2 serious ones. And it's exactly the kind of code I see in vibecoded apps.

Let's break it down together.

The code in question

import {
  Sheet,
  SheetContent,
  SheetHeader,
  SheetTitle,
} from '@/components/ui/sheet';
import {
  EmbeddedCheckoutProvider,
  EmbeddedCheckout,
} from '@stripe/react-stripe-js';
import { getStripe, getStripeEnvironment } from '@/lib/stripe';
import { supabase } from '@/integrations/supabase/client';
import { useCallback } from 'react';

export function CheckoutSheet({
  open,
  onOpenChange,
  quantity,
  customerEmail,
  userId,
  companyId,
  onComplete,
}: {
  open: boolean;
  onOpenChange: (o: boolean) => void;
  quantity: number;
  customerEmail?: string;
  userId?: string;
  companyId?: string;
  onComplete?: () => void;
}) {
  const fetchClientSecret = useCallback(async () => {
    const { data, error } = await supabase.functions.invoke('create-checkout', {
      body: {
        priceId: 'pro_monthly_per_seat',
        quantity,
        customerEmail,
        userId,
        companyId,
        environment: getStripeEnvironment(),
        returnUrl: `${window.location.origin}/admin/billing?checkout=success&session_id={CHECKOUT_SESSION_ID}`,
      },
    });
    if (error || !data?.clientSecret)
      throw new Error(error?.message || 'Failed to start checkout');
    onComplete?.();
    return data.clientSecret as string;
  }, [quantity, customerEmail, userId, companyId, onComplete]);

  return (
    <Sheet open={open} onOpenChange={onOpenChange}>
      <SheetContent side="right" className="w-full sm:max-w-xl overflow-y-auto">
        <SheetHeader>
          <SheetTitle>Upgrade to Pro</SheetTitle>
        </SheetHeader>
        <div className="mt-4">
          {open && (
            <EmbeddedCheckoutProvider
              stripe={getStripe()}
              options={{ fetchClientSecret }}
            >
              <EmbeddedCheckout />
            </EmbeddedCheckoutProvider>
          )}
        </div>
      </SheetContent>
    </Sheet>
  );
}

At first glance, it looks clean. Properly typed, hooks used correctly, Stripe embedded inside a shadcn Sheet. A junior dev would merge this without blinking. So would an AI agent.

First red flag though: the Supabase call is made directly inside the component. No dedicated hook, no service, no API client. The UI talks to the backend in a straight line. It seems harmless, but it isn't: with no intermediate layer, there's no natural place to draw the line between "what the client sends" and "what the server must revalidate". Everything is mixed, and there's no architecture.

Now let's look at what's actually happening.

Problem 1: userId and companyId come from the client (serious)

Look at these lines:

body: {
  ...
  userId,
  companyId,
  ...
}

userId and companyId are passed as props to the component, so they come from the client. And the client sends them back to the server in the request body.

Why is that a problem? Because anything that goes through the client can be modified. A user opens the browser DevTools, intercepts the request, changes userId to someone else's, and clicks "Pay". Stripe charges. The server attaches the subscription to the other user.

Concretely: I can subscribe your account to the Pro plan with my card. You didn't ask for it, you didn't pay, but you become "Pro". Worse, I can do the opposite: if the logic relies on companyId, I can attach my payment to someone else's company and benefit from their limits.

What you should do instead: the server NEVER trusts these values. It reads userId itself from the Supabase auth session (server-side), and derives companyId from the database, verifying that the authenticated user actually belongs to that company.

Simple rule: identity is read on the server, never on the client.

Problem 2: hardcoded priceId on the client (serious)

priceId: "pro_monthly_per_seat",

The client tells the server what price it wants to pay. Again, anyone can intercept this request and send a different priceId. For example, the priceId of the free plan or a 1€ trial plan.

If the server trusts that value and creates the Stripe session with it, the user pays 1€ and gets the 99€/month Pro plan.

What you should do instead: the client sends an abstract identifier ("pro_monthly", "team_yearly"). The server has a hardcoded mapping (server-side) between this identifier and the actual Stripe priceId. This way, even if the client tampers with the call, it can't make up an arbitrary priceId.

Better yet: the server also validates that the plan is compatible with the user (for example, no "team" plan for a solo user).

Problem 3: onComplete is called before payment (very serious)

This is the sneakiest bug in the file. Look:

const fetchClientSecret = useCallback(async () => {
  const { data, error } = await supabase.functions.invoke("create-checkout", { /* ... */ });
  if (error || !data?.clientSecret) throw new Error(/* ... */);
  onComplete?.(); // <-- here
  return data.clientSecret as string;
}, [/* ... */]);

fetchClientSecret is the function that starts the Stripe session. Not the one that confirms it's done. It's called when the payment form is shown, not when the user actually entered their card.

So onComplete is called before the user pays anything. If onComplete does something like "mark this user as Pro" or "send the welcome email", you do it for anyone who opens the Sheet, even if they never entered a card.

Attack scenario: I open the payment Sheet, I see the Stripe form, I close it without paying. My account just became Pro for 30 days. For free.

What you should do instead: the only source of truth for "payment succeeded" is a Stripe webhook (checkout.session.completed), received server-side. The frontend can show a "Payment in progress" toast at most. All business logic (changing the plan, sending the email, opening access) fires inside the webhook handler, never before.

Problem 4: success comes from a URL parameter

returnUrl: `${window.location.origin}/admin/billing?checkout=success&session_id={CHECKOUT_SESSION_ID}`,

When the payment is done, Stripe redirects the user to this URL. You might be tempted, on the /admin/billing page, to do:

if (searchParams.get('checkout') === 'success') {
  // mark as Pro / show confetti / etc.
}

Except ?checkout=success is just a string in the URL. Anyone can visit /admin/billing?checkout=success&session_id=whatever directly, without going through Stripe. And trigger the "success" logic.

It's the same problem as before: you trust the client for something that has to be validated on the server.

What you should do instead: on the return page, if you want to confirm the payment, take the session_id and call your server with it. The server then asks Stripe (via API) for the actual status of that session. And answers "yes or no". The client doesn't guess the status, it requests it.

Problem 5: environment sent from the client

environment: getStripeEnvironment(),

The client tells the server "are you in test or live mode?". It's the opposite of what should happen. The server knows its own environment (via an env variable, e.g. NODE_ENV or a dedicated flag). It doesn't need to receive it from the client.

The risk: if the server trusts this parameter, you could potentially flip between test and live env by modifying the request. Depending on how it's implemented server-side, that goes from harmless (test payments rejected) to broken (mixed keys, crossed Stripe accounts).

What you should do instead: remove the field. The server knows where it lives.

Bonus: what doesn't break security, but still needs cleanup

• No visible error handling. If fetchClientSecret throws, EmbeddedCheckout stays blank. The user sees an empty Sheet and has no idea why. You'd want at least an error toast and a fallback state.
• No loading state. Between the click on "Upgrade" and the Stripe form showing up, there's a network call. During that time, the Sheet is open but empty. A spinner would do.
• The title is hardcoded in English ("Upgrade to Pro") in a presumably bilingual app. Hardcoded, not i18n. Detail, but it's the same laziness throughout the file.
• The interfaces are inline in the component signature. Prop types are declared on the fly. For something as central as "what you need to start a checkout", this deserves a dedicated file (a checkout.types.ts for example), so it's reusable, testable, and readable without having to parse a sprawling signature.
• Stripe is hardwired into the component. getStripe, EmbeddedCheckoutProvider, EmbeddedCheckout: everything is referenced directly. If tomorrow you want to switch to Lemon Squeezy, Paddle, or add a SEPA direct flow for enterprise clients, you have to refactor half the file. An abstraction layer (a usePaymentSession hook, or an agnostic <PaymentProvider /> component) would let you swap providers without touching the UI. This can sometimes be overkill, but it's worth weighing depending on the scale of the app you're building.

The rule that sums it up

If you only remember one thing from this article:

Anything that touches money is never validated from the client. Always with a webhook.

The client can be useful to start an action (open a form, show a UI). But the moment you change important state on the server (a plan, a balance, an access right), the decision is made server-side, based on signed events (Stripe webhook) or data the server reads itself (auth session, database).

Anything that comes from a user request body is suspect by default.

This rule doesn't come from a tutorial. You learn it once you've hit the problem. And the AI has never hit the problem. It generates code that works, not code that resists.

To be clear: AI is not the enemy

I'm not saying you should stop generating code with an AI. The component above is fairly well structured. It works technically. The problem isn't the AI, it's shipping it to production without review.

The AI produces a first draft that works. It doesn't produce code that will hold up in production for the next 10 years.

If you're vibe coding your SaaS and you touch payments, auth, or user data, that's exactly the moment to bring in a human who can check everything.

Originally published on vibengineer.io.