#sehr_-PaymentMethods
gusty hedge
it's not possible to turn off this feature. One alternative which I can think of is to never save a PaymentMethod on a Customer for future use.
there're certain conditions where the Checkout Session will offer a pre-existing payment method : https://stripe.com/docs/api/checkout/sessions/create#create_checkout_session-customer so if you want to bypass this, you can aim to avoid fulfilling those conditions
lofty fulcrum
Hmm yeah. This only seems to occur when the customer has a pre-existing subscription tied to their customer object. We're looking to collect both once-off and monthly donations through Stripe.
Currently the user enters a bunch of regulatory data on a form before being sent to Checkout. Here we ask the email to double-check if the customer exists already. If they do we add the customer id to the checkout session creation.
Ideally a user could potentially have multiple subscriptions tied to a single customer object
gusty hedge
ah, if it's subscription then it's going to be difficult to never fulfil those conditions
I'd suggest implementing authentication for your site. It's possible if you never pass in an existing customer id, but it would make it difficult for you to track / link up all the customers then
lofty fulcrum
Hmm, we're a charity trying to make it as simple as possible for users to donate. Authentication adds another complexity to the UX
gusty hedge
hmmmm, how are you planning to allow customers to cancel their subscriptions?
lofty fulcrum
Via phone call to our hotline. But we like the idea of using Stripe Customer Portal for self-management of receipts and expired cards
We'd send the customer portal link via email. Similar to that of the "magic link" login flow
gusty hedge
hrm, i guess Checkout is not the answer in this case. You can consider using Elements - https://stripe.com/docs/billing/subscriptions/build-subscription?ui=elements
https://stripe.com/docs/payments/accept-a-payment
The con is that it's going to take more effort to implement
lofty fulcrum
So if we used Elements we could achieve what's described above? The first issue I see there is we now have to handle address validation ourselves
Pros and cons to both I suppose
gusty hedge
yep, if you used Elements, you wouldn't need to worry about it displaying existing PaymentMethods. And yes, unfortunately you wouldn't have the address validation with Elements.
lofty fulcrum
If we were to require authentication for subscriptions, I could foresee that it'd be possible to split a customer into two customers. One for once-off and two for subscriptions. Not ideal, but then the issue wouldn't exist. The payment method only sticks when you have a subscription tied to your account
Is there an ETA for the Address Element?
lofty fulcrum
If we were to require authentication for subscriptions, I could foresee that it'...
or we get the user to validate their email via magic link before sending them to checkout
gusty hedge
no concrete ETA yet for the Address Element. By magic links do you mean sending the customer an email with a link to validate the email belongs to them? It's pretty much another layer, in which case, you must as well implement authentication, no?
lofty fulcrum
yeah, pretty much. We just need to validate the email belongs to them, otherwise anyone can enter their email and subscribe/donate using their card attached to their customer object. I had envisioned user + pass login when you initially mentioned it. We don't really want to have to manage that if we can avoid it
gusty hedge
i think every option has it's own pros and cons which you'd want to evaluate. For example, with magic links, i can think of a bad actor sending lots of magic links, or if the customer has issues with receiving the email then they might get frustrated and not donate.
ultimately choose one which you can work with 😁
lofty fulcrum
yeah, it's down to how we architect it now. Anywho, thanks for your help!