k3davis-setup-intents

[frank otter]

Hi! Yep, you want to follow our guide here and use SetupIntents: https://stripe.com/docs/payments/save-and-reuse?platform=web

[gusty lava]

i specifically want to create a payment method and not a setupintent at this point, because i can't create the customer until later. i don't think i can create a setupintent without a customer?

then later (perhaps 1 day) assign/use that payment method id to create a setupintent

[frank otter]

Ah thanks for clarifying. In that case you use stripe.createPaymentMethod (https://stripe.com/docs/js/payment_methods/create_payment_method) with card Element

[gusty lava]

and when i do so it is possible to use that payment method id to create a setupintent later, when i have my customer?

[frank otter]

Yep

You can pass a PaymentMethod ID to a SetupIntent

You would just confirm it server-side in this case.

And then redirect the customer to complete 3DS if necessary

https://stripe.com/docs/api/setup_intents/create#create_setup_intent-payment_method

[gusty lava]

aha! thank you very much

[frank otter]

Sure thing!

[gusty lava]

if i may ask a follow up, is there a similar method i can use for ACH direct debit

[frank otter]

With ACH Direct Debit you would not use Elements, you would just collect the account/routing yourself and create a PaymentMethod server-side: https://stripe.com/docs/api/payment_methods/create#create_payment_method-us_bank_account

[gusty lava]

that's easy to do but does that meet nacha verification rules? eg when the setupintent is created will they be directed to complete the verification?

[frank otter]

Yes you would do the same flow.... you would confirm the SetupIntent and pass the PaymentMethod. This will initiate the verification just like if you are using the flow where you use Stripe.JS to collect details: https://stripe.com/docs/payments/ach-debit/set-up-payment

[gusty lava]

the docs seem a bit vague on that

The Stripe Financial Connections authentication flow automatically handles bank account details collection and verification

how is that done if the user isn't on the form anymore (maybe it was yesterday)? how are they prompted "off-session" to complete that?

[frank otter]

Ah sorry didn't specify. They would have to be brought back on-session for that flow to work.

However, I believe you could run the microdeposit flow without bringing them on-session if you collected mandate acceptance when you first collect bank details.

Overall though I really don't recommend this route. I'd just set up the bank account and create the Customer when you collect the bank details.

What is preventing you from going that route?

[gusty lava]

i'm unable to create the customer at the same time because the only way to check for an existing customer first is by email address, which is not a unique identifier in our system (multiple donors, typically spouses, may share). so i don't know who they are in our internal system yet, i would end up with multiple copies of them in stripe if i did it before the internal id was validated

basically i'd need a one to many mapping of our id and stripe customer ids to gather all their info in our system

[frank otter]

Hmmm okay and collecting email prior to these payment method details is not an option?

[gusty lava]

no, i can (and do) collect the email. but if it is an email shared by multiple donors, i wouldn't know which one yet. or if it's an existing donor who is unbeknownst to us using a different email address, we'd have the same issue

i feel like i am overthinking it but i can't figure out a way to avoid endless customer duplicates

[frank otter]

I'm confused, how do you verify that thereafter?

[gusty lava]

once we've taken in the form submission we use search match etc on our end to identify the donor (or create them in our system if they don't exist)

so theoretically if i collected all the "biodemo" and the payment method id i can construct the intents after the donor and stripe customer relationship is established

[frank otter]

Is there good reason not to use a two-step process here?

Like get all the non-payment-method info and perform your database check then handle the new or existing customer for payment method data?

You could still do this all on one page. Just two forms

[gusty lava]

well, that would essentially require them to log in to donate, which would solve this problem, but cause others. the search match process isn't real time and sometimes needs human intervention

[frank otter]

Ah okay the human intervention is a key missing piece.

You wouldn't need them to log in necessarily

But yeah if you need human intervention then that is going to be challenging here

[gusty lava]

typically the results are automatic but sometimes donors are so alike (or have moved and not told us) that errors arise and need to be manually "fixed"

that's why i suggested that they would need to log in to firmly establish identity if we were to try to do it all in the standard order

[frank otter]

Yeah I was more thinking you would just have them put in whatever personal details you use to search match in step one of the page and then collect payment method on step 2. No separate "log in" per say

[gusty lava]

makes sense, i wish that were a reliable option on our end :/

it seems like we need to choose between authenticated forms or collecting the payment methods manually and creating the intents later

[frank otter]

Yeah I think that's right.

I have to step away but my colleague @sonic hare is here if you have further questions we can help with

[gusty lava]

thanks for your input

[sonic hare]

👋 Let me know if you have any other questions

[gusty lava]

thanks karbi, i think i'm set for now, i'm going to document some things and see if I have any gaps left. thank you!