negative10xprogrammer

[small fjord]

Hi! Let me help you with this.

[wide plaza]

to clarify: which part is the "save during payment" part. Is it adding a customer to the paymentintent or the setupfutureusage property+

[small fjord]

looking through "save during payment"
Are you refering to an article or a feature?

[wide plaza]

https://stripe.com/docs/payments/save-during-payment

Basically:

When user registers, I create a stripe customer. Always. Without any payment methods.

Then, I want payment methods to be added to the customer under two circumstances.

When they go into billing details and simply add a card.

And when they make a purchase, if it's their first time making a purchase, they'd populate the form with their card details

[small fjord]

• PaymentIntent with setup_future_usage charges the customer immediately, but allows to reuse the Payment Method.
• SetupIntent doesn't charge the customer, but allows to reuse the Payment Method in the future.

[wide plaza]

Ok, so they represent almost the same thing then? And it IS setup_future_usage that's the key part here in "save during payment"? A payment intent created without this property but still set to a customer, what happens to that?

[small fjord]

they'd populate the form with their card details
You can't do this, but you can allow them to select and use a saved Payment Method from a list (e.g. based on last 4 digits)

[wide plaza]

@small fjordI mean in stripe elements, surely the first time they make a purchase they'd have to input their card details into the form

after that I will attach the returned payment method to their paymentintent (like you mentioned abov) and this iwell tie it to the customer

allowing for reuse

[small fjord]

You can't reuse the PM without setup_future_usage.

[wide plaza]

Ok. So to recap: All I need to reuse payment/be able to fetch a customer's payments methods is to add Customer = {{CustomerId}} and setup_future_usage to the paymentintent?

What happens when on the second purchase, a paymentintent is created and confirmed in the same way with the same paymentmethod?

and does it need to be set to off_session?

[small fjord]

Yes, you need to use off_session

[wide plaza]

@small fjordAlright. And last question: What happens when on the second purchase, a paymentintent is created and confirmed in the same way with the same paymentmethod?

[small fjord]

Yes

[wide plaza]

no I mean what happens?

If I do this:

First purchase:

        {
            Amount = 100,
            Customer = "1",
            SetupFutureUsage = "off_session",
            PaymentMethod = "1"
        };

And on the second purchase, exact same customer nad paymentmethod. Will stripe just ignore that? I.e. it wil go through as usual and won't be reattached or duplicated

or sohuld the creation of the paymentintent object look different on subsequent requests with same customer nad paymentmethod?

[small fjord]

Why would you provide a PaymentMethod on the first purchase? Where would it come from?

[wide plaza]

@small fjordstripe elements would return it when they input their card details?

[small fjord]

What kind of flow are you following exactly?
Are you creating a PaymentIntent after the customer provides CC data in Payment Element?

[wide plaza]

Yes I've moved almost all of it to the backend, for good reasons (in this case)

1. They interact with payment element
2. It returns a paymentmethod
3. I create and confirm the paymentintent in the same request

and then potentially returna client secret to the client

in case of 3ds auth

I was under the impression this was ok

[small fjord]

Are you following any specific guide that told you to do that?

[wide plaza]

No I was stumbling through the docs at first, but did some testing and asked around here after and htey said it was fine so I just went with it

[small fjord]

I would recommend you to stick to a specific guide as it's very hard to investigate issues if your integration is too bespoke without a good reason

I would recommend you to stick to this: https://stripe.com/docs/payments/accept-a-payment?platform=web&ui=elements

[wide plaza]

The reason is, we didnt have anyone working on the frontend. And so I moved most of it to the backend to speed up the development process

The docs you linked even say: "If you want to render the Payment Element without first creating a PaymentIntent, see Collect payment details before creating an Intent."

So the only difference is, payment element is rendered before we hit hte server. They interact with it, get a paymentmethod, and that is then used on the server to create the paymentintent. Is that really so out there?

this is the flow i went with

[small fjord]

I don't understand what you mean by "moved most of it to the backend"
The order of actions change, but not their location.

[small fjord]

I would recommend you to stick to this unless you have a good reason to use the other flow. The same amount of frontend work is required.

[wide plaza]

Alright, from what I could ascertain at the time, it seemed like more work had to be done on the client. But maybe that assumption was incorrect. Either way, I've already written this code with the flow outlined above

so im asking, will it work?

I also think it was a design choice.

With the recommended flow, it seems like I'd have to create a paymentintent when I might actually want a setup intent (since you can decide not to pay online, but in person. We use setup intent here to charge on cancellation)

The client flow is: They select accommodations, click book -> this should take them to the checkout. Here, they input their card details and personal details and select if they want to pay online or in person. If they select online, obviously we should create a payment intent... but then what? Now we're creating a payment intent on the server without a payment method, which requires an additional step

if they select pay in person, we create a setup intent with off session usage

but the recommended flow would be like this: create paymentintent without paymentmethod ón the server, return, and then the client both attaches paymentmethod and confirms?

[small fjord]

In this case I would suggest always collecting a Payment Method with a SetupIntent, and then deciding whether you want to charge it or not with a PaymentIntent (with "off-session").

[wide plaza]

even if i intend to charge it immediately? hmm alright

[small fjord]

It can be after 10 seconds, 5 minutes or 2 weeks.

[wide plaza]

ok so you're saying i should skip the creation ogf paymentintent entirely, and regardless of online vs pay in person, create a setup intent with the customer (and paymentmethod from client) attached, then simply create a paymentintent out of it with autoconfirm upon charge+

and that's it?

[small fjord]

Correct.

[wide plaza]

ok, I'll rewrite my flow then. Just one question, is there a reason this is preferred over the other strategy? paymentintent with paymentmethod and setupfutureusage? is it because oyu dont want paymentintents with paymentmethods laying around?

[small fjord]

It's a simpler mental model: you acquire a Payment Method (with SetupIntent) and then decide what to do with it later, charge or not charge.

[wide plaza]

gotcha thanks