#nerder
paper hollow
inner adder
That depends on what you want to know. Is your Checkout only supporting Subscriptions?
lofty bobcat
for now yes, but in my native integration i'm supporting also one-off payments
inner adder
When you say "native integration" are you using Payment Intents?
lofty bobcat
yes
inner adder
But your DB only cares about Subscriptions?
lofty bobcat
No i also handle one-off payments but they are out of scope for this web integration that i'm doing
but why is this relevant? I'm not following you I guess 🤕
inner adder
Okay. In that case you may want to also listen for customer.subscription.updated in case you allow any modifications the Subscription
I wanted to know if you wanted to listen to payment_intent.payment_succceeded
lofty bobcat
right now i'm mainly listening this:
case StripeWebhookEvent.CUSTOMER_SUBSCRIPTION_DELETED:
case StripeWebhookEvent.CUSTOMER_SUBSCRIPTION_CREATED:
case StripeWebhookEvent.CUSTOMER_SUBSCRIPTION_UPDATED:
case StripeWebhookEvent.INVOICE_PAID:
and do stuff accordingly (like saving the subscription on my DB to retrieve it later, etc)
now I can see that when the checkout session is completed, all this webhook events are firing correctly and I can see the subscription and customer created in my DB and all
(only issue is with payment_method.attached which is for some reason fired before customer.created, but this is an issue with my integration I guess)
inner adder
Webhook event delivery is not guaranteed to be in order
lofty bobcat
What I'm trying to do right now is to handle the success_url callback, and on that page, I want to show some customer information for instance the email and name.
so in my head I need to:
- retrieve the checkout session using the provided ID
- extract the customer_id an retrieve that as well
the question here is, I should wait for checkout.session.completed before allowing that?
inner adder
Is this on the back-end or front-end
lofty bobcat
on the backend
inner adder
- You can shorten the API calls by using Expand on the Customer Property for the Checkout Session https://stripe.com/docs/expand
lofty bobcat
this is good
inner adder
You should be able to get the current state of the Checkout Session when you make the API call and include that in your response to your customer
lofty bobcat
Ok, but in this case if i'm in the success_url is most likely to be completed already no?
inner adder
That depends on the payment method. If you are retrieving the Checkout Session object from the API you'll be able to inspect the status anyway
lofty bobcat
oh you are right, might be paid using SEPA for instance
inner adder
And in that case the Checkout Session will complete but the payment won't be paid for up to 3 days or so
lofty bobcat
Ok I see
inner adder
Which is where payment_intent.payment_succeeded can be useful
Sorry
payment_intent.succeeded
lofty bobcat
so to recap, when the fronted is accessing the success_page i:
- call my backend passing as a parameter the checkout session ID
- call Stripe API retrieving that session (expanding the customer to avoid calling the api again)
- return to the frontend the information I need (email, name) and also the status of the checkout session to be handled accordingly in the frontend
inner adder
If you think that will provide your customers with the information you want, that'll work nicely.
lofty bobcat
yes for now this is more than enough, this is just a web companion but all the main informations are in the app
is just a way to handle the checkout before downloading the app 🙂
inner adder
Makes sense 👍