lumen-payment-webhooks

[bright hound]

Hello! Starting up a thread for you

Before diving in, can you elaborate on this question a bit more:
I'm also not sure how to handle errors. What if the payment is declined after the user is sent to the "thank you" page? How do I show the user that something went wrong?
What do you mean by a payment declining after the user is sent to the "thank you " page?

Are you worried about non-card payments that may have some processing time and take a bit longer to reflect error? or are you just referring to payments that fail in general?

[steady crow]

The truth is, I don't really understand all the complexities of everything that can happen after the user has been sent to return_url, and all the errors that may occur.

In the example I linked to, the docs say that I have to handle 3 options - the payment intent can have the states succeeded, processing, and requires_payment_method (if it fails).

I'm assuming that succeeded guarantees that the money have been sent and the payment is completed, but processing may take some time to resolve, and can result in success or an error.

Are you worried about non-card payments that may have some processing time and take a bit longer to reflect error?
I think mainly that, I just don't know the correct way to handle things in this case.

[bright hound]

Gotcha - so in general, the idea is that after the redirect you'd check the "status" of the Payment and then display different things to you user based on that. If the payment is still processing your UI should say something about payment being in progress but not successful and you'd wait until you get the payment_intent.succeeded or payment_intent.payment_failed webhook event to continue with updating your database or emailing/contacting your user to tell them payment wasn't successful

[steady crow]

Thank you!

I think I'm still a bit confused, I could check the status of the payment intent as I'm loading the thank you page, but I don't understand, where should I be writing all the code that has to do with updating the database to deliver the course?

1. If I'm doing that when the user returns to the return_url, before sending them back the "thank you" page, I can check the status of the payment intent, update my database, and show the user the correct thank you page. But in that case, I would also be updating the database in my webhooks, in case the user closes the browser before being redirected to the return_url. So I end up with two places in my code where I update the databse and deliver the course, that doesn't seem right.

2. Or should I only update the database in my webhooks, but not before loading the thank you page? Then I would be doing it only once, but then I don't know how to show the user the correct "thank you" page that gives them the link to access the content, because to show them that link I have to update the database first.

[bright hound]

Yeah sorry I wanted to address the confusion about the error case first before going into the updating the database part

[steady crow]

(I'm not sure I've explained everything well, maybe this illustration will clarify things a bit)

I'm not sure where I should be updating the database (in webhooks, or in both webhooks and before thank you page?), and if it's just in webhooks, I'm not sure how to display the correct content on the thank you page.

[bright hound]

You shouldn't need to update your database twice - instead, you should add logic to your integration so that whatever first processes the successful payment intent (including updating your database) marks that Payment as being processed. Then, the next trigger (either the webhook or the user hitting the return_url, whichever comes second) can check whether the payment has been processed, and choose to stop if it's already been handled

does that make sense?

[steady crow]

Um... So to mark the payment intent as "processed", should I just put something into its metadata?

Something like this?

  stripe.paymentIntents.update(
    paymentIntentId,
    {
      metadata: {
       hasBeenProcessed: "true"
      },
    }
  )

But then I'd still need to have my database updating logic, both in my webhooks, and before the thank you page? Very similar code would have to be in two places, and I'd use the payment intent metadata to decide which code should run first?

This seems like a very awkward way to handle things, like, I'm violating DRY principle. I'd have to put similar logic into two places in my code. And it will be mostly unpredictable which one will run first, the webhook or the server function before the thank you page?

[bright hound]

There's a lot of different ways you can do mark it as already processed - you could put it in the metadata, you could mark it as processed in your database, etc.

And yes, it would be unpredictable which one would run first but that doesn't really matter - you just want it to be processed as soon as possible so that you can send your customer to the correct "Thank you" page. If you want to add more predictability to this, you could build in some queueing system for your webhook events to wait a little bit before processing them. That way most of them will be processed by the redirect to the return_url and the webhook event would just be for any stragglers that chose to exit the flow early or ran into other issues with the return_url redirect

[steady crow]

I guess I'm trying to figure out - is it normal for experienced people, working on big projects, to have this payment processing code in both places? Is there no more elegant solution, a way to consolidate all this logic in one place?

[sullen lodge]

@steady crow if it were me I'd have one piece of code that does this and then both my webhook and my "redirect" code would call into the same code. Whichever gets there first