#redpanda-subscriptions

1 messages · Page 1 of 1 (latest)

slate fjord
#

@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.

sterile current
#
  1. From what I saw confirmCardPayment will create a new payment method automatically. So I basically need two plan selections for never-subscribed and existing customers?

  2. The first link is setting the payment method per-subscription and the second globally for the customer. Is this correct?

slate fjord
#

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)

sterile current
slate fjord
#

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

sterile current
#

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!

slate fjord
#

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

sterile current
slate fjord
#

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!