How can I store a payment method for later useage without directly making a payment?

[fulstadev]

Is your feature request related to a problem? (please describe)
I've currently implemented stripe on my website to save a payment method (credit card, google pay and / or apple pay) for later usage, without directly charging at the moment the payment method is stored. According to the custom flow described here: https://docs.stripe.com/payments/save-and-reuse?platform=web&ui=elements

Describe the solution you'd like
I've been checking your docs about the payment sheet, card field and card form field used to store payment method data and directly submit that to stripe; yet all of these involve an associated payment intent, which I don't have at the moment the payment method is stored.

Describe alternatives you've considered
I cannot see any alterantive for this; I'm locked at the point where I have successfully initiated a setup intent for an initiated stripe customer, and thus have the setup intent client secret ready on the client-side. What remains is sending the payment details with that setup intent client secret to stripe to obtain the payment method ID token in response, as it's done in the link provided above using their HTML + Js - way.

Additional context
Or is what I want already possible with your package?

[fulstadev]

Ok I've been digging much further now, and I've found this example here which clearly shows how you can confirm exclusively the setup intent in a first step for a CardField / CardFormField. Yet our app uses credit cards and also Apple Pay and Google Pay as the enabled payment methods, and only your PaymentSheet seems to provide an easy way for Apple Pay and Google Pay. The Payment Sheet however only provides the confirmPaymentSheetPayment() method according to your docs, so it's not clear to me how / if I can confirm only a setup intent using the PaymentSheet.

First, is my understanding correct that all methods of the Stripe class of your package are inherently linked with the values currently provided vir your input widgets (PaymentSheet, CardField & CardFormField) ? Meaning submit calls such as for example confirmPaymentSheetPayment submit the data of the PaymentSheet, to not provide direct access to the form fields for PCI-Compliance, is that it?

In this case, do I understand things correctly that to reach what I want, I have to:

• Have a customer initiated on the server-side
• At the moment the payment method form shall be initiated, create an according setup intent on the server-side and forward the clientSecret of that initiated setupIntent to the client
• Initiate a Payment Sheet in Flutter by calling initPaymentSheet(), setting the setupIntentClientSecret of the SetupPaymentSheetParameters passed to the initPaymentSheet() call to the value obtained in the previous step, customFlow to true, and also set applePay and googlePay to provide these in the payment sheet too.
• Call presentPaymentSheet to display the payment sheet.
• Call confirmPaymentSheetPayment as soon as the customer clicks on "Submit".
• After awaiting the result of that call, call retrieveSetupIntent to retrieve the setup intent, still with the same client secret as the obtained at the very start.
• Verify that the status property of that SetupIntent is now succeeded. If so, it should have the according paymentMethodId property set to the ID of the stored payment method. Which can then be forwarded back to my servers.

--> Is this flow correct?

PS: Yes, I use the older way and not the newer one to store payment method IDs mapped to my customer IDs on my server-side, as my integration prefers manual server-side confirmation.

[remonh87]

Hi, the flow that you described is correct.

Make sure to add a customer to the payment sheet, see stripe docs. Other advantage is thatStripe will make sure that the customer is provided with the correct payment methods.

[fulstadev]

Hi @remonh87 Cheers, but is this required even if you provide the customer ID to the call used to initiate a new setup intent on the server-side according to the docs? Shouldn't that be enough to make sure that the newly created setup intent (of which you'll then use the obtained client secret) is mapped to the correct customer? And thus also the payment method added via that setup intent?

[fulstadev]

@remonh87 Obviously not intending to be rude; but could you may answer my last question? I'm somewhat confused as I've asked how to store a new payment method without a payment intent / paying, but the link you've mentioned in your answer links to a page of the stripe docs explaining how to capture a payment intent with their checkout without mentioning a setup intent anywhere?

[remonh87]

You need to provide the customer and the ephemeral key to the payment sheet and it will be remembered . Paymentntent and serupintent works similar in this

[fulstadev]

@remonh87 thanks for this, I've managed to implement the flow, but one last question regarding this popped up. I absolutely must prevent the current payment methods from showing up in the initiated payment sheet, as well as the ability to edit and / or delete them. The payment sheet is exclusively used to add a new payment method. Modifying anything related to the payment methods must pass through our own API first, e.g. to prevent that a stored payment method is deleted that is still involved in pending payments / bookings.

I've now quickly chatted with a few developers from stripe, and they've confirmed that:

• the customer ephemeral key is, in all their 3 SDKs (native iOS, native Android, React Native) exclusively used in the context of a setup intent initiated for a payment sheet to precisely list their current payment methods + provide the possibility to directly edit and / or delete them.

• they confirmed that omitting the customer ephemeral key when setting up the setup intent for the payment sheet will not negatively impact the payment method storage + the mapping of the stored payment method to the provided customer in any way. It will simply lead to the payment sheet showing up not listing the current payment methods of the requesting client.

• They've also confirmed that flutter_stripe relies on stripe's native iOS + Android SDKs, and reuses the same native codebase as their react native SDK.

--> Can you confirm that, with the flutter_stripe package, omitting the customer ephemeral key in the above-described flow leads to the same behaviour, and no errors / problems in your SDK? And thus that omitting the customer ephemeral key in the flow above is the best way to omit current payment methods from the payment sheet, + the ability to directly edit / delete them? I've tested this on an iOS-Simulator and there it indeed did the trick, but I still must double-check this with you.