#ironbeard-testing billing

1 messages ยท Page 1 of 1 (latest)

glossy needle
#

๐Ÿ‘‹ happy to help

quiet charm
#

Sure, one second

#

So let's see. Customer is update/created with req_WxdNnU6AJhjX8a, then Subscription updated/created with req_uhziwQYlHREykI, then PaymentMethod updated/created with req_FtVltKetfBch2i

glossy needle
#

I'll take a look

quiet charm
#

thanks ๐Ÿ™‚

glossy needle
#

you have set the invoice_settings.default_payment_method for the customer to be the 4242... card. This is why you're not getting any declines

quiet charm
#

Oh, so even though the card that was input in the form should decline, Stripe is using the default PM from a previous time?

#

that makes sense. thanks ๐Ÿ™‚

glossy needle
#

let me know if you need any more help

quiet charm
#

I think I should be good. So if I want to change it to not use the default payment method, when would I do that?

glossy needle
#

you need to update the customer and set the invoice_settings.default_payment_method to the new payment method

#

please note that you should be using this card instead 4000000000000341

#

Decline after attaching

#

you can use the magic string pm_card_chargeCustomerFail which will do the trick

quiet charm
#

Gotcha, and I would do that before creating the Subscription? or after? Sorry, lots going on in my head right now.

I get the client_secret to pass to the front end after updating/creating the Subscription

glossy needle
#

oh wait

#

are you using the latest_invoice.payment_intent.client_secret to pay the Subscription?

quiet charm
#

Oh, yes.

#

Sorry should have specified that. I remembered I was doing something kind of different than usual

#

So, I guess the latest_invoice will be using the default PM, not the one I'm entering in the Card Element?

glossy needle
#

I think so, but I'm trying to dig a little deeper

#

what I would suggest to do is to start fresh

#

with 2 new customers

#

and try to set the invoice_settings.default_payment_method for each

#

one failing and one succeeding

#

and testing

quiet charm
#

Gotcha, so create two new users, one using e.g., 4242 4242 4242 4242 and the other using 4000 0000 0000 0341?

glossy needle
#

yes

#

and if you want we can discuss the flow you're trying to implement

quiet charm
#

and then try to update/add to the 4242... subscripting and use the ...0341 card?

glossy needle
#

for your subscription

#

yes you can create the subscriptions and they will automatically succeed for the first and fail for the second

quiet charm
#

Gotcha. Gonna try that and will see what happens. Thanks ๐Ÿ™‚

quiet charm
#

When does PaymentMethod attaching happen? Not sure if this is an obvious question, or something that changes a lot depending on my flow

#

A PaymentIntent can have a Customer and a PaymentMethod (which can be null). If I PaymentMethod is attached to a Customer, does it have to have a PaymentIntent?

heady ice
#

๐Ÿ‘‹ stepping in here as tarzan had to step away.

quiet charm
#

no worries ๐Ÿ™‚

#

no rush here

heady ice
quiet charm
#

So I believe all the PaymentIntents I'm creating have 'off_session' has setup_future_usage

#

I'm using the PaymentMethod.attach method

heady ice
#

Ah you are building a subscription flow

quiet charm
#

Correct, sorry

#

Does Attaching a PaymentMethod to a Customer make it the default PM?

heady ice
#

When you create the Subscription you set that to on_subscription and then when you confirm the initial PaymentIntent for the Subscription the paymentmethod will be automatically attached to the customer and set as the default for the Sub

quiet charm
#

Will that work if I'm updating a Subscription? in my flow, every user can only have on Subscription (with multiple items) and if they go through the payment process again at a later date (and use a new card), then I'm updating the subscription with new items

#

and would want to use the new card, that was input in the Card element

heady ice
quiet charm
#

Gotcha, I'll look into those docs a bit more, thanks ๐Ÿ™‚

#

Would I need to possibly update the python lib to use this?

heady ice
#

Yes you likely need the latest version

#

As the param was just added about a month ago

quiet charm
#

cool cool, wasn't sure if it just passed through, will look for an update.

#

Thanks for all your help ๐Ÿ™‚

heady ice
#

Of course!

quiet charm
#

Okay, I think I've almost figured it all out ๐Ÿ™‚

  1. Create/update a Subscription (Customer + items (Prices)), also pass through payment_setting={'save_default_payment_method': 'on_subscription'}
  2. Retrieve the Subscription with expand=['latest_invoice.payment_intent.payment_method']
  3. This gives me payment_intent['client_secret'] which I return to the front end and then use Stripe.JS's stripe.confirmCardPayment

So my question lies between 2 and 3: How do I detect the declined card? I still get a client_secret with the insufficient_funds card, right? I'm under the impression that I should be able to determine if the card failed before stripe.confirmCardPayment in the JS, is this right or wrong?

heady ice
#

Nope, the decline will be synchronous when you call stripe.confirmCardPayment

#

So you would prompt for a different card if they hit that decline

quiet charm
#

Gotcha. Is the decline something that Stripe Elements should be handling, in the same way that it handles bad exp dates?

heady ice
#

Yep. The promise will resolve with a result.error which you then display the message to the customer.