#Gesundheit-card-setup

1 messages · Page 1 of 1 (latest)

runic charm
cedar coral
#

Hello again cough

runic charm
#

Hello again

cedar coral
#

Thanks for sticking with me for almost the entire week

#

my first question will be that i noticed stripe api provides ways to either

  • Update the billing information of the card (e.g. address, name, expiration date)
  • Or create a whole new card
#

i'm not sure what's the right question to ask this time. The situation is that we try to take the card that came with the invoice and set it as the default payment method of the customer, but that risks of updating something with the exact same information

#

Which doesn't sound right

#

so probably what i'm really asking for is an example implementation, or somewhere i can look into

runic charm
#

The fingerprint for the same card will always be the same if generated on the same account.

#

Are you unsure of the general flow or specific details on how you want to accomplish this?

cedar coral
runic charm
#

Maybe let's go a bit more general: what question is currently blocking you?

cedar coral
#

Got it! I'm generally just planning out how I'm going to implement the flow as described yesterday, which is below:

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.

#

We're using elements, thus rises some questions:

  1. How does Stripe know to use the customer's default payment method?
  2. As pointed out above, we're basically updating the default payment method every time an invoice is paid, so we need a way to fight the occasion when the payment method hasn't changed at all but is still being updated.
  3. I looked around and saw this other page:
    https://stripe.com/docs/payments/save-during-payment?platform=web
    And this one tells me that the payment method is automatically attached to a customer when the payment goes through, which contradicts the need to manually set it, as we discussed yesterday
#
  1. The biggest question of all is that Stripe does seem to recognize a customer's default payment method (through the dashboard), but there is no recommended way for me get / update that information.
opaque pebble
#

@cedar coral answering your qs now

#

you're using PaymentMethod objects right?

cedar coral
#

yep

#

as suggested in earlier conversations (i.e. don't use customer.default_source, use customer.invoice_settings.default_payment_method)
(EDIT: well i guess this has nothing to do with that)

opaque pebble
#

ok so a couple of things to clarify

#
  1. How does Stripe know to use the customer's default payment method?

PaymentMethods don't have a "default" concept except only for Invoices and Subscriptions

so customer.invoice_settings.default_payment_method works and makes a PaymentMethod the Customer's default only for Subs and Invoices

#

And this one tells me that the payment method is automatically attached to a customer when the payment goes through, which contradicts the need to manually set it, as we discussed yesterday

attach happens automatically if you pass setup_future_usage: on the payment.

#

The biggest question of all is that Stripe does seem to recognize a customer's default payment method (through the dashboard), but there is no recommended way for me get / update that information.

the only place you should look at for PaymentMethod default via the API is customer.invoice_settings.default_payment_method

#
  1. As pointed out above, we're basically updating the default payment method every time an invoice is paid, so we need a way to fight the occasion when the payment method hasn't changed at all but is still being updated.

not sure I fully understood what this scenario means

like how does it happen that:

when the payment method hasn't changed at all but is still being updated.
an example would help

cedar coral
opaque pebble
#

what Stripe endpoint do you use? PaymentIntents?

#

if PaymentIntents, they don't have a concept of a "default PaymentMethod"

cedar coral
# opaque pebble > 2) As pointed out above, we're basically updating the default payment method e...

so taken from the documentation:

if (stripeEvent.Type == "invoice.payment_succeeded") {
  var invoice = stripeEvent.Data.Object as Invoice;

  if(invoice.BillingReason == "subscription_create") {
    // Retrieve the payment intent used to pay the subscription
    var service = new PaymentIntentService();
    var paymentIntent = service.Get(invoice.PaymentIntentId);

    // Set the default payment method
    var options = new SubscriptionUpdateOptions // replace here with new CustomerUpdateOptions
    {
      DefaultPaymentMethod = paymentIntent.PaymentMethodId, // update invoice_settings.default_payment_method with the paymentMethodId
      // But we wouldn't know if the payment method is identical
    };
    var subscriptionService = new SubscriptionService();
    subscriptionService.Update(invoice.SubscriptionId, options);
  }
}
opaque pebble
#

like that doesn't exist, you have to specify a payment_method: in each PaymentIntent creation request

cedar coral
opaque pebble
#

As pointed out above, we're basically updating the default payment method every time an invoice is paid
so what that docs code snippet is doing is, whenever the first Invoice on a Subscription is paid, it is attaching the PaymentMethod that was used to pay that Invoice as the "default" on the Subscription.

occasion when the payment method hasn't changed at all but is still being updated.
that won't happen since that code is only doing the update of the PaymentMethod on the first Invoice, when your Subscription isn't associated with a PaymentMethod

so it is using the Invoice's PaymentMethod and saying "use this PaymentMethod on the Subscription going forward"

#

Is there anything else other than subs and invoices? (we're only selling digital products)
so to answer your question, you are using Subs and Invoices

if you were creating one off payments then you'd be using PaymentIntents which you are not

#

so customer.invoice_settings.default_payment_method is relevant in your case as it applies to Subs and Invoices which you are using

cedar coral
#

Ok.. i'm following.

#

So the code snippet only fires at the first invoice of a subscription (or at any one-off invoice). The duplicate update problem will still occur when a customer starts a new subscription, but the customer already has their customer.invoice_settings.default_payment_method set

opaque pebble
#

so what that snippet is doing is, it is not attaching the PaymentMethod to the Customer
(so not attaching to customer.invoice_settings.default_payment_method)

But instead is attaching to default_payment_method on the Subscription object.

So e.g. I can sign up with visa pm_123 on sub_1
and mastercard pm_456 on sub_2
on your Stripe account

and each Sub will be paid with a different card.

I think you don't want that?

instead you want pm_123 on customer.invoice_settings.default_payment_method
and later, when customer signs up on sub_2 with pm_456, you want this new PM as customer.invoice_settings.default_payment_method ??

cedar coral
#

yes, exactly!

opaque pebble
#

yeah so in that case, you would not update the Subscription's default_payment_method like that code snippet is doing

but instead update the Customer object and update the new PaymentMethod on the customer.invoice_settings.default_payment_method param

cedar coral
#

just that?

#

this means that if the customer does not change their card between sub_1 and sub_2, the code will still try to update customer.invoice_settings.default_payment_method with the same payment method id

#

i guess it's not a big problem

opaque pebble
#

correct, if they use the same card to sign up for sub_2, your code path would get a new PaymentMethod pm_456 that is the same card as pm_123 in reality

so your code needs to check the fingerprint on the 2 PaymentMethods and if it is the same, then leave it as is

the other approach is, that guide is for cases where your Customer doesn't have a PaymentMethod.

In your case, your Customer will have a customer.invoice_settings.default_payment_method

so when you create the Subscription, it will automatically use that default PaymentMethod so when this code is hit, it will try to replace pm_123 with pm_123 and that just works and there's no real net change on the Customers default PaymentMethod

cedar coral
#

Is there a way that we automatically apply pm_123 to sub_2?

opaque pebble
#

yeah if you create a Subscription on a Customer that has a customer.invoice_settings.default_payment_method , that default PaymentMethod on the Customer is used on that Subscription

cedar coral
#

ok, then the value being passed to the code snippet would be pm_123, instead of a new pm_456

opaque pebble
#

yep, pm_123 will just be used on that new Sub

cedar coral
#

cool! I'll try to implement what we went through

#

thanks a lot for the help! And sorry for being bad at asking (if I did)

opaque pebble
#

And sorry for being bad at asking
please no! not at all!

Happy to collaborate and talk through solutions, it is what we're here for! 🙂

cedar coral
#

wait, i have an off-topic question

#

is an invoice capable of including both subscription (recurring) and one-time (non-recurring) products at the same time?

#

just wanted to make sure

opaque pebble
#

yes you can create an Invoice on a one time Price

Prices are what you create off of Product, and define them as recurring or one time

and so you can create an Invoice on one time Prices

cedar coral
#

so an invoice can be a mixture of both -- which leads me to the question of what the value of invoice.billing_reason would be when that happens

opaque pebble
cedar coral
#

i understand that, but what happens when an invoice has items that are both subscription and one-off items?

opaque pebble
#

it can, so e.g. I can have an Invoice that was "$10 recurring, plus $5 one time late fee"

and the Prices will tell you which part was recurring vs not

cedar coral
#

but invoice.billing_reason represents the whole invoice, no?

#

I need that information to determine whether the invoice is for a new subscription, a one-off purchase, or either, or neither

karmic silo
#

Yeah invoice.billing_reason would represent the whole Invoice - if you need to know more specifics on whether all/some/none of the invoices items are tied to one-off purchases, you'd have to iterate through each line item and check them

cedar coral
#

invoice.billing_reason would represent the whole Invoice
So what happens when part of the invoice is a subscription and the other part is not?

karmic silo
#

If the invoice was generated as part of the natural renewal cycle for a subscription, then we consider it to be a subscription invoice. If it happens to also include one-off invoice items as well, we still consider it to be a subscription invoice since it was automatically created by us for a specific subscription

cedar coral
#

So, when a customer pays for a cart (hypothetical) that contains

  • a new subscription
  • a one-off product

the invoice will be counted as subscription_create?

karmic silo
#

Yup!