#Jonah Librach

1 messages · Page 1 of 1 (latest)

lunar pendantBOT
olive ermine
#

This channel is for technical integration questions related to Stripe products. Is your question Stripe related?

dark latch
#

Yes...

# 
if event and event['type'] == 'payment_intent.succeeded':
        payment_intent = event['data']['object']  # contains a stripe.PaymentIntent
        print('Payment for {} succeeded'.format(payment_intent['amount']))
        # Then define and call a method to handle the successful payment intent.
        # handle_payment_intent_succeeded(payment_intent)
olive ermine
#

I see! What is it about Slack documentation? We don't know how Slack works.

For Stripe webhooks, we don't have recommendation of queue system as it depends on your business requirements. Stripe only requires acknowledgement with 200 to ensure that your server receives the event

dark latch
#

Where do you see Slack?

#

Oh lol my bad

#

Sorry haha, sub "slack" for "stripe". Missed that on 2 re-reads trying to understand your question

dark latch
olive ermine
#

Different merchants have different event handling and it's not necessarily queuing the event. handle_payment_intent_succeeded(payment_intent) is just pseudo code on where you can handle the events

dark latch
#

Can you recommend something though? ChatGPT is recommending Redis RQ, but I'd rather do something that doesn't require spinning up an extra server if possible

olive ermine
#

Why do you need a queuing system? If you process the event immediately, there shouldn't be a need of queuing system

dark latch
#

I recall reading it in the docs, one sec

olive ermine
#

Yup, it will be helpful to share the doc link

dark latch
#

Ya, so it's this

#

And what I need to do in my handling is:

  1. write to mongo
  2. call stripe.Subscription.modify
olive ermine
#

This is not a queuing system. Queuing system is to send the messages to another of your system and process them asynchronously

#

The one you're referring to is just simply event handling

dark latch
#

"another of your system", meaning?

olive ermine
#

It doesn't require queuing system

dark latch
#

Right, but the stripe.Subscription.modify, that could take long

#

No?

olive ermine
#

If you wish to process the subscription update (that can take long) asynchronously, then yes - queuing system may be required.

"another of your system", meaning?
This means that the event handling isn't in your webhook code, but sending to another service (other part of your system) to process them asynchronously

dark latch
#

In that case, can you recommend one for use with Flask

olive ermine
#

Queuing system is an infrastructure and isn't binded to any framework or language. It requires additional server to be setup for consuming the queue messages. I'd recommend checking the available queuing systems on the market such as Redis and Kafka and see which works better for you

dark latch
#

ok 😦

lunar pendantBOT
dark latch
#

If I didn't add that to a queue, should I expect to be okay though?

#

Or would it be strongly advised to queue that up

sudden shale
#

Hi @dark latch I'm taking over this thread

dark latch
#

🙂

#

Jack, do you concur with the above advice?

If I am running the above calls in my webhook, suggest I use Redis/Kafka some other queue?

sudden shale
#

I'm unable to provide recommendations beyond Stripe products.

dark latch
#

No, sorry, I mean if I need to make the calls noted above in my webhook

#

Do I need to set up a queue, or would it be alright to process that synchronously?

sudden shale
#

can you elaborate more on " make the calls noted above in my webhook" ?

dark latch
#

What I need to do in my webhook handler invoice.paid is:

  1. write to mongo
  2. call stripe.Subscription.modify
sudden shale
#

OK. Upon receiving the stripe webhook event, you endpoint should responds a 200 immediately. Are you returning 200 before or after the two operations?

dark latch
#

Would it be possible to return 200 and still perform those operations in a Flask server?

#

Current setup is doing it before

# 
handle_payment_intent_succeeded(payment_intent

I suppose that is just a wrapper for enqueuing that event

sudden shale
#

The general advise is to avoid operation that takes longer time (i.e., DB write/read, Network I/O) in webhook handling.

dark latch
#

Okay, so what's the general advice on how to implement

#

And I really appreciate your prompt responses

sudden shale
#

It depends on your integration. If you are receiving lots of events and you webhook is unable to keep up the rate, you might want to implement a queue system so that you can still process the webhook event after returning 200 to Stripe.

dark latch
#

Currently it's not expecting to be processing too many events

#

But I'm still listening

sudden shale
#

But if you are not receiving lots of event and the webhook handling only involves simple operations that don't take lots of time, then you don't need to implement a queueing system.

dark latch
#

Are those operations "simple operations"?

  1. write to mongo
  2. call stripe.Subscription.modify
#

These are run before returning 200]

sudden shale
#

These are IO operations so it may longer time when your DB grows, or your server experience connectivitiy problem

dark latch
#

Are they simple enough to avoid a queue system?

sudden shale
#

My concern is the time to complete these two operations can be long, so that your endpoint won't be able to return 200 in time.

dark latch
#

It wouldn't take longer as my db grows.
Hashing to the userId is O(1), and the write of the field should be << O(log(n))

#

How long is the timeout?

#

It says immediately, but that's not very precise haha

sudden shale
#

Yes, the public doc doesn't specify the webhook timeout.

#

It's your integration so you know it better than anyone else.