#atlasdb

1 messages · Page 1 of 1 (latest)

pallid ermineBOT
#

Hello! We'll be with you shortly. 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.

eternal sluice
#

Afternoon Toby, thanks for chatting with me today

halcyon coral
eternal sluice
#

Okay cool we're on the same track, As I asked the question I looked into the stripejs docs and saw the methods for ConfiormPayment or ConfirmPayment Intent

#

Yup I think stripe.confirmSetup is what I'm looking for.

#

So just to be sure, the SetupIntent will confirm the payment (card) and save it as a payment source for the customer?

halcyon coral
#

Nope, the Setup Intent does not do anything to process a payment, it only works on setting up a new Payment Method.

#

Oh, wait, maybe that is what you said and I misread it?

eternal sluice
#

lol yes i think so, so it will in fact save it to the customer?

#

So this means after i confirm the set up intent i can proceed to update a subscription, assuming the ConfirmSetupIntent registered the Payment Source to the customer

halcyon coral
#

The Setup Intent will save the Payment Method (it will not create a Source) to the Customer.

eternal sluice
#

Okay I see, and sorry for my confusion, but what's the difference between a payment source and a payment method?

halcyon coral
#

They do the same thing, just a Source is an older version whereas Payment Methods are newer and more robust.

Payment Methods: https://stripe.com/docs/api/payment_methods
vs
Sources: https://stripe.com/docs/api/sources

It may have already been what you were referring to, I just wanted to make sure we were using the right terms so what we discuss will align with what you see in our documentation.

Payment Methods | Stripe API Reference

Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.

Sources | Stripe API Reference

Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.

eternal sluice
#

Oh okay, yes so I think we're on the same page. So Confirm Setup simply saved the payment method, got it.

So logical next steps would be to create a preview invoice, then on user confirmation, I can call my api to update the subscription with a new price, and it should be charged to the payment element? Or should will I have to define the payment method each time I update a user's subscription?

halcyon coral
#

It won't be charged to the Payment Element. Do you want the newly created Payment Method to be the new default? And if so, where are you storing those default payment methods, at the Customer level or the Subscription object level?

eternal sluice
#

Yes, i would like the new payment to be default, and I'm assuming I will be saving it on the User level... But correct me if that is misguided

halcyon coral
#

You can save it at either the Customer object level:
https://stripe.com/docs/api/customers/object#customer_object-invoice_settings-default_payment_method
or at the Subscription object level:
https://stripe.com/docs/api/subscriptions/object#subscription_object-default_payment_method

I'm not sure how you've chosen to handle that. The Setup Intent won't automatically set the newly created Payment Method as the default payment method at either level, you will need to explicitly do that, but it also may be better to wait and make sure the Payment Method can complete a payment before setting it as the default.

pallid ermineBOT
eternal sluice
#

I'm not sure how to handle that either lol Thats the sort of guidance I'm looking for. So right now the logical order of updating the subscription sounds like this:

  1. Customer Selects new Price

  2. I Create a Setup Intent (Card Only) on the back end, returns a clientSecret to the Client, render Payment Element on page.

  3. User fills out payment method and submits, I send element to API to ConfirmSetupIntent

3a) I also use stripe.invoices.retrieveUpcoming to generate an invoice preview and return back to the front end.

From here on out, im not sure exactly how to proceed

  1. Client is shown Preview Invoice and click Finalize Payment Button to finalize everything.

  2. I hit up my Update Subscription Endpoint...

wind nymph
#

Hi, stepping in and catching up here

eternal sluice
#

Afternoon @wind nymph thanks for joining

wind nymph
#

If you have not heard of our Customer Portal, I'd also look there: https://stripe.com/docs/no-code/customer-portal. This is a UI where your customers can update their subscription on their end and you can also configure it to change collect new payment method details.

eternal sluice
#

Yeah ive used them before in previous projects, but we found many customers having issues leaving the site to manage billing. So we are trying to implement an integrated solution

wind nymph
#

However, if you're looking to hand this on your end, after you collect the payment method details using the SetupIntent, you choose to either save it to the customer or on the subscription level. That part is really up to you. My teammate provided how you can set here 'You can save it at either the Customer object level:
https://stripe.com/docs/api/customers/object#customer_object-invoice_settings-default_payment_method
or at the Subscription object level:
https://stripe.com/docs/api/subscriptions/object#subscription_object-default_payment_method'

eternal sluice
#

Okay i think im starting to understand

#

So after step 4, when a user confirms the invoice and I make a call to the Update Subscription Endpoint, I'm sending over three things: New Price ID, Payment Method ID, and Customer ID.

On the endpoint I will handle

  1. (If I want to set up a default Payment) I Update the User Object with new Payment ID then
  2. Updating the subscription with new Price, and payment method
#

Please feel free to tell me if im wrong in any concept or thought process, I really want to undrstand all this, I want to think the way stripe thinks

wind nymph
#

Once they've confirmed it, you can make a server side request to update the subscription with the new line items and the payment method id collected. There is not customer id parameter for that method, https://stripe.com/docs/api/subscriptions/update

eternal sluice
#

Okay this makes sense

#

In terms of testing, If i input the same 42424242 card number will the payment method be overwritten? or will a new card be created per each SetupIntent?

wind nymph
#

A new payment medhod id will be created each time you go through the SetupIntent flow.

#

I highly recommend that you test all of these to confirm that this is the exact flow you'd like.

eternal sluice
#

So I account for a user leaving the payment process halfway through, by storing the setup_id temporarily, so in the case of pre-mature cancelation, we call cancelIntent any time the user pre-maturely exits the payment pipeline, what affect does this have on PaymentMethods created in the process?

wind nymph
#

If they leave your site before you make the confirm call, there is no payment method. I think testing these from end to end will be helpful

eternal sluice
#

Sounds like a plan, I will try implementing this new pipeline and hopefully I can report back before this thread is closed. Many thanks @halcyon coral and @wind nymph

#

So since we're in the realms of the Payment Element,

  1. What is the best way to handle the UI when trying to ask the user to save this payment element as default? Do I include my own check box for example and handle it manually, or is there an option that handles this

  2. Is there an element or recommended workflow to list or render previous payment elements as an option, rather than entering a new payment each time?

wind nymph
#

I think testing the SetupIntent as mentioned above will help answer some of these questions.

eternal sluice
#

Yup, I'm testing it out now and can receive a successful response when calling the Setup Confirmation, but now these question came up while testing lol

wind nymph
#

I'm helping someone else on this channel as well. I'll be back to answer your follow up questions here.

eternal sluice
#

Sure no rush, I appriciate any and all help, I'll be here when you have a chance

wind nymph
#
  1. What is the best way to handle the UI when trying to ask the user to save this payment element as default? Do I include my own check box for example and handle it manually, or is there an option that handles this

We talk a bit about this here, https://stripe.com/docs/payments/save-and-reuse?platform=web&ui=elements on the compliance side of things. However, we can't comment on the complaince issues on this channel.

  1. Is there an element or recommended workflow to list or render previous payment elements as an option, rather than entering a new payment each time?

What do you mean by this? Can you clarify?

pallid ermineBOT
eternal sluice
#

Hey @solemn depot thanks for joining

eternal sluice
# wind nymph 1) What is the best way to handle the UI when trying to ask the user to save thi...

So 1 sounds good, i'll take a look at the docs, for 2) what im trying to say is do we have a stripe Element to render previous payment methods? For example a user who has previously submitted a payment method before, rather than asking them to add a new payment each time, (ie. check if customer has previous payments, if so, show them a list of their previous payment methods rather than the payment element) is there an element we can use to render this list, or would this need to be fleshed out manually.

solemn depot
#

Right now we don't offer any stripe.js elements that automatically display the previously saved payment methods of a customer - you can write into support (https://support.stripe.com/contact) and see if there are any beta/private features taht support this, but for now there isn't any public feature that supports this

#

You'd either have to built that UI yourself, or redirect your customer to the customer portal to see them all in a stripe-hosted URL