#stickyjams_api
hushed hatchBOT
👋 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/1397076233094692904
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
oak shale
Hi there 👋 I just want to acknowledge your question. I'm working on other threads and will get to yours soon!
forest osprey
no problem, thanks
oak shale
thanks for waiting, could you share with me the API request ID that return the error? Here’s how you can find the request ID: https://support.stripe.com/questions/finding-the-id-for-an-api-request
forest osprey
req_0UZSsS2wMcWoOJ
oak shale
Okay so the request you shared originated from Stripe Checkout. By default, in subscription mode, Stripe Checkout creates a customer and attach the payment method to the created customer: https://docs.stripe.com/api/checkout/sessions/create#create_checkout_session-customer
I'm abit unclear when you mention "create a new account" but is there a reason why you're using the payment method ID created from the customer's previous checkout session and attaching it to a new customer?
forest osprey
what I mean is, if the user already has that payment stored in another username on our system
ex, they create two accounts for whatever reason. they cancel one, etc. it's rare but in that scenario i wouldn't know how to handle this error
oak shale
I see, thanks for the context. In this scenario you will need to retrieve the payment method [0] and specifically expand the customer parameter [1] to check which existing customer the payment method is tied to, then check if its the same customer.
However, as you've said, its not ideal to detach / attach payment methods across customer objects. The most direct way to handle this scenario is to check if the customer first exist in your database and if there's a corresponding Stipe customer ID. If the customer already exists, then pass the existing customer ID into the new Checkout Session.
[0] https://docs.stripe.com/api/payment_methods/retrieve
[1] https://docs.stripe.com/api/payment_methods/object#payment_method_object-customer
forest osprey
I see, so in the context that we know they are already a customer, we send in their customer id to the checkout, but if they go into the checkout without being logged in for example, or on another site (lets say different product but same person) then what
oak shale
Then a new customer ID will be created and when they checkout, a new payment method id should generate
the new checkout session wouldn't use the old payment method id
forest osprey
hmm. thats what I was thinking, but when I am checking out, I'm just using the same test payment info, which is then causing the error I mentioned above when I try to set the users default payment method the one they used to purchase
oak shale
okay i need somemore context actually if you don't mind, what do you mean by "create two accounts and cancels one". Are the accounts in your database?
forest osprey
the error is occurring when I complete a test checkout with a new email, but use the same payment details as a previous order. it seems tahts whats causing it. so I was trying to think of situations where a person would validly enter the same card twice
and yes in that instance, I meant if someone had two accounts on my site, such that we don't know they are a customer
they could also be logged out of my system, buying a new product, etc.
oak shale
Can you share with me the resulted payment from the "test checkout with a new email"? I would like to verify if a new payment method ID was generated because it should have been.
oak shale
and yes in that instance, I meant if someone had two accounts on my site, such t...
Gotcha, the best way to handle this is to check whether an existing customer exist. Once a payment method is attached to a Customer ID in Stripe, you cannot detach it and reattach again.
There shouldn't be a scenario where you need to do this actually because every new checkout session should generate a new payment method ID even if the same card info is used, unless your integration allows previously saved payment method to redisplay.
forest osprey
The flow is -> click checkout button -> sends to Stripe Checkout page -> fill out info -> send to thank you page -> StripeEventListener gets details of successful payment via webhook -> creates new user if new email -> looks at payment method, adds it to the new user as payment method -> error because this payment method is already on a customer
oak shale
when it looks at payment method, from where is it getting the reference?
forest osprey
I apologize, I think I know whats happening
I think that the admin account being logged in is what is confusing the system
I still dont understand why the payment method would be the same though
I am using "payment_method" from the payload data
if I look at the transactions in the test data, I do two transactions back to back with different payment info, different email, and the payment method id is the same 😅
pm_1RnZxGGhtBDavM9YgMNh4A30
no its not, im sorry i have no idea why this is happening
ive never had this issue with stripe before but i never used native checkout
perhaps I'm supposed to be setting it to the "payment_intent" as the default payment method ont he user, instead of the "payment_method"
no thats not a valid payment method. i have no idea.
oak shale
catching up 👋 apologies, i'm juggling other threads
Maybe as a start, could you simulate a scenario where a single customer makes payment twice using different email but the same card, through Stripe Checkout?
By the end, you should have:
- two different Customer IDs
- two different PaymentIntent IDs
- two PaymentMethod IDs
You can then check the PaymentMethod IDs on the resulting two PaymentIntents. The expected behaviour is that each of the PaymentIntent will have its own unique PaymentMethod ID
forest osprey
wait. maybe because i'm generating a subscription this way --- the payment method is already on the customer and so attempting to set it is throwing an error. the "customer" its referring to is the same customer
😅
oak shale
Yes your checkout sessions are creating subscriptions, which will automatically saved the created PaymentMethod to the Customer object. This is also why I said you shouldn't need to detach and attach to another customer
forest osprey
i see. the error message was making think that it was another customer, not the same one. in a previous checkout, I had implemented a payment intent for a single payment, with future billings, then added that payment method to the customer. this worked without error
I guess with this way, it already is all set up for that, so its a redundant step throwing an error
oak shale
From the first request you shared (req_0UZSsS2wMcWoOJ)
- pm_1RnXvuGhtBDavM9YPrzDs4G6 was first attached to cus_SizvjAJGKOHQdr
- req_0UZSsS2wMcWoOJ is trying to attach pm_1RnXvuGhtBDavM9YPrzDs4G6 to cus_SizvIXTv3BzOSr <-- this is a different customer ID thats why req_0UZSsS2wMcWoOJ errored
forest osprey
I'm not sure. I am pulling the info directly from the webhook event
// create the stripe customer
$user->createOrGetStripeCustomer();
$defaultPaymentMethod = $user->defaultPaymentMethod();
if (!$defaultPaymentMethod || $defaultPaymentMethod->id !== $paymentMethod) {
// updating default payment method with error handling
try {
$user->updateDefaultPaymentMethod($paymentMethod);
oak shale
which webhook event?
hushed hatchBOT
gaunt warren
Hey! Taking over for my colleague.
req_0UZSsS2wMcWoOJ is trying to attach pm_1RnXvuGhtBDavM9YPrzDs4G6 to cus_SizvIXTv3BzOSr <-- this is a different customer ID thats why req_0UZSsS2wMcWoOJ errored
Why are you trying to attach a PaymentMethod that was already attached to a customer, to another one ?
forest osprey
i have resolved the issue
that was not the intention
what was happening is that laravel cashier was creating a new customer
but because the stripe native checkout already creates one
the system was attempting to assign the payment method to a new customer rather than the existing one
it was basically a duplicate customer
I got the "customer" from the payload and assigned it to the user and the error has resolved
there shouldn't be any need to update the payment method on the customer now, should there? for future billing on transactional purchases
gaunt warren
Yeah there is no need to make any additional action, as the payment method is collected and already attached to the customer
forest osprey
ok great. sorry for the confusion.
if i wanted to do an in page payment, it seems complicated to do subscription when there is no customer already, compared to the native checkout
it seems easy with a simple 1 time payment and then starting a subscription on the backend, but for some reason it seems like you can only start the subscription with a user already existing, but the checkout page won't have that info yet (the email will be in the checkout)
gaunt warren
With Checkout Session, you can pass the existing customer if you have one already. You can update the flow to:
- Pass the Customer Id to the Checkout Session, if one exists
- Configure the Checkout Session to create one, if none exists