#Nick - Testing Payment Methods
1 messages ยท Page 1 of 1 (latest)
Hi!
Can you share how you are testing this?
Sure! req_geCIQ6TEONaR4v
I'm trying to apply it as the default payment method on the subscription level rather than the customer default
So wondering if it only works at the customer level
When you are specifying the default payment method on the Subscription, the payment method in question must belong to the Customer
Makes sense - is there any way to do that without making it the default payment method for the entire customer?
I know it's possible with real setupintents and stuff - but wondering in the context of a test clock with the in-built payment method ID's
I just create test Customers that have test cards as their default payment methods since the Test Clocks are tied to Customer objects
Yeah I'm just trying to line it up with exactly how we have it in production - which doesn't have customer level default payment methods.
Context, I'm trying to test re-attempting-charge of old delinquent invoices. This is a challenge for us because we don't use the customer level default (so we need to go back and tell the old invoice to use the new subscription default rather than what it was set to originally)
So basically our flow will be:
Sign up for a subscription
Upgrade to a paid one with a credit card
Credit card fails for 1-3 months worth of invoices
User adds a new credit card, which updates the subscription level default payment method
We attempt to recharge the delinquent invoices from months 1-3 // this is the part I'm trying to test
Okay that makes sense.
But the request you sent was to create a subscription. Are you setting up the failing sub at this point?
Yeah so I'm trying to create the subscription, and then attach the payment method to the subscription without it becoming the customer default which doesn't seem possible with the test clocks, because you have to attach it to the customer when you create, which automatically sets it as default
Unless there's a way to update the customer after the fact? I just don't see anything here: https://stripe.com/docs/api/customers/update wrt payment method that doesn't mention default
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
No there really isn't. But my question is, what about the billing process do you think differs significantly if the method is the default or not?
From what I've seen, when the invoice re-attempts to charge, it tries against the customer default - so if the customer level default has changed it "just works"
What's been happening for us is because the invoice was generated against a specific subscription level payment method, that invoice still tries to charge the payment method it was generated from
So part of this was also trying to prove out my understanding of how this works
Okay, that does make sense.
I've just found this endpoint: https://stripe.com/docs/api/invoices/pay
Not sure why, but whoever was helping me here about this didn't mention the endpoint. I think this is exactly what I need
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
So I won't need the test clocks to prove out anything. Thanks for your help!
Okay...wait yeah I'm sorry I didn't get there sooner.
That's so much more direct to what you're trying to do
Also FWIW if you are adding payment methods using Setup Intents I don't think they need to be specified as the default for that customer.
https://stripe.com/docs/api/setup_intents/create
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
Yeah we're doing the setupintents that way in prod, just was trying to also do that programmatically (ie, without card entry) through the test clocks locally. But the invoice pay is a lot more direct so that'll suffice
It's kind of buried so someone probably just forgot about it ๐
But you can use SetupIntents programmatically. Just pass the actual payment_method ID parameter. No front-end required.
And that'll work with the pm_card_visa shorthand?
Just tested it
stripe.SetupIntent.create(customer="cus_Lxxxxxxyg", payment_method=
...: "pm_card_visa")
Out[4]:
<SetupIntent setup_intent id=seti_1KxxxxxxxxxxxxxK1D at 0x1073f9ae0> JSON: {
"application": null,
"cancellation_reason": null,
"client_secret": "seti_1Kvxxxxxxxxx1D_secret_Lcexxxxxxxbgj",
"created": 1651598275,
"customer": "cus_Lcxyg",xxxxx
"description": null,
"id": "seti_1KvxxxxxxxbK1D",
"last_setup_error": null,
"latest_attempt": null,
"livemode": false,
"mandate": null,
"metadata": {},
"next_action": null,
"object": "setup_intent",
"on_behalf_of": null,
"payment_method": "pm_1KvxFD",
"payment_method_options": {
"card": {
"mandate_options": null,
"request_three_d_secure": "automatic"
}
},
"payment_method_types": [
"card"
],
"single_use_mandate": null,
"status": "requires_confirmation",
"usage": "off_session"
}