Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Confirm Payment notification never sent #1676

Closed
ragulka opened this issue May 15, 2024 · 8 comments
Closed

Confirm Payment notification never sent #1676

ragulka opened this issue May 15, 2024 · 8 comments

Comments

@ragulka
Copy link

ragulka commented May 15, 2024

Cashier Stripe Version

15.3.2

Laravel Version

10.48.9

PHP Version

8.2

Database Driver & Version

No response

Description

It looks like when a subscription is created via Stripe Checkout, and a future payment (on subscription renewal) requires confirmation, the notification is never triggered, because of the is_on_session_checkout check here.

This check was added in this PR to prevent confirmation notifications being sent while the customer is in the checkout session, which makes sense, because the initial payment is not off-session: the customer can already see that they need to confirm the payment when checking out.

However, it seems to me that this flag should be cleared from subscription metadata once the initial payment is successful, so that future renewals can still trigger this notification.

Steps To Reproduce

  1. Create a subscription via checkout, ie
$user->newSubscription('default', 'price_1H9g3eLzK4Z2r3a4')
    ->checkout([
        'success_url' => route('billing'),
        'cancel_url' => route('billing'),
    ]);
  1. Complete the checkout with a valid test card that allows a successful payment
  2. In Stripe Dashboard, update the subscription to use the "Always authenticate" 3DS card (4000002760003184)
  3. Use a test clock on the subscription, and advance the clock to a date after the next renewal
  4. Stripe sends the webhooks as expected
  5. Cashier receives the webhook, but skips processing it, because of this check.
@driesvints
Copy link
Member

Hi @ragulka. Thank you for flagging this. If that's the case then yes we should fix this. I guess it's the invoice.payment_succeeded we need to check for this? We should be able to derive the subscribe for it and clear this metadata key on the subscription.

Copy link

Thank you for reporting this issue!

As Laravel is an open source project, we rely on the community to help us diagnose and fix issues as it is not possible to research and fix every issue reported to us via GitHub.

If possible, please make a pull request fixing the issue you have described, along with corresponding tests. All pull requests are promptly reviewed by the Laravel team.

Thank you!

@ragulka
Copy link
Author

ragulka commented May 20, 2024

I guess it's the invoice.payment_succeeded we need to check for this? We should be able to derive the subscribe for it and clear this metadata key on the subscription.

Correct - invoice.payment_succeeded seems to be the webhook to handle. I can try and put together a PR for this?

@driesvints
Copy link
Member

Yes please! ❤️

@driesvints
Copy link
Member

@ragulka are you still up for sending in that PR?

@driesvints
Copy link
Member

Since we only had one ticket about this and there's no activity here I'm gonna close this one.

@ragulka
Copy link
Author

ragulka commented Jul 30, 2024

@driesvints sorry - somehow I did not see the notifications from this thread. I'd be up to submit a PR, I've just been rather tight with time.

@driesvints
Copy link
Member

@ragulka no worries. Would still very much appreciate a PR when you can spare the time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants