Which Stripe webhook event should you trust?

One successful Checkout payment sends your endpoint several events that all read like "it worked", and Stripe's event list does not rank them. In April 2026 a Hacker News commenter described the result: "there is no guidance on which events and states are authoritative or take precedence." The answer does exist. It is spread across three Stripe docs pages and a mailing list reply from Stripe staff, and it changes with how you take payments.

Pick the event by integration

One event per job. If a second event from the same payment feeds a second job, such as a ledger entry from payment_intent.succeeded, keep that handler away from fulfillment.

What one Checkout payment sends

Checkout is built on Stripe's other APIs. In Stripe's own reply on its api-discuss mailing list, a one-time payment "will create and use a PaymentIntent under the hood", and a recurring one creates a Subscription that creates Invoices and PaymentIntents for you. Each object reports its own success, so one purchase produces one success event per layer:

A developer on Stack Overflow logged 14 events from a single subscription Checkout, five of which announce some kind of success: checkout.session.completed, charge.succeeded, invoice.paid, invoice.payment_succeeded, and payment_intent.succeeded. The same reply from Stripe tells Checkout users which layer to read: "you really would only care about the Events associated with your Checkout Session".

checkout.session.completed vs payment_intent.succeeded

Scope decides most cases. A handler on payment_intent.succeeded runs for every PaymentIntent on the account, so the day you add subscriptions or a second product, your Checkout fulfillment code starts receiving payments it was never written for. Line items and metadata are where handlers lose the cart: Stripe webhook line items covers reading products, quantities, and metadata from either event.

Stripe webhook events arrive out of order

Stripe's webhook docs are direct about it: "Stripe doesn't guarantee the delivery of events in the order that they're generated." The created timestamp does not rescue you, because it is recorded in seconds and the events from one payment usually share it. The same docs say not to use created to determine event order.

Order observed in testing is not a contract either. On one Stack Overflow question a commenter reports that checkout.session.completed fires first and an answer reports that payment_intent.succeeded does, each from watching their own integration. On another, a developer who stores the customer on checkout.session.completed and grants access on invoice.paid asks how to make the first arrive before the second. Nothing does. Each handler has to work alone:

• Treat the event as a signal and fetch the object before acting. The API returns current state, so a late event cannot move your records backward.
• When a handler needs a record another event creates, fetch that record from Stripe instead of waiting. Stripe's docs suggest the same: retrieve the invoice, charge, and subscription from invoice.paid if it reaches you first.
• Never infer state from sequence. "I have not seen payment_intent.succeeded yet" says nothing about whether the payment succeeded.

How two listeners fulfill one order twice

Listening to both events "to be safe" is the usual route to a duplicate shipment. Stripe documents two ways to catch duplicates: log the event IDs you have processed, and, for the cases where Stripe generates two Event objects for one change, compare the ID of the object in data.object together with event.type. Neither catches this one. checkout.session.completed and payment_intent.succeeded have different event IDs, different types, and different objects, a cs_ ID and a pi_ ID. Every check passes and the fulfillment code runs twice, often concurrently, since Stripe sends both as the payment completes.

The success page is the third caller. Stripe recommends triggering fulfillment from your landing page as well as the webhook, and says the function "might be called multiple times, possibly concurrently, for the same Checkout Session." So the key that makes fulfillment happen once has to be yours, and it has to be the same key from every entry point. For Checkout that is the session ID, enforced by the database:

const event = stripe.webhooks.constructEvent(rawBody, signature, secret);

const FULFILL_ON = new Set([
  "checkout.session.completed",
  "checkout.session.async_payment_succeeded",
]);
if (!FULFILL_ON.has(event.type)) return res.sendStatus(200);

// Both events carry the same session, so the session ID is the key.
// Read current state: the payload in hand may be older than the truth.
const session = await stripe.checkout.sessions.retrieve(event.data.object.id);
if (session.payment_status === "unpaid") return res.sendStatus(200);

await db.tx(async (t) => {
  // The unique constraint on session_id stops the second fulfillment,
  // whether it comes from a retry, the other event type, or the
  // success page calling the same function.
  const first = await t.result(
    `INSERT INTO fulfillments (session_id) VALUES ($1)
     ON CONFLICT DO NOTHING`,
    [session.id],
  );
  if (first.rowCount === 0) return;
  await fulfill(t, session);
});

res.sendStatus(200);

If a handler must start from payment_intent.succeeded, resolve the PaymentIntent to its session first and use the same key. Two keys for one sale is the bug.

On Flint there is one event to pick. order.paid means the order is paid, on every payment surface, with the line items in the payload. See the handler or get free API keys and run it against a sandbox.

Questions, answered

One event to trust on Flint

Flint is a payments API built around orders. The order exists before any payment does, with its line items, and every way of collecting money attaches to it: hosted checkout, a payment link, an invoice, or your own payment form. That gives the webhook feed one event that answers the fulfillment question. order.paid fires when the order becomes fully paid, whichever surface collected the money, and its data carries what you need to act:

{
  "order_id": "ord_1kmn0aExample",
  "status": "closed",
  "payment_status": "paid",
  "total_money": { "amount": 16400, "currency": "USD" },
  "paid_money": { "amount": 16400, "currency": "USD" },
  "outstanding_money": { "amount": 0, "currency": "USD" },
  "order_payment_intent_ids": ["pi_1kmn0aExample"],
  "line_items": [
    {
      "order_line_item_id": "li_1kmn0aExample",
      "name": "Trail Runner 2",
      "quantity": 1,
      "unit_price_money": { "amount": 12800, "currency": "USD" },
      "total_money": { "amount": 12800, "currency": "USD" }
    },
    {
      "order_line_item_id": "li_1kmn0bExample",
      "name": "Merino socks",
      "quantity": 2,
      "unit_price_money": { "amount": 1800, "currency": "USD" },
      "total_money": { "amount": 3600, "currency": "USD" }
    }
  ]
}

A bank debit that is still processing has not paid the order, so order.paid has not fired, and there is no payment_status check to remember and no second event to wire up for delayed methods. The whole handler:

const { event } = flint.verifyWebhook(rawBody, headers, [
  process.env.FLINT_WEBHOOK_SECRET!,
]);
if (event.event_type !== "order.paid") return new Response(null, { status: 200 });

const order = event.data;

await db.tx(async (t) => {
  const first = await t.result(
    `INSERT INTO fulfillments (order_id) VALUES ($1)
     ON CONFLICT DO NOTHING`,
    [order.order_id],
  );
  if (first.rowCount === 0) return;
  await fulfill(t, order.line_items);
});

return new Response(null, { status: 200 });

Payment-level events are still there when a job calls for them: payment_intent.succeeded for a ledger, subscription.payment_succeeded for entitlements, invoice.paid for accounts receivable. Choosing webhook events maps each job to its event, Webhooks covers signatures, retries, and resends, and Migrating from Stripe moves one payment flow at a time, so you can start with the handler that hurts most.