andydavies

[sick pier]

HI there 👋 this seems to be mostly outside of the Stripe portion of your flow, so I'll only be able to give some general ideas.

Having your landing page poll your server checking for access is one option, but probably not an ideal one.

You could revise your process so your success page triggers the same access granting as your webhook event handler, which would allow you to control what your users see while their permission is being granted. You could then use the webhook events as a fallback process in case a user closes their browser before your success page has a chance to complete its actions.

[weary granite]

The second idea is interesting, but is there a way to verify that the request (to the success page) has come from Stripe? To prevent just anyone accessing /success and getting the course for free? I know there's a way to verify the webhook.

[sick pier]

Your success page would still want to trigger a process to check whether the payment was made successfully, and if you're coming from one of our hosted checkout pages then I think you can check the referrer header to get an idea of where the customer came from.

[weary granite]

ok, thanks. I think checking the header wouldn't be too secure as the user could modify them.

This looks like it might do what I want: https://stripe.com/docs/payments/payment-intents/verifying-status but I'm not sure where these PaymentIntents fit into Stripe Checkout. Is this more of a Custom payment flow, rather than Stripe Checkout?

[sick pier]

Our Checkout Sessions are higher-level objects that rely on an underlying Payment Intent to process the payment. The Checkout Session objects have a field that contain the ID of their related Payment Intent once the intent has been generated:
https://stripe.com/docs/api/checkout/sessions/object#checkout_session_object-payment_intent

[weary granite]

Ok, so am I right in saying that on my 'success' page I can retrieve the Checkout Session (like this https://stripe.com/docs/api/checkout/sessions/retrieve?lang=java) and check that the payment went through ok? (With the webhook as a fallback)

[sick pier]

Yup, exactly.

[weary granite]

Ok great. One more thing though (thanks for all your help on this), I think I still have a security issue doing this in the success redirect page. Because the user could modify the referrer header.

With webhooks, I see that I can verify the request by checking the stripe-signature header:

String sigHeader = request.headers("Stripe-Signature");
            if(endpointSecret != null && sigHeader != null) {
                // Only verify the event if you have an endpoint secret defined.
                // Otherwise use the basic event deserialized with GSON.
                try {
                    event = Webhook.constructEvent(
                        payload, sigHeader, endpointSecret
                    );
                } catch (SignatureVerificationException e) {
                    // Invalid signature
                    System.out.println(":warning:  Webhook error while validating signature.");
                    response.status(400);
                    return "";
                }
            }

Can I do a similar thing on the success page redirect from Stripe Checkout?

Actually no, I'm talking nonsense. A malicious user could go to the success page but they couldn't modify the Checkout Session. Sorry, long day.

Ok, I think I know what to do from here. Thanks for your help!

[sick pier]

Apologies for the delay! I think this is particularly tricky to handle, because someone savvy could spend enough time looking at how Checkout Sessions work to try to emulate their behavior. One approach that comes to mind, though I'm not fully convinced it's viable (sorry, the server is busy today so thinking through this fully is taking some time), is that you could add a unique ID as a query param on the checkout session's success_url, and then do validation to make sure that value matches what you're expecting.

Best of luck with the project though!