#Jonah Librach
pure meteor
What are you trying to do in the broader sense?
pure meteor
Test your flows for handling webhook events that are emitted in this case?
clear forum
Yes
My backend code will produce a PaymentLink that's served to my frontend.
However, in my test code, I'll get access to the session and should be able to pay for that session with Python
This is probably something super simple I'm overlooking
pure meteor
I would suggest taking a look at this CLI issue comment for how to build your own fixture using the CLI to execute a sequence against Checkout:
https://github.com/stripe/stripe-cli/issues/516#issuecomment-1464229704
This is about setup mode but you should be able to do the same for subscription mode and use either a successful test payment card or a decline card
clear forum
Is there not a an object along the lines of stripe.PaymentLink.pay(**kwargs)?
I know there's an Invoice.pay('{{INVOICE_ID}}') in the API
pure meteor
No, there is not
clear forum
Some python call that just mocks the API call that's done from the UI
Would it be easy/possible to just copy that API request and send to stripe
Just sending from Python instead of browser? Not sure what's involved on client side
pure meteor
There's no such single call for that though -- it's not the way the payment link and checkout flow works
pure meteor
You can make API to achieve this using a subscription outside the Checkout context, but not through Checkout itself
So you could create a test mode subscription, grab the first invoice and pay it successfully or unsuccessfully, but simulating that specifically through Checkout can't be done with normal API calls
So to achieve this you'd use a CLI custom fixture like the example I showed
clear forum
As long as the subscription, first-invoice and payment will mock what would show up in my webhooks
pure meteor
Sure -- you can do that. You wouldn't receive anything related to Checkout though.
clear forum
The webhook calls will be the same, no?
pure meteor
The subscription/invoice/PI ones should be yes
But which events in particular are you inspecting?
clear forum
Seems like the customer.subscription.updated call is the one that means payment happened successfully
pure meteor
In context it might mean the subscription transitioned from incomplete to active status as a result of successful payment, yes
plucky bronzeBOT
clear forum
Hi, thanks for this.
Another question: what's the recommended protocol for handling when my app server fails to receive/process requests from stripe.
For example, customer paid successfully, but server is down or returns some 500.
split prawn
For webhooks, we will retry sending you the event with three days with exponential backoff (so, we will try again fairly quickly but will space out our retries longer and longer if you are still down). https://stripe.com/docs/webhooks/best-practices#events-and-retries
clear forum
What's the best practice to test this?
Does forwarding the TEST_CLOCK trigger the retries?
split prawn
I'm not sure if the test clock retries would be on the test clock time or real clock time. You can definitely try that in test mode to see. That being said, is there something about the retries that you are trying to test? The event will be the same from our end at least
If that doesn't work automatically you could try manually resending the event with the CLI https://stripe.com/docs/cli/events/resend