#Gesundheit-card-setup

1 messages · Page 1 of 1 (latest)

languid helm
uncut bridge
#

Hello again

languid helm
#

Was about to say the same thing!

uncut bridge
#

Glad that you joined me again, then I wouldn't have to repeat the question again haha

indigo fox
#

Note that this only applies to invoices/subscriptions, not one-time payment intents

#

you need to always provide an explicit payment method for one time payments

uncut bridge
languid helm
#

You can use it for both, just collecting it once

#

One moment let me look through that doc again

uncut bridge
#

Thanks! Yeah. I'm not sure if the method described in the doc saves the payment method to the subscription or to the user.

#

If you would allow me, let me describe the use case we're trying to achieve here

languid helm
#

It does not, you can modify the webhook the doc has for invoice.payment_succeeded to accomplish that though

#

Yes please, that will be very helpful

uncut bridge
#

Cool! So basically when a new customer without a card on file decides to purchase something (whether it's recurring (i.e. subscription) or not)

  • The user provides their card
  • We save their card
  • We use that card to pay for their purchase

Later on, when the customer wants to purchase something else, we use the card-on-file to make that purchase.
When the billing period of a subscription renews, we automatically use that card to pay as well.

The user should always have one and only one card on file. They should be able to modify / delete their card as well.

#

Hopefully that's specific enough lol

#

So yeah, judging by the use case, I would imagine that I have to set and use customer.invoice_settings.default_payment_method every time

languid helm
#

Which I am sure you knew just typing it out

uncut bridge
# 
// Set the default payment method
    var options = new SubscriptionUpdateOptions <--- new CustomerUpdateOptions() instead?
    {
      DefaultPaymentMethod = paymentIntent.PaymentMethodId, <--- something something default payment method update instead
    };
    var subscriptionService = new SubscriptionService();
    subscriptionService.Update(invoice.SubscriptionId, options);
#

something along the lines as above perhaps?

uncut bridge
languid helm
#

That's thinking like an engineer! Yeah that would make sense to just check if the default payment method has been set, let me look at modifying that object though

#

And yes that code would work, just keep in mind calling the Attach method first, you need to attach a PaymentMethod to be able to set it as the default

uncut bridge
# languid helm We don't have a built in way to limit them to one PaymentMethod so you will like...

On second thought I feel like you're absolutely right on that one. I imagine that attaching a payment method just adds a payment method to the list, query-able through the List Payment Methods API.
Of course, it's not going to cause a lot of problems since I will only be accessing the default_payment_method property anyway; but as time goes on a customer may have changed a dozen of different cards and that will leave the list growing without notice.
Just speculation haha, dunno if i'm right

#

I guess for the sake of housekeeping it's better to keep that list limited to one?

languid helm
#

If that is the behavior that you want then yes. You could make either work to keep the customer having only one card

#

For example checking if the default is null or not, if it is not detach the card, then attach and default the new one

#

And just to make sure we are on the page with some terminology, when you say "access and modify invoice_settings.default_payment_method", that is something you can do on that field on the customer but the actual PaymentMethod object it refers to would need to be detached to remove it. It can't be modified to refer to a new card as far as I am aware

uncut bridge
#

Got it. I need to think this through

#

A lot of steps included haha.

languid helm
#

Of course, and you know where to go with any questions!

uncut bridge
#

thanks!