Build a Pay Once For Access App
This episode is for members only

Sign up to access "Build a Pay Once For Access App" right now.

Get started
Already a member? Sign in to continue
Playing
15. Preventing duplicate Payment Intents

Episodes

0%
Your progress
  • Total: 1h 11m
  • Played: 0m
  • Remaining: 1h 11m
Join or sign in to track your progress

Transcript

00:00
We spoke about a little bit earlier on in the course the issue with multiple incomplete payment attempts being created when we land over on the payments page.
00:10
Now, we're currently a member so let's go ahead and set member to false. Let's just jog our memory of this issue. So if we come over to payments and we come over to Stripe now, you can see that we have an incomplete payment intent.
00:23
If we refresh this page or we navigate back to dashboard and back to this page, that's going to go ahead and create another one. So we're creating a huge amount of payment intents here when there's no real need to do this. Ideally, the flow that we need to get here,
00:37
if we just open up our payment index controller, is go ahead and create a payment intent, set the payment intent ID in a session, so then when the user comes back to this page,
00:47
we just relook up the payment intent that they initially landed on. So we're going to just change this around very slightly to retrieve a prior payment intent if one exists. So if we come back over to the Stripe API reference, you can see we can actually retrieve a payment intent by its ID.
01:09
Now, to grab this, let's just die dump on this payment intent and let's come over and give this a refresh and you can see sure enough we get this ID property in here which we can use. So we're going to be setting this in a session.
01:23
So let's just die dump here and say session has, let's just say payment intent ID. Now, of course, we're going to expect that to be false at the moment, but what we're going to do as soon as we create this payment intent,
01:36
we're going to put this into the session. So let's do that first of all. So we're going to say payment intent, down here, we're going to go ahead and say session put payment intent ID,
01:48
we're going to access that payment intent and grab the ID. Now, when we die dump on session and get maybe payment intent ID, we should see that in there. Great.
02:02
And of course, has is going to go ahead and give us true now. So what we can now do is take this and put this into an if statement and up here say if not session has payment intent ID, then we want to create one and put it into the session.
02:21
So we're going to move that into this if statement here. Now, otherwise, we want to go ahead and look this up. So we're going to die dump on, and if we just reference this abstract payment intents here,
02:35
retrieve, and of course, then we're going to say session get payment intent ID. So now when we land on this page, if we don't have this in session, it's going to create one. Otherwise, it's going to go ahead and retrieve it for us.
02:50
Now, just to sort of demo this within our app, let's just go and head over to our network tab, go and in fact, let's not do that. Let's go ahead and say session forget payment intent ID. And let's just go ahead and kill the page there for now.
03:10
So let's just get rid of that in session. And then let's start again. And we can monitor this over on our payments page. So let's just give this a refresh just to make sure all of the data is coming in.
03:23
And let's just look at the last three characters. So this one is 0IJ. Now, when we land on this page, that's going to create a payment intent for us. Now, we're actually dying and dumping on this.
03:34
So it looks like that was already in there. So let's go over and have a look. So we've got D-O-I-J. Yes, we've got 0IJ in there.
03:42
So that was already in our sessions. That didn't actually get rid of it the first time. Let's go ahead and actually just clear this out in the browser. I think that's going to make a little bit more sense.
03:53
So let's go and just come over to our application. Under our cookies, we can get rid of all of these. Give that a refresh. And let's just sign in again just to make sure everything's sort of nice and clear.
04:07
And we're over in payments. So that will have now gone ahead and created a new one for us, which now ends in, if we just give this a refresh again, 6ZC.
04:20
So now, when we refresh this page, we do get an undefined variable. That's just because we're not doing anything in here. Now, what we want to do is set the payment intent to the retrieved payment intent. So now, when we give this a refresh, however many times we refresh this,
04:38
we're always looking up this one just here, which is in that session for that particular user. Now, you may end up with duplicate payment intents if the user closes their browser and starts this back up again.
04:50
You could put in a cookie technically, a long-lived cookie, but it's not really the end of the world. So now, we have got away from the issue of having multiple payment intents. So we have now got away from the issue of creating multiple payment intents.
05:08
That user can now go ahead and make a payment, like so. Go ahead and be redirected, and there we go. They are upgraded, but we don't have multiple payment intents created before we succeed on the one that we created initially.

Episode summary

In this episode, we tackle the problem where refreshing the payments page or navigating back and forth creates multiple incomplete Payment Intents in Stripe for the same user. This is a common issue that can lead to a cluttered Stripe dashboard and potentially confusing scenarios during payment processing.

We start by taking a closer look at the current behavior: each visit or refresh creates a new Payment Intent, which is not ideal. To improve this flow, we update the controller logic so that when a user lands on the payments page, we first check if there's already a Payment Intent stored in the session. If one exists, we reuse it—instead of creating a new one every time. If there isn't one yet, we create a new Payment Intent and store its ID in the session for future use.

The video walks through changing the controller code, using session helpers to store and retrieve the Payment Intent ID, and testing the logic by clearing sessions and cookies. This way, the same Payment Intent is reused for that user's session unless they clear their cookies or session storage.

By the end, we've successfully prevented duplicated Payment Intents, ensuring every user only has one open intent until they're done with the payment flow. This makes the payment process much cleaner and avoids extra clutter in your Stripe account.

Episode discussion

No comments, yet. Be the first!