brianc-paymentintent | Stripe Developers | Page 1

limpid hazel Sep 17, 2021, 5:06 PM

#

hello, I am not sure I fully understand your premise re:

We are currently upgrading from using Stripe token values to Payment/Setup intents.
but jumping to your actual question:

Is it possible to create a customer with an attached card from a setup intent or payment intent?

yes, both SetupIntent and PaymentIntents can be confirmed with an existing Customer and their attached card

sharp ermine Sep 17, 2021, 5:14 PM

#

To clarify, our checkout process now creates a stripe card token from the customer supplied information, we then take that token and using the Stripe customer creation api, create a customer record with the source param = the generated card token. The process we are migrating to will use the payment intents object. Once we receive the response from creating the payment intent (or setup intent) we want do do the same thing and create a customer record. The issue is, we do not see a card token to use as the source param. How can we do this as we do not see a tokenized card being returned.

"yes, both SetupIntent and PaymentIntents can be confirmed with an existing Customer and their attached card"
I think this is reversed, we do not have an existing customer record when creating the intent, we need to create one once we receive the intent response

limpid hazel Sep 17, 2021, 5:20 PM

#

so the way you do it is

#

1/ create a Customer e.g. cus_123
2/ create a PaymentIntent and pass the customer: cus_123 param and setup_future_usage: off_session param
3/ on the frontend, confirm the PaymentIntent with Stripe.js and Stripe Elements

in 3/, you confirm the PaymentIntent, it creates a PaymentMethod for you (the newer abstraction over Tokens) and it also attaches said PaymentMethod to the Customer

as part of migrating from Charges, I would also recommend moving from Tokens -> PaymentMethods

sharp ermine Sep 17, 2021, 5:29 PM

#

This seems like it would require at least two hits to the Stripe server for one checkout transaction.

1/ user enters card info at checkout using stripe elements and submits the info
2/ we create a customer record (if we are not using tokens to create, can you point us to docs on PaymentMethods to do this?
3/ we store the customer record info in our database
4/ we then need to start the process to create a payment intent using the returned customer Id?

This doesn't seem to be the rigtht way to migrate away from tokens in our scenario,

#

I guess the point is, we do not start with an existing customer created when the transaction begins, as this seems to assume in order to minimize steps/

keen citrus Sep 17, 2021, 5:31 PM

#

@sharp ermine you can create the customer upfront when they sign up. Or you can create the customer later, after their successful payment

#

there are many ways to integrate with Stripe and a lot of it depends on your business model, whether you want returning customers, saved cards, etc.

sharp ermine Sep 17, 2021, 5:33 PM

#

Thankyou -

"there are many ways to integrate with Stripe and a lot of it depends on your business model,"
We already have our model integrated and it is working well, we now need to modernize it for SCA and the flow above that I described is how we are doing it currently. We were told we could not do that any more. Trying to find a clear path to upgrade. That is where we need advice.

keen citrus Sep 17, 2021, 5:35 PM

#

There's a shift between charge and payment intent, mostly to handle async payment methods or extra confirmation (like 3DS) which requires client-side interaction

#

And I know you want advice, but with little information about what the outcome is it's hard because I can advice 10 different approaches

sharp ermine Sep 17, 2021, 5:36 PM

#

Yes, please let me know what else you need to know.

keen citrus Sep 17, 2021, 5:37 PM

#

Mostly what is blocking you with the flow above. You mentioned "extra API requests" but you already do then in your current flow based on the earlier paragraph you wrote

#

The idea with charges is that you collected card details first, got a token, then server-side, used it (create a customer, then charge their card). With PaymentIntents, you flip it, because after the "charge" you likely need 3DS client-side anyways. So you create the PaymentIntent for the right amount first (with or without a customer) and then you confirm it client-side with card details

sharp ermine Sep 17, 2021, 5:41 PM

#

OK. That makes sense. After we get the client-side card details we have previously been creating a customer record and then actually processing the charge, sometimes at a later date. We would use the customer payment method attached, In the PaymentIntents approach, how would we do this?

keen citrus Sep 17, 2021, 5:42 PM

#

If you want to process a charge later, there's a separate API called SetupIntent so that you can still do 3D Secure now, when the customer is here: https://stripe.com/docs/payments/save-and-reuse

sharp ermine Sep 17, 2021, 5:44 PM

#

OK. Got it. With either Payment or Setup intents, how do we create the customer with an attached payment method* from the return information we get from the payment/setup intent response? Still pretty confused by this.

#

*without using the token which is deprecated

keen citrus Sep 17, 2021, 5:46 PM

#

You don't really do this anymore

#

but I'm struggling to see what's confusing you so not sure how to word it

#

usually you have a customer, you associate that customer with the PaymentIntent or SetupIntent and you get "card attachment" automatically done for you as a result of the success of those

sharp ermine Sep 17, 2021, 5:47 PM

#

"You don't really do this anymore" do what anymore? Create customer records with attached payment methid

keen citrus Sep 17, 2021, 5:47 PM

#

yeah that's the thing, you don't do the old flow of "let me collect card details, let me get a token, let me send that to my server, let me attach the card, let me then charge that card"

#

instead you charge a card client-side and it gets attached automatically all in one go

sharp ermine Sep 17, 2021, 5:47 PM

#

" gets attached automatically" to what?

#

a customer records?

#

Do we end up with a custmer record with a payment method attached?

#

I know it must be super clear/simple to you since you work with it every day, but our software/business model is written a certain way and this seems like a complete rewrite/ just trying to be as efficient as possible. I do appreciate your help

keen citrus Sep 17, 2021, 5:50 PM

#

yep all good, the hard part is understanding what you don't understand because you're also too close to "how it used to work"

#

When you create the PaymentIntent: why not just create the customer before that? What's blocking you from doing this?

sharp ermine Sep 17, 2021, 5:58 PM

#

OK. Here is a more simplified flow:

We have a new customer on the checkout page
They are presented with a Stripe elements form
Depending on the product they are purchasing, their card will either be charged immediately or at a later date
They submit the form with card details and product details
We process the order - either by charging the card and storing a Stripe payment method (which is attached to a newly created customer profile ) and transaction ID
- OR - if it is for a charge at a later date, we do not charge the card and store the customer's payment method to be processed at a later date
When charging at a later date, we take the attached card source from the stored customer profile using the "cus_" id and run the charge
The order is added to our database wth a transaction id (if paid immediately) or with an internal flag to let us know it needs to be charged at a later date

How can we use the new payment intents/setup intents to achieve this flow?

keen citrus Sep 17, 2021, 6:02 PM

#

You flip it over:

We have a new customer on the checkout page
They are presented with a choice of purchasing a product or be charged later
They submit their decision
We either create a PaymentIntent or a SetupIntent based on their choice (optionally creating a customer first) and we put setup_future_usage if it's a PI so that the card can be saved automtically

We go back client-side with the PI or SI's client_secret . We show the Elements form to collect card details and we confirm the PI/SI as relevant
=> If that succeeds, the card is automatically attached to the customer as a result for future payments

sharp ermine Sep 17, 2021, 6:05 PM

#

OK. Thanks, That changes our model though. It adds an additional step for the choice. We can't do that. We CAN detect on submit of the payment form if it is a payment or setup intent, but we need to process the order from there, How would that work?

keen citrus Sep 17, 2021, 6:07 PM

#

So I can explain, but honestly you'll regret it and change it later

#

But you can just create a PaymentMethod https://stripe.com/docs/js/payment_methods/create_payment_method like you create a token

#

then server-side you create a customer and attach the PaymentMethod. Then either you decide to charge later and do nothing (but know you will get 3D Secure required when you try and it will likely fail and you'll have to force the customer to come back to your website) or create a PaymentIntent and confirm it, and if 3DS is needed, go back client-side and do 3DS

#

It might be the easiest for you to grasp how it works though I guarantee you'll rework your payment flow later to make this easier anyways

sharp ermine Sep 17, 2021, 6:13 PM

#

"Then either you decide to charge later and do nothing (but know you will get 3D Secure required when you try and it will likely fail and you'll have to force the customer to come back to your website)".
From what I understand, this could happen regardless when the card is save to charge later. This is stated in the docs.

#

If 3DS is needed immediately, it will authorize and then process.

#

"They are presented with a choice of purchasing a product or be charged later
They submit their decision
We either create a PaymentIntent or a SetupIntent based on their choice (optionally creating a customer first) and we put setup_future_usage if it's a PI so that the card can be saved automtically"

Is there any reason why this couldn't be handled when the payment form is submitted with the card details? Can we eliminate this extra step of having to return to the page to get card info after getting payment/setup intent?

keen citrus Sep 17, 2021, 6:20 PM

#

From what I understand, this could happen regardless when the card is save to charge later. This is stated in the docs.
Sure but the likelihood of it happening is >90% if you don't do 3DS/SI upfront

#

I don't fully grasp your follow up I'm sorry. I think part of it is that you haven't really tried PaymentIntents yet

sharp ermine Sep 17, 2021, 6:20 PM

#

Or could we just make them all setup intents and just process the charges immediately after for the ones that need to be charged right away? Would that solve it?

keen citrus Sep 17, 2021, 6:21 PM

#

you're still set on "I separately collect card details and get an object for it and later do something else"

#

Well it's highly discouraged to do that too unfortunately

sharp ermine Sep 17, 2021, 6:21 PM

#

I have a payment intents setup and it is working. I;ve tried it

keen citrus Sep 17, 2021, 6:21 PM

#

Okay so I don't really grasp what part is confusing you in all this and why you're still focused on trying to do things server-side after payment details collection

sharp ermine Sep 17, 2021, 6:23 PM

#

We can't have the extra step in the checkout flow. It won't work for us. It needs to be a normal checkout flow.

"Is there any reason why this couldn't be handled when the payment form is submitted with the card details? Can we eliminate this extra step of having to return to the page to get card info after getting payment/setup intent?" - this being the creation of a payment /setup intent and not having to re-display

keen citrus Sep 17, 2021, 6:25 PM

#

that's the part where I really don't understand you 😦

#

I don't know what you mean and how you want one step

#

The way you do one step is 1/ Create the PI server-side. 2/ Client-side collect card details and confirm the PI in one step

#

if you want to do 1/ Collect card details 2/ Create the payment server-side =====> This leads to having to do 3DS and back on the client

#

Sorry I know it looks like we're running in circles a bit but I am really struggling to see where the disconnect is

sharp ermine Sep 17, 2021, 6:32 PM

#

We want to:

Have the customer complete their card information and submit form for payment
Do whatever needs to be done to create the Payment/Setup Intent
-If during this process we need a 3D or 3DS validation, it is handled with the pop-up
After validation/3D/3DS , we process or save the payment information in our database

It should all happen on one submission without having to make the customer
a) choose to pay now or later , create the payment/setup intent and send back to checkout page
b) display the card info form to collect card info

keen citrus Sep 17, 2021, 6:36 PM

#

-If during this process we need a 3D or 3DS validation it is handled
How can you do that server-side after the PI creation. 3DS happens client-side, you will always have to go back client-side

sharp ermine Sep 17, 2021, 6:37 PM

#

If during this process we need a 3D or 3DS validation " it is handled with the pop-up" from Stripe correct? It has nothing to do with our server, unless I am not understaning it correctly

keen citrus Sep 17, 2021, 6:41 PM

#

but for that to happen, we need to know how much to charge. Which is something you configure on the PaymentIntent

#

so it has to exist before you confirm/collect card details

sharp ermine Sep 17, 2021, 6:48 PM

#

OK. Now we are getting somewhere.

In order to omit the extra step of choice/submit/return for card details, technically we should be able to do that in JS without having to add an addtional action by the customer.

Form is submitted
Amount and currency is sent to Stripe for Payment/Setup Intent
PI/SI id is sent back
Card info is submitted to Stripe for verification
3D/3DS if necessary
Payment is processed - or not if saved for later
The above all happens client side, the info is sent to our server and we add to our database

How would we be able to do that using Stripe elements?

keen citrus Sep 17, 2021, 6:50 PM

#

Just to try and be clear: how is that different from what I explained earlier?

#

Because that's the part I'm not following. What you described is exactly how it should work

sharp ermine Sep 17, 2021, 6:59 PM

#

We have a new customer on the checkout page
They are presented with a choice of purchasing a product or be charged later
They submit their decision
We either create a PaymentIntent or a SetupIntent based on their choice (optionally creating a customer first) and we put setup_future_usage if it's a PI so that the card can be saved automtically

We go back client-side with the PI or SI's client_secret . We show the Elements form to collect card details and we confirm the PI/SI as relevant

This scenario implies that there is another UI step the client (or we) must take. First choose "charge now or later", submit, then display Stripe elements form for the client to fill out and submit.

The scenario above has the Stripe elements form displayed right away and client fills out card info prior to any submit
on submit - with the card info filled in - , the form is submitted, client side code sends request for the PI/SI to be created with the amount/currency, we then get the PI/SI in JS and then allow the form info to submit to Stripe form validation (including 3D if neccesary). Depending on whether it was PI/SI we get some sort of return from Stripe. Is this possible?

keen citrus Sep 17, 2021, 7:06 PM

#

Gotcha, yeah sorry, to me it was implicit you can do that, I just modeled after your write up. This is totally possible but by creating the PI/SI at that point you add latency to the overall payment flow. You need a request server-side, create the PI/SI and potentially the customer, then back

sharp ermine Sep 17, 2021, 7:07 PM

#

Which is what I meant by the extra API calls previously.

#

It's a bit of a square peg round hole for what we already have built but I have a better idea now. Thanks

keen citrus Sep 17, 2021, 7:12 PM

#

gotcha, sorry it took me a while to get there

sharp ermine Sep 17, 2021, 7:13 PM

#

All good! Much appreciated!

#brianc-paymentintent