#florian-ruen_webhooks
sleek saddleBOT
👋 Welcome to your new thread!
⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1280445925067853826
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- florian-ruen_api, 5 days ago, 37 messages
zinc herald
Hello there,
To add more details:
- on checkout.session.completed, I set the default payment added (using setup mode) to default for a customer ;
- for this, I'm listeing payment_method.attached event, to find if there is a similar credit card (using fingerprint) ;
- but the same event is fired if the customer add the credit card using customer portal
My idea is to let the customer portal "like this" without changing the behavior using events (skip the event using success response without anything else)
There is a way to detect from which source an event was generated ?
pearl wyvern
hi! unfortunately not really, there isn't a robust way to know this. The only real approach is something like adding metadata to the PaymentMethod object before attaching it, and looking for the presence (your code) or absence (Stripe process) of it in the webhook handler; I think.
zinc herald
can be an idea, and there is a way when creating a checkout session, to get the payment method metadata directly ? (because in my case the payment method is attached based on a checkout session in setup mode)
It seems in PaymentMethodData of checkout session there is only AllowRedisplay field
pearl wyvern
well if you're using CheckoutSession in mode:setup it creates the PaymentMethod and confirms a SetupIntent(which attaches it to a Customer), there's no way you can access the PaymentMethod safely until you are handling the chekout.session.completed event.
zinc herald
so this can't works, because payment_method.attached seems to be fired before checkout.session.completed, so I can't set the metadata on PaymentMethod easily here
pearl wyvern
yep. unfortunately there isn't a robust way to implement this so there's no good answer here. You can get into the realm of checking if the event is close in time to when you created a CheckoutSession or something.
Ultimately what I would do is not build this the way you're saying. Your use case is just setting the newly-added card as default, right? Then why don't you just do that when handling checkout.session.completed ?
zinc herald
because i also want to check if there is no another similar payment method. there is no check at this time, and I can add the same credit card a lot of times If i want
my idea is to check the fingerprint of the new added method if not already attached to the customer and detatch/set as default depending on the result of this check
but maybe I can also do this on checkout.session.completed ?
pearl wyvern
you can but it would be confusing, the user has already entered their card and got a success message and a redirect, and now you're actually removing it in the backend and have to tell them that somehow
honestly I would not use Checkout for this I would use PaymentElement via https://docs.stripe.com/payments/accept-a-payment-deferred?platform=web&type=setup + https://docs.stripe.com/payments/build-a-two-step-confirmation and you can check the fingerprint of the new PaymentMethod in real-time before confirming the SetupIntent, and can reject it there.
zinc herald
Maybe, but I want to avoid to let my user enter card details on my website.
even though it's secured by Stripe, I think customers may doubt the security/reliability. while redirecting to a Stripe page seems to me to bring more confidence
pearl wyvern
makes sense. I don't really have any other suggestion here though, it's a bespoke use case that Checkout doesn't solve for today (but yes in general the whole "duplicate cards on a Customer" thing is something we'd like to offer built-in solutions for in the future).