ironbeard_api

[trail crescent]

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1400927324219768882

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

• ironbeard_api, 6 days ago, 13 messages

[idle steppe]

The reason I ask this is bc this flow seems to make sense to me as a way to add in a Confirmation Step, but the docs mentionm Setup Intents, etc etc, and I'm not familiar with those

[narrow ember]

SetupIntents are used to save payment methods for future use. This will create the PaymentMethod in a single flow so you don't have to send a call to create the Payment Method [0].

[0] https://docs.stripe.com/api/setup_intents

We go into more detail here [0]

[0] https://docs.stripe.com/payments/save-and-reuse

[idle steppe]

Can you explain your second sentence a little? When I use stripe.createPaymentMethod, that's just a single call too, right? And I can send the id to my back end, and on the next step pass both the client secret and the payment method id to the front end and use stripe.confirmCardPayment in the front end?

[narrow ember]

I mean when the customer is making payment, you'll need to create an Intent. In this case, it will make sense to just use the PaymentInent and pass setup_future_usage [0]

[0] https://docs.stripe.com/recurring-payments?lang=node#use-paymentintents

Does that make sense?

I was trying to explain the purpose of SetupIntents. Apologies if that confused you a bit.

[idle steppe]

But can't I get the payment intent by creating the subscription?

In my mind I see it like this:

Customer enters details into card element, I call stripe.createPaymentMethod and return some values to the back end (last4, zip, and payment method id) with a POST.

The POST redirects to a GET for the "Confirm" page. During this GET, I create a Subscription on my backend and have it expand latest_invoice.payment_intent. Then, I send that paymment intent's client secret to the front end along with the pm id. Then, we the user clicks my "Submit Payment" button, I call stripe.confirmCardPayent(<client_secret>, <pm_id>).

[narrow ember]

Gotcha. I missed that part from earlier. I believe your approach makes sense given what you're trying to achieve.

I'll you'll need to do is pass

var card = elements.create('card', { options });

const {paymentMethod, error} = await stripe.createPaymentMethod({
      type: 'card',
      card: card
    });

I recommend tesing this flow out in the Sandbox or Test Mode.

[idle steppe]

Right. So I do that on the step where people create the payment method (e.g. /checkout/payment/) which is step 2 after creating an account (/checkout/account/) on our website. Then I can create the payment intent by creating the subscription when they request (/checkout/confirm/), and at this point both the paymentintent ID and the payment method ID are in the front end, so when the visitor clicks "Submit Payment" I can call stripe.confirmCardPayment(payment_intent's client_secret, payment_method's id)

Okay, just wanted to make sure there's not some big issue with this flow

[narrow ember]

Nope, there's no issue with the flow.

[idle steppe]

I guess though, I want this payment method to be the default one, but I still want the subscription to be in "default_incomplete" in order to not charge the card immediately

[narrow ember]

default_incomplete shouldn't impact setting the PaymentMethod as default.

[idle steppe]

So on the backend can I do the following (in the Python lib)

strip.Subscription.create(
  items=[...],
  customer='customer-id',
  cancel_at_period_end=False,
  payment_behavior='default_incomplete',
  payment_settings={'save_default_payment_method': 'on_subscription'},
  default_payment_method='pm_id',
)

that is, will specifying both default_payment_method and payment_behavior='default_incomplete' on Subscription creation prevenmt the invoice from being charged immediately?

[narrow ember]

You can do one or the other, you don't have to do both default_payment_method and payment_behavior='default_incomplete'.

[idle steppe]

Setting payment_method='default_incomplete' is what allows me to create the Subscription in an incomplete status, right? But if I also want to set up the default payment method for the subscription, why wouldn

't I pass it as default_payment_method?

[narrow ember]

Sorry, I meant payment_settings={'save_default_payment_method': 'on_subscription'}, not payment_behavior='default_incomplete'

Friday brain

[idle steppe]

Oh, I could do one or the other of

  payment_settings={'save_default_payment_method': 'on_subscription'},
  default_payment_method='pm_id',

?

[narrow ember]

Yes

[idle steppe]

Final question: so will payment_settings={'save_default_payment_method': 'on_subscription'}, always update the Subscription's default payment method with the one used to pay the invoice / payment intent?

[narrow ember]

Yes, we'll use the PaymentMethod specified as the default.

[idle steppe]

thanks! Have a great weekend!