#PrivateCitizen-webhook
manic hull
Not sure i understand, you mean this?
https://github.com/stripe/stripe-php/archive/refs/tags/v9.1.0.tar.gz
manic hull
All, im looking at logs, i see what happened. My confusion is the request.id=null now. Im assuming how things are handled was change. Now i have to figure out how to build my mouse trap to work with the new way.
My memory is a little fuzzy too, i coded for version 7 back in march.
autumn mason
Yes pretty much the case
manic hull
I can explain what im doing, you tell me what i have to change...
Im using subscriptions on stripe.
On my site when someone wants to make a new account, i take their details and save in SQL in a temp table.
I then send them to checkout.
The webhook gave a request.id which i saved in the sql temp table with their data.
On invoice_paid i would then use the request.id to match payment to the data stored in the sql temp table. I would then use that data to create an account and add that user with their new stripe customer ID to a permanent sql account table.
So i was using request.id as the glue to match checkout session completed and invoice paid to their data stored in temp table.
autumn mason
What request id, for example, that you are using?
It sounds a bit weird to me for using a request id
and where do you take a request.id from invoice.paid to match up?
manic hull
This is what i was using, because back then (march) it was what i found that was consistent between webhooks linking all the calls together to the same customer / checkout-session.
Since multiple webhooks are fired off for a single customer/transaction
autumn mason
I see. Let me ask some clarify questions
How much time from a checkout.session.completed until an invoice.paid events that you are storing and matching up the id?
I think subscription id would be a better id to use
manic hull
But multiple customer would have the same sub id, right?
manic hull
Is data->subscription something new in v9 that wasn't in v7?
autumn mason
I don't think so, but isn't it just good enough for now? 🙂
manic hull
Maybe, im running some test.... brb
manic hull
More fuzzy memories.... After a customer signs up, everything worked, account was created in stripe and on my backend. When its time for renewal, when their card is auto charged and the webhook is sent letting me know to extend their subscription. What happens for the data->object->subscription then? What gets passed? Anything? Same as when they signed up? A new sub number?
autumn mason
Should be the same id sub_xxx
manic hull
I notice something else not the same.
Using \Stripe\Checkout\Session::retrieve i would get the subscription->latest_invoice->payment_intent->status but it is now returning null.
manic hull
After that point. I changed my code to use subId as you suggested, i resent the webhooks and they went through, customer account was created.
I have a landing page for the customer for after they finish checkout, on that page i would use the session::retrieve to verify status and show the corresponding message to them, like it worked, payment is pending, etc.
Im seeing on the https://stripe.com/docs/api/checkout/sessions/retrieve docs it shows that status is still a thing. But on the test im doing right now its coming up null.
Im going to dump the json to see if it changed... brb
autumn mason
Good luck!
manic hull
Im getting confused with the docs, im looking at https://stripe.com/docs/api/checkout/sessions/retrieve but it is not matching up with what im getting.
object(Stripe\Checkout\Session)#5 (41) {...}
It is a Checkout Session object
manic hull
What is the right docs for that?
I tried using search, this is what i got, which gave me those docs.
autumn mason
manic hull
So im guessing the way that was handled has been changed. Is the info in a different field now?
I have a guess what is happening. They changed how you have to expand it?
$session = \Stripe\Checkout\Session::retrieve(['id' => $stripeSessId, 'expand' => ['subscription.latest_invoice.payment_intent']]);
I don't think so. But if you use the Subscription Id it shouldn't be a problem right?
manic hull
As far as i know, its the only way to get the current status, such as if payment is pending (bank payment).
manic hull
```
$session = \Stripe\Checkout\Session::retrieve(['id' => $stripeSessId, 'expan...
But i believe its not being expanded in the reply. What is the new way of doing that? That is the code im currently using.
autumn mason
Your code are correct, but it's just no PaymentIntent there to expand
If you expand latest_invoice, you should see the object
manic hull
So that was changed? Because i was getting expanded info for payment intent when using v7.x
Or from another angle. What field can i check to find out the status of the payment? Like before it would return succeeded, processing, requires_payment_method.
manic hull
cs_live_b1IJxJm1OoHZS7BVg3p0swlN1iJHrPEs74LJ9UWLWfYrijYbFDbvh0VmxW
I think ive found something, look like its been changed from
subscription -> latest_invoice -> payment_intent -> status
To just being
payment_intent -> status
Or i could be reading the docs wrong.
autumn mason
This Invoice doesn't have any PaymentIntent
Because it has Limited Plan Free Trial (100% off)
manic hull
Anyway way to create a live transaction with payment_intent without charging a real cc?
autumn mason
No. You should create a test transaction with a test card instead
why not using Test mode? It's safe and you can test anything
manic hull
I used a dummy account for test mode, this account only has live setup. I didn't want to have to create test products and prices just for one transaction. But im trying to run through a dry run to make sure everything works after upgrading to v9.x
autumn mason
I would recommend still do on Test mode, either on the dummy account or this account
manic hull
Okay, i think that is good enough for today. Thanks for your help. You can close/delete this thread.