#redpanda-subscriptions
1 messages · Page 1 of 1 (latest)
@sterile current
1/ yes you'd have to list their existing subscriptions(or store info in a local database) and enforce not creating a new on in your business logic.
2/ You'd have to manually list the customer's payment methods and check if the fingerprint is the same and not add the new card if it is (https://stripe.com/docs/api/payment_methods/object#payment_method_object-card-fingerprint)
3/ https://stripe.com/docs/payments/checkout/subscriptions/update-payment-details is the most complete guide but it's for Checkout. In any case it's just a matter of saving the relevant PaymentMethod to a customer(per the docs of the specific method you're looking at) and then setting either https://stripe.com/docs/api/subscriptions/update#update_subscription-default_payment_method or https://stripe.com/docs/api/customers/update#update_customer-invoice_settings-default_payment_method to point to it.
-
From what I saw
confirmCardPaymentwill create a new payment method automatically. So I basically need two plan selections for never-subscribed and existing customers? -
The first link is setting the payment method per-subscription and the second globally for the customer. Is this correct?
yeah the problem is that 2/ is really hard to implement
since in our default integrations you don't get to see the details of the payment method before it's used, so you have to change things(and we don't document how to)
https://github.com/stripe/stripe-payments-demo/commit/dffb17f7d6bbbf40268c181d399423c2567ed693. I just found this commit, but it's from 2019. Would this still be a good solution?
what it boils down to is you need to split things, so call https://stripe.com/docs/js/payment_methods/create_payment_method first to create the PaymentMethod from the customer's input, then send ti your backend server, which calls https://stripe.com/docs/api/payment_methods/retrieve (since you can only see the fingerprint from backend API calls), check if it's a duplicate, and if not, return back to the frontend and call https://stripe.com/docs/js/payment_intents/confirm_card_payment#stripe_confirm_card_payment-existing instead
yeah something like that commit helps, but to be clear that is some kind of post-facto action to detach already-attached methods, it doesn't prevent them from being added I believe
Yeah I prefer your suggested solution of checking the fingerprints before creating a new payment method and then handling the payment with the payment method id.
That's all I have for now, thanks for the quick response. Much appreciated!
also yes 3/ your understanding is correct
if subscription[default_payment_method] is set it is charged for recurring payments, if it's not, then we look at customer[invoice_settings[default_payment_method]] instead
So if I want to add more subscriptions down the line and don't want to deal with handling payments per-subscriptions it would be better to switch out https://stripe.com/docs/billing/subscriptions/elements#default-payment-method with an implementation that sets the customer invoice_setting's default_payment_method?
that is one option yep, if you think you will have Customers with multiple Subscriptions and don't want them all to maintain their own default and set it globally instead , it's up to you
we go with setting it on the Subscription in the docs as it's more defined and prevents surprises like new subscriptions charging a method you didn't expect, but it's not a problem to do it either way!