[Bug]: core stripe payment integration - double /capture api

[420coupe]

Package.json file

{
  "name": "medusa-starter-default",
  "version": "0.0.1",
  "description": "A starter for Medusa projects.",
  "author": "Medusa (https://medusajs.com)",
  "license": "MIT",
  "keywords": [
    "sqlite",
    "postgres",
    "typescript",
    "ecommerce",
    "headless",
    "medusa"
  ],
  "scripts": {
    "build": "medusa build",
    "seed": "medusa exec ./src/scripts/seed.ts",
    "start": "medusa start -p 9777",
    "dev": "medusa develop -p 9777",
    "test:integration:http": "TEST_TYPE=integration:http NODE_OPTIONS=--experimental-vm-modules jest --silent=false --runInBand --forceExit",
    "test:integration:modules": "TEST_TYPE=integration:modules NODE_OPTIONS=--experimental-vm-modules jest --silent --runInBand --forceExit",
    "test:unit": "TEST_TYPE=unit NODE_OPTIONS=--experimental-vm-modules jest --silent --runInBand --forceExit",
    "full-cost-reconcile": "node -r dotenv/config -r ts-node/register src/scripts/full-cost-reconciliation.ts",
    "per-message-costs": "node -r dotenv/config -r ts-node/register src/scripts/per-message-cost-tracker.ts",
    "monitor-db-pool": "node -r dotenv/config -r ts-node/register src/scripts/monitor-db-pool.ts",
    "backfill-tiers": "medusa exec ./src/scripts/backfill-customer-tiers-merged.ts"
  },
  "dependencies": {
    "@medusajs/admin-sdk": "latest",
    "@medusajs/cli": "latest",
    "@medusajs/framework": "latest",
    "@medusajs/medusa": "latest",
    "@mikro-orm/core": "6.4.3",
    "@mikro-orm/knex": "6.4.3",
    "@mikro-orm/migrations": "6.4.3",
    "@mikro-orm/postgresql": "6.4.3",
    "@sendgrid/eventwebhook": "^8.0.0",
    "awilix": "^8.0.1",
    "multer": "^1.4.5-lts.1",
    "pg": "^8.13.0",
    "twilio": "^5.3.3"
  },
  "devDependencies": {
    "@medusajs/test-utils": "latest",
    "@mikro-orm/cli": "6.4.3",
    "@swc/core": "1.5.7",
    "@swc/jest": "^0.2.36",
    "@types/jest": "^29.5.13",
    "@types/multer": "^1.4.12",
    "@types/node": "^20.0.0",
    "@types/react": "^18.3.2",
    "@types/react-dom": "^18.2.25",
    "jest": "^29.7.0",
    "prop-types": "^15.8.1",
    "react": "^18.2.0",
    "react-dom": "^18.2.0",
    "ts-node": "^10.9.2",
    "typescript": "^5.6.2",
    "vite": "^5.2.11",
    "yalc": "^1.0.0-pre.53"
  },
  "engines": {
    "node": ">=20"
  },
  "packageManager": "yarn@3.2.3+sha512.f26f951f67de0c6a33ee381e5ff364709c87e70eb5e65c694e4facde3512f1fa80b8679e6ba31ce7d340fbb46f08dd683af9457e240f25a204be7427940d767e"
}

Node.js version

v20.18.1

Database and its version

PostgreSQL 15.6

Operating system name and version

Ubuntu 25.04

Browser name

Brave

What happended?

The stripe endpoint /capture is called twice on a processPaymentWorkflow event whether manual or automatic capture from medusa-config.ts. I even tested with two different version frontend package versions and see the results below:

Default versions used by medusajs packages (core medusa stripe integration and nextjs-starter)

backend medusajs: 
@medusajs/medusa@2.9.0 invalid: "latest" from the root project
  └─┬ @medusajs/payment-stripe@2.9.0
    └── stripe@15.12.0

frontend nextjs:
├── @stripe/react-stripe-js@1.16.5
├── @stripe/stripe-js@1.54.2

Here find the following: Multiple calls to stripe /capture api endpoint

1. top manual capture
   "capture_method": "manual"
2. bottom automatic
   "capture_method": "automatic"

Different package version frontend

backend medusajs: 
@medusajs/medusa@2.9.0 invalid: "latest" from the root project
  └─┬ @medusajs/payment-stripe@2.9.0
    └── stripe@15.12.0

frontend nextjs:
├── @stripe/react-stripe-js@3.9.2
├── @stripe/stripe-js@7.9.0

Here find the following: mutiple calls to strpipe /capture api endpoint on manual, 1 /capture and 1 /cancel on auto

1. top manual capture
   "capture_method": "manual"
2. bottom automatic
   "capture_method": "automatic"

Payment is successfully captured in both scenarios with both package versions. However at times there can occur a race condition between the capture events and the .confirmPayment on the nextjs frontend leading to a refund after an order is successfully processed and fulfilled in the case of digital products.

Expected behavior

1. payment intent created
2. .confirmPayment - if capture: true this is where payment is collected as "capture_method": "automatic" is passed due to the config below in medusa-config.ts

{
      resolve: "@medusajs/medusa/payment",
      options: {
        providers: [
          {
            resolve: "@medusajs/medusa/payment-stripe",
            id: "stripe",
            options: {
              apiKey: process.env.STRIPE_API_KEY,
              webhookSecret: process.env.STRIPE_WEBHOOK,
              automatic_payment_methods: true,
              capture: true,
            },
          },
        ],
      },
    },

3. order created after success response from .confirmPayment
4. There would be no need for the /capture api calls if capture: true

Actual behavior

1. payment intent created
2. .confirmPayment - payment is captured - race conditions occur 1/1000
3. order created after success response from .confirmPayment
4. processPaymentWorkflow - /capture api call
5. processPaymentWorkflow - /capture api call (from webhook response)

Link to reproduction repo

https://github.com/medusajs/medusa-starter-default/

[420coupe]

To clarify the race condition actually occurs from .confirmPayment and the paymentWebhook.

When option capture:true is set the .confirmPayment() is sent with the confirmation_method: "automatic", so payment is collected in the .confirmPayment() step. After payment is confirmed cart/[id]/complete is called where processPaymentWorkflow is called.

Then the paymentWebhook is hit and if the status is authorized or succeeded webhook also runs processPaymentWorkflow. This causes the race condition.

[radeknapora]

@willbouch @olivermrbl - sorry for tagging, but I’d like to bump this issue as it’s a serious problem in my case as well.
As @420coupe described, the race condition between .confirmPayment() and the paymentWebhook sometimes leads to orders not appearing in the admin dashboard, which makes it critical for production use.

Also, as seen from the reactions here, this seems to affect multiple users.

Could you please take a look at this? 🙏
Thanks in advance!

[willbouch]

Yes, this does look like a nasty little bug. Will take a look asap

[420coupe]

Any update on this? Seems to be occurring much more frequently (1/5020)

[willbouch]

I am sorry, I haven't had time to take a look at it yet. It is still in my todo list :/

[420coupe]

I am sorry, I haven't had time to take a look at it yet. It is still in my todo list :/

I'm pretty sure this is a simple fix, just need a check on the process-payment call so if/when it gets called from the webhook it ignores it as it's already successfully processed.

Double check but i'm 99% sure this is a simple solution for this issue. @willbouch

edit - see PR above.

[adrien2p]

hey @420coupe, thank you for the pr and issue, but I have a few questions before proceeding further.
Wich locking module have you configured? cause here the thing, the complete cart workflow acquire a lock upon execution, meaning that the first to acquire it will run through and the one that is queued will execute only after completion. therefore, the next run should return the already created order.

[420coupe]

hey @420coupe, thank you for the pr and issue, but I have a few questions before proceeding further. Wich locking module have you configured? cause here the thing, the complete cart workflow acquire a lock upon execution, meaning that the first to acquire it will run through and the one that is queued will execute only after completion. therefore, the next run should return the already created order.

I have it in a production environment with server, worker and redis each dockerized in it's own container.

The second to run fails and gets response below and initiates a refund - in some cases reverses order that may have already been fulfilled as in my case with digital products.

Cart cart_xxxx is already completed. 

ERR Encountered an error when trying to delete payment session - payses_xxxx - Error: An error occurred in cancelPayment: You cannot cancel this PaymentIntent because it has a status of succeeded. Only a PaymentIntent with one of the following statuses may be canceled:requires_payment_method, requires_capture, requires_confirmation, requires_action, processing...

Should we keep the convo here on in the PR?

[adrien2p]

I believe we can keep the convo here.m 👌
And the locking module you are using is it the redis one or the Inmemory one?

Because there is two things, the payment workflow up ont calling the complete cart workflow has a continueOnPermantFailure, so there shouldn’t be any compensation there, which seems different for you. Also, there is the lock in the complete cart, which means the workflow on the second run should return the order without doing anything 🤔

It means that there is something else at play.

[420coupe]

I believe we can keep the convo here.m 👌 And the locking module you are using is it the redis one or the Inmemory one?

Because there is two things, the payment workflow up ont calling the complete cart workflow has a continueOnPermantFailure, so there shouldn’t be any compensation there, which seems different for you. Also, there is the lock in the complete cart, which means the workflow on the second run should return the order without doing anything 🤔

It means that there is something else at play.

I am using the actual redis instance, here's entire medusa-config.ts

with these env settings for db

DB_POOL_MIN=15
DB_POOL_MAX=70
DB_ACQUIRE_TIMEOUT=45000
DB_CREATE_TIMEOUT=20000
DB_DESTROY_TIMEOUT=3000
DB_IDLE_TIMEOUT=25000
DB_REAP_INTERVAL=2000
DB_CREATE_RETRY_INTERVAL=300

import { loadEnv, defineConfig } from "@medusajs/framework/utils";

loadEnv(process.env.NODE_ENV || "production", process.cwd());

module.exports = defineConfig({
  projectConfig: {
    databaseUrl: process.env.DATABASE_URL,
    // Database connection pool configuration for performance
    databaseDriverOptions: {
      connection: {
        ssl: { rejectUnauthorized: false },
      },
      pool: {
        min: parseInt(process.env.DB_POOL_MIN || "5"),
        max: parseInt(process.env.DB_POOL_MAX || "20"),
        acquireTimeoutMillis: parseInt(
          process.env.DB_ACQUIRE_TIMEOUT || "30000"
        ),
        createTimeoutMillis: parseInt(process.env.DB_CREATE_TIMEOUT || "15000"),
        destroyTimeoutMillis: parseInt(
          process.env.DB_DESTROY_TIMEOUT || "2000"
        ),
        idleTimeoutMillis: parseInt(process.env.DB_IDLE_TIMEOUT || "15000"),
        reapIntervalMillis: parseInt(process.env.DB_REAP_INTERVAL || "1000"),
        createRetryIntervalMillis: parseInt(
          process.env.DB_CREATE_RETRY_INTERVAL || "200"
        ),
      },
    },
    // Worker mode configuration for production deployment
    workerMode:
      (process.env.MEDUSA_WORKER_MODE as "shared" | "worker" | "server") ||
      "shared",
    // Redis URL for sessions, cache, and workflows
    redisUrl: process.env.REDIS_URL,
    http: {
      storeCors: process.env.STORE_CORS!,
      adminCors: process.env.ADMIN_CORS!,
      authCors: process.env.AUTH_CORS!,
      jwtSecret: process.env.JWT_SECRET || "supersecret",
      cookieSecret: process.env.COOKIE_SECRET || "supersecret",
    },
  },
  admin: {
    backendUrl: process.env.MEDUSA_BACKEND_URL,
    // Disable admin in worker mode
    disable: process.env.DISABLE_MEDUSA_ADMIN === "true",
  },
  modules: [
    // Production Redis modules for caching, events, and workflows
    {
      resolve: "@medusajs/medusa/cache-redis",
      options: {
        redisUrl: process.env.REDIS_URL,
      },
    },
    {
      resolve: "@medusajs/medusa/event-bus-redis",
      options: {
        redisUrl: process.env.REDIS_URL,
      },
    },
    {
      resolve: "@medusajs/medusa/workflow-engine-redis",
      options: {
        redis: {
          url: process.env.REDIS_URL,
        },
      },
    },
    {
      resolve: "@medusajs/medusa/locking",
      options: {
        providers: [
          {
            resolve: "@medusajs/medusa/locking-redis",
            id: "locking-redis",
            is_default: true,
            options: {
              redisUrl: process.env.REDIS_URL,
            },
          },
        ],
      },
    },
    // Custom modules
    {
      resolve: "./src/modules/digital-product",
    },
    {
      resolve: "./src/modules/marketing",
    },
    {
      resolve: "@medusajs/fulfillment",
      options: {
        providers: [
          {
            resolve: "@medusajs/fulfillment-manual",
            id: "manual",
          },
          {
            resolve: "./src/modules/digital-product-fulfillment",
            id: "digital",
          },
        ],
      },
    },
    {
      resolve: "@medusajs/medusa/notification",
      options: {
        providers: [
          {
            resolve: "@medusajs/medusa/notification-sendgrid",
            id: "sendgrid",
            options: {
              channels: ["email"],
              api_key: process.env.SENDGRID_API_KEY,
              from: process.env.SENDGRID_FROM,
            },
          },
          {
            resolve: "./src/modules/twilio",
            id: "twilio",
            options: {
              channels: ["sms"],
              account_sid: process.env.TWILIO_ACCOUNT_SID,
              auth_token: process.env.TWILIO_AUTH_TOKEN,
              messaging_service_sid: process.env.TWILIO_MESSAGING_SERVICE_SID,
            },
          },
        ],
      },
    },
    {
      resolve: "@medusajs/medusa/file",
      options: {
        providers: [
          {
            resolve: "@medusajs/medusa/file-s3",
            id: "s3",
            options: {
              file_url: process.env.SUPABASE_S3_FILE_URL,
              access_key_id: process.env.SUPABASE_S3_ACCESS_KEY,
              secret_access_key: process.env.SUPABASE_S3_SECRET_KEY,
              region: process.env.SUPABASE_S3_REGION,
              bucket: process.env.SUPABASE_S3_BUCKET,
              endpoint: process.env.SUPABASE_S3_ENDPOINT,
              prefix: process.env.SUPABASE_S3_PREFIX,
              additional_client_config: {
                forcePathStyle: true,
              },
            },
          },
        ],
      },
    },
    {
      resolve: "@medusajs/medusa/payment",
      options: {
        providers: [
          {
            resolve: "@medusajs/medusa/payment-stripe",
            id: "stripe",
            options: {
              apiKey: process.env.STRIPE_API_KEY,
              webhookSecret: process.env.STRIPE_WEBHOOK,
              automatic_payment_methods: true,
              capture: true,
            },
          },
        ],
      },
    },
  ],
});

edit: also i tried both in-memory and redis instance and race condition occurs in both.

edit2: i see the images didnt take here are some examples of different fails.

This one was weird, Payment successful, no order was created unlike others where order gets created and reversed/left unfulfilled

This last one order created, Payment successful, no refund, order created but not fulfilled -skipped a bunch of steps