WhySoAsync-default-paymentmethods

[paper cairn]

Hi there!

You can use the card fingerprint to avoid duplicates being added to a customer: https://stripe.com/docs/api/payment_methods/object#payment_method_object-card-fingerprint

[opal inlet]

hello

[paper cairn]

Then if you want to just set a paymentmethod as the default on the customer to be used for their Subscriptions/Invoices you set the paymetmethod as the customer's invoice_settings.default_payment_method: https://stripe.com/docs/api/customers/update#update_customer-invoice_settings-default_payment_method

[opal inlet]

but what if i have 2 different subscriptions

and i wanna show cards for those subscriptions

or i cannot do that?

payment methods are only on customer

and you just set default one of them

on the subscription

[paper cairn]

You can set a paymentmethod to be used specifically for a Subscription if you prefer to not use the same paymentmethod for all of a customer's subscriptions.

See: https://stripe.com/docs/api/subscriptions/create#create_subscription-default_payment_method

[opal inlet]

Got it, i have 2 more questions

I will leave one card per subscription only

and he can change his card whenever he wants

[paper cairn]

Have you taken a look at the Customer Portal btw?

[opal inlet]

I need to do retry functionality, if card is expired he needs to change his card and retry payment

[opal inlet]

not yet, i wanted to create a custom one myself

[paper cairn]

Gotcha, the Cusotmer Portal will handle what you have been talking about for you, so you may want to look into using that.

[opal inlet]

But to do retry functionality i need to somehow create a subscription that will invoice in 1-2 minutes, and change the card to a one that will fail

then change card to a working card and retry somehow

[paper cairn]

So you want to use your own UI to update a customer's paymentmethod and retry payment when you encounter a failure?

[opal inlet]

yes, i'm almost finished, i have the retry functionality only to be done

[paper cairn]

https://stripe.com/docs/billing/subscriptions/overview#build-your-own-handling-for-recurring-charge-failures

Our docs there describe how you would go about handling this yourself

[opal inlet]

aa cool

one more thing

const activeSubscriptions = await stripe.subscriptions.list({
customer: customerDetails.data[0].id,
expand: ['data.latest_invoice.payment_intent.payment_method', 'data.default_payment_method']
});

i get the subscriptions

on /user/:id

to activate the functionalities for the user if the subscription is active

i don't wanna rely on my database and webhook, so i wanted to know if i can use the status from stripe directly

[paper cairn]

Why do you not want to rely on a Webhook?

This is really what you should use.

[opal inlet]

But if i get the status on each http call from stripe when users get their data

i get the active status of the subscription, without using my DB

but if the app has 10.000 users, it will be a lot of http requests, and i saw somewhere that stripe restricts that

[paper cairn]

Not exactly sure what you mean by this

Yes if you poll the API you will likely hit rate limits

Info here: https://stripe.com/docs/rate-limits

[opal inlet]

so i can't use
const activeSubscriptions = await stripe.subscriptions.list({
customer: customerDetails.data[0].id,
expand: ['data.latest_invoice.payment_intent.payment_method', 'data.default_payment_method']
});

to get the subscription data all the time?

i was hoping i could, i had some issues with updating in db from webhook in the past and i don't really trust that.. what happens if the server is down and the webhook sends a request to update the status of subscription and the server cannot process that?

[paper cairn]

I mean you can... but you likely will hit rate-limits as you scale and then that will cause problems.

[paper cairn]

Yeah you will want to protect against this and queue webhooks that aren't processed for some reason. There are also retries for 3 days: https://stripe.com/docs/webhooks/best-practices#retry-logic.

All in all Webhooks are a better way to go as opposed to polling the API if you are going to be working at scale

[opal inlet]

I understand, that's nice that are retries. I will change then to that, i don't wanna hit rate limits.

Thank you for the information !