#boltizar_code
pure oreBOT
đ 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/1329546397237776475
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
outer marsh
Hello
Yeah I understand this is a bit confusing but the concept of a SetupIntent is that you would set it up for future re-use, which would involve a Customer object. Really, even though you only want it for a one-time payment, you still are going to need to attach to a Customer object (pass one in with your SetupIntent), otherwise the SetupIntent essentially "uses up" the single-use of the PaymentMethod -- it must be attached to a Customer before being used with a PaymentIntent in the future.
hollow pecan
Is there a different route to collecting the card as a payment method to not pass a customer in the PaymentIntent? We upgraded our app to use SetupIntents a while back to use the Element that let us start using Apple Pay, Google Pay, etc plus streamline with ACH Debit.
There are some tradeoffs in how we'll build the guest checkout framework depending on if we pass a customer or not, so it would be good to understand if there's a way to achieve the "no customer" model without breaking away from the rest of what we already have built out and in production so we can evaluate the two paths forward.
outer marsh
Not with a SetupIntent, no. But you can just use an empty Customer object -- what are the tradeoffs?
hollow pecan
Thanks for the tip! We've been sketching out two routes, one where we create a customer that we'll consider a guest customer (and store it accordingly in our database) and one where we just have a guest in our system that's not tied to anything that's reusable. We already listen to webhook events on accounts to act on activity that we don't originate, so this idea of a customer we know about but don't have any way to interact with is something we already support in our model and we'd then apply to these "empty" customers you suggest if we go that route.