#shane_webhooks
1 messages · Page 1 of 1 (latest)
đź‘‹ Welcome to your new thread!
⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
đź”— This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1324455973225758842
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
Happy New Year!
Hi đź‘‹ happy new year to you as well!
payment_intent.processing Events are emitted when a Payment Intent needs to go into a processing state:
https://docs.stripe.com/payments/payment-methods#event-destinations
There is no Event type that exists for "still pending" intents. Instead you'd listen for payment_intent.succeeded Events as well, and if you don't receive that in the expected timeframe after the payment_intent.processing Event, then you know the payment is still processing.
Hi Toby, thanks for your quick response, let me take a quick look and get back to you!
For this event sub_1QWp45P5z4SsTbbxbfrKxNWv, I didnt see a payment_intent.processing event being fired, am I missing smth here?
The main concern here is ACH banking customers thought they paid for our service but they actually not yet paid. They often assume they’ve successfully paid for our service once they initiate the payment, even though the funds haven’t cleared yet. This creates confusion when they don’t get access to the service immediately, and we often get questions like, “Why haven’t I received the service I paid for?”
I'm hoping to resolve this from stripe side, if stripe doesnt offer custom webhook events, I can also try to resolve it on our end.
Is there a way to isolate such payments—where the payment intent is created but the invoice hasn’t cleared—using a specific event or webhook? My goal is to temporarily upgrade these customers based on the payment intent, and then use a cron job to check the payment status later. If we don’t receive an invoice.paid event after a set timeframe, we could downgrade their service.
Here's the payment_intent.processing Event that was generated for the Payment Intent belonging to the Invoice that was generated by the Subscription you provided an ID for:
https://dashboard.stripe.com/events/evt_3QWp45P5z4SsTbbx034COsh6
Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.
Since it looks like you're using Checkout Sessions, there are also Checkout related Events that can be used here if you prefer.
https://docs.stripe.com/checkout/fulfillment?payment-ui=stripe-hosted#create-payment-event-handler
such as checkout.session.async_payment_succeeded
https://docs.stripe.com/api/events/types#event_types-checkout.session.async_payment_succeeded
For the successful check, we are currently using invoice.paid event as a success. I think it can handle all payment methods.
If we were to use payment_intent.processing as our trigger to temp upgrade our customer if they use a payment method that doesnt clear immediately, what other info should we read from this event? Cause we also accept credit cards and that was never a problem, I dont want our code changes interrupt our existing flow.
I'm thinking of isolating such events, ONLY when a customer paid in a method that doesn't clear immediately, we temp upgrade them.
For above payment_intent.processing event:
"payment_method_types": [
"card",
"cashapp",
"link",
"us_bank_account",
],
I dont think it clearly indicates the correct payment method though
If I recall correctly, only delayed-notification payment methods result in intents going into a processing state. Do you have an example of an intent from a card payment that we can take a closer look at?
That's not a good field to look at, it shows all payment method types that the intent calculates it can accept or that are explicitly set.
Instead you'll want to retrieve the Payment Method used for the payment using the ID stored in the payment_method field on the Payment Intent.
Let me get you a creadit card payment example, if only delayed-notification payment methods result in intents going into a processing state, that would be wonderful
Then the type field on the Payment Method object can be used to confirm what type of payment method is being used:
https://docs.stripe.com/api/payment_methods/object#payment_method_object-type
Ah, yeah, see it mentioned in the guide I linked earlier that only delayed notification payment methods should go into a processing state:
https://docs.stripe.com/payments/payment-methods#event-destinations:~:text=The customer’s payment was submitted to Stripe successfully. Only applicable to payment methods with delayed notification.
I'm happy to take a look at an example and confirm that's the behavior you're seeing.
I'm only focusing on delayed payment types, cause customer will ask why we paid but not being served lol, the exact payment method doesn't really matter that much. If that is the case I think all i need is payment_intent.processing event .
sub_1QcCCFP5z4SsTbbxVuUL6AUY I believe this sub is paid by credit card
Yup, that Payment Intent for the Invoice for that Subscription seems to have used a card Payment Method. And I don't see that the intent went into a processing state, it went straight to succeeded.
Nice nice
Thank you so much for confirming that
In that case, I will also listen to payment_intent.processing, retrieve customer object and temp upgrade our customer.
Thank you so much for your help!
Then if you receive payment_intent.payment_failed for that intent, you can undo the temp upgrade.
So no cron job is needed? That is sweet!
Only if you want some sort of alert if an intent hangs out in a processing state longer then you want. Otherwise I believe you can use Events to trigger everything.