dmitry-zip

[untold bridge]

You shouldn't be using that endpoint really

Is the saving done during a payment?

[wintry kiln]

We have various scenarios. Our customers can choose whether to make the payment immediately, or just save the card for later payments

I am using Stripe's .NET SDK to attach cards. And the SDK is making the calls to the /attach endpoint

[untold bridge]

You shouldn't be using that endpoint. You should be using:

• setup_future_usage with a Payment Intent: https://stripe.com/docs/payments/save-during-payment
• Setup Intents if there's no payment (just to save): https://stripe.com/docs/payments/save-and-reuse

The /attach endpoint is not recommended in most scenarios as it can't handle 3DS/auth flows (i.e. if the bank requests 3DS during the 'attach' call, it just errors)

[wintry kiln]

We do use SetupIntent to collect card details. Does this flow automatically attach the payment method to the customer?

[untold bridge]

If you're passing the customer parameter on Setup Intent creation, yes: https://stripe.com/docs/payments/save-and-reuse?platform=web&ui=elements#:~:text=Successful confirmation of the SetupIntent saves the resulting PaymentMethod ID (in result.setupIntent.payment_method) to the provided Customer.

[wintry kiln]

We do not pass the customer parameter to SetupIntent. In this case, how come the payment method ends up being attached to the customer without an explicit call to /attach from our system?

[untold bridge]

Do you have an example? It shouldn't

[wintry kiln]

I shared a screenshot above. Customer ID is cus_O8zQ4Z1CrDPVdk

[untold bridge]

You definitely made 2 API requests to attach 2 PMs to that Customer:

• https://dashboard.stripe.com/logs/req_kmwJec4xxm1qx0
• https://dashboard.stripe.com/logs/req_2RGF8Es4bN7zQy

[wintry kiln]

Ah, I see, so the POST /customers request also attaches the payment method if it's specified in the request body