#AbelB

1 messages · Page 1 of 1 (latest)

untold sparrowBOT
thick badger
#

Hi! Let me help you with this.

lone wharf
#

default_payment_method takes precedence over default_source if it's set

#

if it is deprecated what is the alternative?
you should generally be using modern integrations that create PaymentMethods pm_xxx and set the default_payment_method fields on objects , for example our Checkout integrations for Subscriptions do that.

Or do we need to just always check both properties and pick one?
if you're using a mix of legacy and PaymentMethods then you need to check both to know what will be charged. The order Stripe uses is to look for default_payment_method first and if not set, look at default_sources

And: since we use Stripe website to create test customer
not sure what that means, I need to see some examples like a specific customer ID cus_xxx about how you create customers and integrate in general.

spark wraith
#

Thanks, this is insightful.

Let me confer with the people that actually create the users in Stripe. AFAIK, there are only two ways we use: Stripe Elements (user must supply the payment methods), or by hand, the latter mostly for test users.

We don't want to manage payment details ourselves atm, due to regulatory requirements for storing / maintaining CC data and the like. We prefer Stripe to be in control of that.

lone wharf
#

yep I mean that's always the case, you never really touch the card details

#

it's more about how you integrate and what actual APIs you use to collect the information and create the objects, ignoring test users you're manually creating in the Stripe Dashboard since that's not representative.

spark wraith
#

We use the latest NuGet package of Stripe.NET. If there's some setting we should use that can automate the above (i.e., we always request invoice settings, and Stripe returns the proper one from default source and invoice settings), I'd very much like to know.

#

Is there some way in the Stripe Dashboard I can see which of the two settings is used?

lone wharf
lone wharf
#

@spark wraith any change you could share an example cus_xxx so I can have a quick look to make sure we're understanding your integration correctly?

spark wraith
#

Yes, ID is cus_LqppZDwxVCwof4, in the Test Stripe

#

I just noticed there's only one way to set default in the Stripe frontend, which is to click the menu item Set Default in the payment method list.

#

So, it seems that this leads to Stripe storing it under the legacy format in default_source.

lone wharf
#

ah right

#

overall it's hard to advise you without complete context on what your actual payment flows are and how you currently integrate them, for example I see you use Invoices a lot as well, so I need to know how your payment pages for those invoices is coded and how you get the customer's card details on it

spark wraith
#

But... this user I just created by hand for testing from the Stripe frontend. And the API we use is purely programmatic for reading this data, not setting it, and it goes through the Stripe.NET api.

lone wharf
spark wraith
#

Does that library have a default of using 1.0 and we should override that perhaps?

lone wharf
#

no it's nothing like that whatsoever

lone wharf
spark wraith
#

ah, that explains a lot!

lone wharf
#

if your own actual code that you use for production payments uses PaymentMethods and such and doesn't have this problem, then the better approach for testing would be to use that code in test mode instead of the Stripe dashboard

spark wraith
#

Unfortunately, in production, we use both approaches: by hand through the dashboard and semi-programmatically through Stripe Elements.

lone wharf
#

yeah makes sense

#

then unfortunately you're being impacted by our bad dashboard that is still not updated to use PaymentMethods a few years after they are the default

#

your only option is to build custom logic like you mention in your most recent GH comment

spark wraith
#

Sometimes we have a customer on the phone and we need to create / update something in Stripe by hand. Most of the times, it is Stripe Elements.

But, suppose:

  1. create customer through Elements from an invoice payment
lone wharf
#

if invoice_settings.default_payment_method is set, that will be charged; if it's not, then default_source will be charged

spark wraith
#
  1. he or she adds a payment method
  2. we change the default for them on their request in the dashboard

During 1) and 2) we have inv settings, and after 3) we have default_source, correct?

#

if invoice_settings.default_payment_method is set, that will be charged; if it's not, then default_source will be charged

Check, gotcha. We'll always query both then.

lone wharf
#

possibly, I can't say without information on what code you use for 1 and 2, but it's plausible sure

#

either way you solve this on the read path the same way, you have to look at both fields

spark wraith
#

unf I also don't know, it's the FE team and I'm backoffice. They'll get back to me though. All I know is they use Elements, but they use the REST API from Vue.js to create a customer first. I don't know about what api version or what exact code they use there.

#

But bottom line is: just check for both settings, always, when reading, to validate what sort of payment method will be used for charging.

lone wharf
#

the order of precedence for the card we charge for a given invoice looks like this, the idea is we'd look at these in order so that's the kind of logic you need to encode

  • invoice.default_payment_method
  • invoice.default_source
  • subscription.default_payment_method
  • subscription.default_source
  • customer.invoice_settings.default_payment_method
  • customer.default_source
lone wharf
spark wraith
#

That above list is going to be very useful. Thanks.

lone wharf
#

great! I'm going to run but my colleagues can help with follow up questions.

spark wraith
#

I think I'm good. We just need to mirror Stripe's approach here.