#ironbeard

1 messages · Page 1 of 1 (latest)

clever walrusBOT
tulip smelt
#

Also, wow it's super busy in here right now, so don't feel rushed to get to me

cloud field
#

Hey there

#

What you mentioned initially is the correct flow. If you want to wait for the customer to "confirm" their Sub then you should use payment_behavior: default_incomplete and then actually confirm the PaymentIntent once the customer "confirms".

tulip smelt
#

I'm doing multi-part forms for Checkout process, and this is what I have now:

  1. CreateUserForm (customers need user/pw since this is Saas)
  2. CreateContactForm (this gets contact details, like first/last name, etc). When this is POSTed, I (syncronously) create a Customer (with email from User and details from Contact), then when that call returns I create the Subscription (again, syncronously), so that's a bit of delay there, since I need the client secrets in the next form.
  3. Third form shows the Card Element, and the client secrets are hidden. When the user puts in their card info in, I use js to call confirmCardPayment.

What I'd like to do, to avoid wait times is

  1. On UserSignupForm POST, I create a background task that creates a Customer using just the email address
  2. On ContactSignupForm POST, I can update the Customer with first_name, etc.
  3. Third form is now just a PaymentMethod creation form, there's no subscription created yet or client secrets passed to the front end. Again, POSTing creates the PaymentMethod via stripe in a background process
  4. Now I display a "Confirm" page that shows their info and allows them to change anything (via a link back to a previous step in the process). In the GET request for this form, I was thinking I'd create the Subscription but in a way that doesn't charge ("default incomplete" I think)? I guess I'm wondering: when the user POSTs this form, what do I do on the backend to charge the card?
#

I think it looks like the answer to my question is "On the back end, get the PaymentIntent associated with the Subscription (that's in default_incomplete) and "confirm" it".

I'm assuming then that "confirm" is a (function) method on the PaymentMethod object in the Stripe API?

cloud field
#

Then you pass that to your backend

#

And confirm the PaymentIntent using that PaymentMethod when you are ready

cosmic lagoon
#

One drawback with this approach is, that there are many subscription entries in the Stripe console which are not completed yet and

tulip smelt
#

Yeah, I've implemented the create payment method on a portion of the website that allows customer to add new cards.

But now I'm wondering: what happens if the card has insufficient funds, etc

cloud field
#

Then the initial confirmation declines just like it would client-side and you need to show an error and ask for a new PaymentMethod

#

Overall I don't really think there is a lot of benefit to what you are trying to do.

#

I would just show the confirmation on that same page

#

And wait to submit the card details client-side until the customer has "confirmed"

tulip smelt
#

I guess my concern is that since I have to create a user and subscription between the "Contact Info" and "Payment Method" forms, those two calls to Stripe sometimes take 5-10 seconds

cosmic lagoon
#

Is there a possibility to create a client_secret without creating a subscription, then wait for the payment confirm and then create the subscription?

#

Sorry @tulip smelt , but I'm just asking because its really close to your question/approach

cloud field
#

Yeah I mean overall it is possible to just create a SetupIntent and then use that PaymentMethod when you create the Subscription later.

tulip smelt
#

Gotcha, I think I need to think through it a bit more, I was just hoping to find a way to offload some of the blocking that occurs when creating objects through the Stripe API.

Thanks for your help 🙂

cloud field
#

Sure thing

tulip smelt
#

@cloud field Could I create a PaymentMethod on step 3 using Card elements, and then on the "Confirm" page (step 4) pass the payment method ID and a client secret from a default_incomplete Subscription to a (hidden) card element and run confirmCardPayment when the user clicks the confirmation button? That way, if an error happened (either insufficient funds, or if they need extra verification), I could "unhide" the card element and let it take care of the situation?

cloud field
#

Not exactly. You wouldn't pass the PaymentMethod ID and client secret to the frontend in this case. You would just confirm on the backend in step 4, then if it fails you would pass the client_secret to the front end and mount the Card Element and show an error so that you can collect new card details and confirm again.

tulip smelt
#

Gotcha. Is there a reference document for the errors that would get sent when trying to confirm on the backend, that I would pass on to the front yet? I guess specifically with having to confirm 3D secure or something, I'm wondering how to get Card Elements to launch the pop up that it uses to take care of that, or if they'd just need to re-enter/submit that card number to trigger that process?

#

(now that it would have a client_secret).

Or, am I misunderstanding: the 3D secure check would happen when they create the payment method?

cloud field
#

Nope you aren't misunderstanding. If you confirm server-side and 3DS is required then the PaymentIntent will move to a status of requires_action. At that point you do pass the client_secret to the front end and you use handleNextAction (https://stripe.com/docs/js/payment_intents/handle_next_action) to display the 3DS modal on the front end.

tulip smelt
cloud field
#

Really?

#

I can load it just fine

#

Ah doh

#

I'm logged in

#

One sec

tulip smelt
#

Ah, gotcha 🙂

cloud field
#

Sorry about that 🙂

tulip smelt
#

No worries, you guys track so much info it's bound it happen 🙂

#

Okay, should be good for now. Take care!