#thiago_subscription-source

1 messages ยท Page 1 of 1 (latest)

hollow epochBOT
#

๐Ÿ‘‹ 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/1438219273024704634

๐Ÿ“ Have more to share? Add more details, code, screenshots, videos, etc. below.

bold python
#

thiago_subscription-source

#

๐Ÿ‘‹ Happy to help! It depends a bit on what you call a Source (there are a few objects in our API that match that description). Is this a Source with the id src_123 or a Card with the id card_123?
And also if it's a Source what is its type?

If you have a concrete example PaymentIntent id or Subscription id that also would help

fallow kernel
#

@bold python Hi koopajah, thanks for the help. It is the source that starts with src_123, i will check some of them to see of which type they are and i'll let you know.

bold python
#

If you can share an id that would be much easier I think to help guide you

fallow kernel
#

I am asking my manager for access since i don't have direct access to the Stripe Account. Which Id would be better? A Payment Intent Id or the Id of the Source object?

We don't use the Subscription API for the integration

#

For now i have a Source object Id. src_1QpOMHCUe03sH8IoAJyft0pp

bold python
#

Okay so this is a Source with type card. So those are compatible with our newer PaymentMethod APIs (like legacy Card objects with the id card_123'. When we built the newer API we made it forward compatible so you didn't have to re-collect all card details again.

#

So what you can simply do is pass payment_method: 'src_1234' for those and it "just works".
If you are using Subscriptions then my guess is that you have either the Subscription or the Customer with default_source: 'src_123' set. What you can simply do is set either default_payment_method on the Subscription or invoice_settings[default_payment_method] on the Customer and it will magically switch to treating that object as a real PaymentMethod.

This is really neat (but I'm biased, I helped design a lot of this) but it can be cryptic at first until you start playing with the API to get a feel for this. Does that make sense?

fallow kernel
#

That is great, which types wouldn't allow me to do that? I need to check a few hundred of them to make sure they're all compatible

#

Yes it makes sense and it's clear.

bold python
#

In theory we have deprecated every single Source types except card over the past 3 years. As of a few months ago no one is allowed to use any Source that aren't a card.
So you likely either only have card ones or you got lots of emails about the deprecation

fallow kernel
#

You just took a huge weight off my shoulders, thank you so much.

bold python
#

happy to help!

#

If you have specific questions let me know. You can test all of this in Test mode easily if you have access to your API keys (don't share those though please)

fallow kernel
#

Great, i do have the API keys, but can i test using the same customer and source ids from the live environment?

bold python
#

You can but I highly discourage this, testing in Live mode is a bad idea.
I recommend testing in Test mode either on your account with Test API keys or in a sandbox

fallow kernel
#

Ok! I believe that is all. Thanks again for your help