#lasergecko_checkout-customers-paymentmethods
noble portalBOT
👋 Welcome to your new thread!
⏲️ We'll be here soon! We typically respond in a few minutes, but in some cases we might need a bit more time (e.g., server's busy, you've got a complex question, etc.).
⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can 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/1255274999049355345
📝 Have more to share? Add details, code, screenshots, videos, etc. below.
sand locust
Hi 👋
Yes, specifying payment_intent_data.setup_future_usage on the Checkout Session creation will create a Payment Method that is optimized for being charged off-session (merchant initiated transaction). However, you need to provide a Customer object when you create the Session in that case.
upbeat bramble
So, in the future when we charge their card, we need to provide the Customer data that gets returned in the webhook. Correct? (id or the full object?)
What endpoint will that charge session go to?
sand locust
Sorry, now I'm confused.
If you want to save the payment method, you need to first create a Customer and pass that Customer ID as a parameter when creating the Checkout Session
https://docs.stripe.com/api/checkout/sessions/create#create_checkout_session-customer
When you charge the card, you will likely want to include both the Payment Method and Customer ID
upbeat bramble
I have customer_creation=always set.
Does that tell Stripe "Hey, if they are already a customer, do your magic and match to their existing Customer. If not, create a new Customer when they pay and send us the id"?
sand locust
No, that says create a new Customer record every time someone pays
upbeat bramble
But, since these are going to be all new to us Customers, then, that's fine, right?
From a merchant's perspective, each Customer is unique, but personally, as a buyer, I have a different Customer Id with every Stripe merchant.
For next year's event, I will include the Customer_id when I create the deposit Checkout Session.
tl;dr - If you have it, send it. If not, store it for next time.
sand locust
If you have it, send it. If not, store it for next time.
Correct. SO in that case it makes sense to create new customers
upbeat bramble
Thank you, @sand locust! I was wondering how the heck we were supposed to search and find their Stripe Customer info, but knew that PCI compliance made that a highly improbable workflow!
sand locust
You can test this entire flow end-to-end in Test mode to make sure it behaves the way you expect
I would be listening to checkout.session.succeeded webhook events to get details on the Customer and Payment Method objects created as well
upbeat bramble
Oh, I've been testing. I can type 4242 4242 4242 4242 faster than anyone I know. 🙂
Yeah, I found that over the weekend since I couldn't find anything on the payment webhooks. Of course, I found it about half an hour after sending the email.
Are there any other webhooks I should definitely enable? All of them seems like it would be too much to handle, but I was thinking about the ones related to chargebacks and settlements, for sure.
sand locust
Determining which webhook events to listen to in general is a bigger topic. I recommend starting in test mode and using the Stripe CLI with stripe listen to get a sense for all the webhooks that fire when certaina actions take place. You can examine the data sent and what makes sense to listen to.
Plenty of our actions trigger multiple events and finding the right one for you will depend on what data you care about.
For instance, when a Checkout Session is successfully completed with a Card PM, you will get checkout.session.succeeded , payment_intent.succeeded and charge.succeeded. It all depends on what data you care about which one you should listen to
upbeat bramble
Copy that. Will give it a shot. This is all basically cURL for now. Thank you for your help! When my buddy initially said "Stripe", I thought oh no since I hadn't worked with it, but now that I know more about it and how the Big Brains handle all the PCI compliance, super thumbs up!
sand locust
We do try to allieviate some of the difficulty 🙂
We also have a bunch of testing card numbers that will trigger different kinds of failures when you are ready to build tests for that too: https://docs.stripe.com/testing#declined-payments
upbeat bramble
Cool! I had seen that, but not in a couple of weeks!
These are all pre-approved clients and thoroughly vetted/contracted, so we should be safe from chargebacks and such. The system is locked down, so no one can just "sign up" for an account.
I think that should cover it. Thank you again for the awesome help!
sand locust
That's why we're here 🙂