Add config to allow processing to be authorized in stripe base payments

[scherddel]

Summary

What — What changes are introduced in this PR?

Added a configurable option authorizeOnProcessing to the payment-stripe provider that allows transactions in Stripe that may take longer to be processed by the complete cart workflow.

Configuration example:

providers: [
  {
    resolve: "@medusajs/medusa/payment-stripe",
    id: "stripe",
    options: {
      authorizeOnProcessing: true
    },
  },
],

When enabled, the payment can be automatically captured through the webhook or manually captured in the admin backend. The order remains in a pending/authorized state (shown as "orange") until Stripe changes the payment intent status to succeeded.

The solution treats payment intents with status processing as authorized when the authorizeOnProcessing flag is set to true. When false, it falls back to the previous behavior.

Why — Why are these changes relevant or necessary?

Stripe-based payments that have a delayed capturing cycle currently cause cart completion to fail. This feature provides a workaround for users who need to support such payment methods by explicitly enabling this behavior through configuration.

Testing — How have these changes been tested, or how can the reviewer test the feature?

I tested approximately 5 different payment methods in Stripe to ensure existing functionality works as expected. The changes now allow delayed payment methods to function properly during cart completion.

Checklist

Please ensure the following before requesting a review:

• I have added a changeset for this PR
  • Every non-breaking change should be marked as a patch
  • To add a changeset, run yarn changeset and follow the prompts
• The changes are covered by relevant tests
• I have verified the code works as intended locally
• I have linked the related issue(s) if applicable

---

Additional Comments

I recognize that an ideal solution would introduce a more robust way of handling carts or orders with pending payments (e.g., a "parking" mechanism). However, this PR serves as a pragmatic workaround until a more comprehensive solution can be developed. In the meantime, this feature enables support for payment methods that would otherwise block cart completion.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 078902a

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[vercel]

@scherddel is attempting to deploy a commit to the medusajs Team on Vercel.

A member of the Team first needs to authorize it.

[cursor]

This PR is being reviewed by Cursor Bugbot

Details

Your team is on the Bugbot Free tier. On this plan, Bugbot will review limited PRs each billing cycle for each member of your team.

To receive Bugbot reviews on all of your PRs, visit the Cursor dashboard to activate Pro and start your 14-day free trial.

[github-actions]

This PR is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[scherddel]

push

[danielgran]

TYSM for providing this. Im not sure about what exactly might brick, but as a quick fix it totally did the job. IMHO Medusa should support a afterpay method, as this is a super common usecase.

For me, it even registeres the orders but does mark the payment as pending / ready to capure by payment with sepa, which is totally fine for me, as there is a capture integration /webhook for that.

Love to you

[scherddel]

@danielgran Thank you so much for your feedback.

Ultimately, it comes down to balancing the risk of introducing a 'quick fix' that is difficult to deprecate later versus building a robust solution that handles complex payment event combinations.

This is a specific pain point regarding European compliance, where we must place orders on 'hold' to defer contract acceptance while still acknowledging the payment request via email. Medusa doesn't support this workflow out of the box, necessitating significant customization. I view this as a major functional gap, as it currently blocks 20% of available Stripe payment methods.

What do you think @olivermrbl ?

[github-actions]

This PR is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[danielgran]

NOT agree to be stale. This is a major issue.

[danielgran]

@shahednasser May we ask you to triage this issue?

[github-actions]

This PR is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[github-actions]

This PR is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[scherddel]

.

[medusa-os-bot]

Thank you for your contribution!

After reviewing this PR, we need a few things addressed before we can move forward:

Required changes:

• Missing How section — the PR description is missing the How section from the pull request template. Please describe the implementation approach.
• Missing changeset — any code change under packages/ requires a changeset file. Run yarn changeset, select @medusajs/payment-stripe as the affected package, choose patch, and use a message in the format feat(payment-stripe): allow processing status to be treated as authorized via config.
• No tests — the new authorizeOnProcessing option needs unit tests verifying that getStatus() returns AUTHORIZED for processing intent status when the flag is enabled, and PENDING when it is not.
• Incomplete implementation — webhook handler not updated — getWebhookActionAndData unconditionally returns PaymentActions.PENDING for payment_intent.processing events regardless of the authorizeOnProcessing flag:

case "payment_intent.created":
case "payment_intent.processing":
  return {
    action: PaymentActions.PENDING,
    ...
  }

When authorizeOnProcessing is true, getStatus() returns AUTHORIZED for a processing intent — but if Stripe fires a payment_intent.processing webhook, the session will be set back to PENDING. The webhook handler must also check the flag and return PaymentActions.AUTHORIZED when it is enabled.