#BrianC-checkout
1 messages · Page 1 of 1 (latest)
Webhook event is needed to get the status update. For example, if there's any network error that fails to return to the success URL, you won't be able to get notified for the payment result
Yes I understand that. That is not my question though
When the paument "succeeds" on the UI form (pre-built checkotu) , what is the status of the transaction?
Has the card been successfully charged at that point? Prior to the return URL being called byt he pre-built
Yup, when the checkout page shows succeeds, then the payment is successful
What is the webhook event fired at that time? charge.succeeded?
the moment the button turns green
Is this is docs somewhere?
You can listen to checkout.session.completed event for successful payment: https://stripe.com/docs/payments/checkout/how-checkout-works#complete
So checkout.session.completed is the webhook fired the moment the button turns greeen on the pre-built checkout. Can we confirm this 100%? Thanks!
Yup, I suggest trying out in the test mode first
So you're not 100% sure or you are? It;s important info. We already have a system built with webhooks and all however the testing of the webhooks with connect accounts and the various types of test modes has been brutal. Just collecting some absolute truths to your system (pre-built) as we do not have access to your source code for that. If you are no 100% sure that is the webhook fired at that exact time it's better that we know you're not sure. Thanks!
@versed forge please use the thread created for you
The event delivery is usually immediate, but there can be delays sometimes
Thanks. That's not the question though. I understand how webhooks work and have been developing with Sripe for years. Pre-built checkout is a new venture for us.
The testing of the webhooks is brutal. Really spotty. I just need to know with the UI for the pre-buitl chekcout., when that little button turns green, what is the status of the transaction at that time and the response immeediately sent back, either by webhook or the return URL. Either flavor. The payload is a session object =, correct?
Yes, it's a session object
So once that button turns green the card has been charged, there is no going back. The next event sent out is the checkout.session.compoleted webhook and/or the return url with the appended session id
OK. Thanks! The payload for the webhook event is a session object.
I recommend to use both return_url and webhook event at the same time. When any of them comes first, you can use the status to update your internal system
Yes, we do. It's aready in production but tryying tyo fix some things., The testing is really rough
What is the issue that you're facing?
Ex. the sample return session object when using the CLI (for local dev) and calling the checkout.sesison.completed test paylod doesn;t seem to allow us to get the session with expanded data using the ID sent back with to get expanded data from the session
So we can't seem to test the wbhook function with our code (whcih required expaded data) and using ngrok third party webhook endpoint (instead of the CLI/local), the connect events are not being sent properly. Been working on this for days literaly
Let's start with the triggered checkout.scssion.completed payload testing with CLI. Anhy reason we can';t make a call back to the server from our webhook after we get the session ID to get another sesison with expanded data?
checkout.scssion.completed doesn't contain the expanded data, but you can make a retrieve call to get the expanded data via API
Of course. that is what we are doing. Getting the session id of the session object paylod sendt to the webhoold and then using that Id to call back.
Is it possible tje checkout.session.completed paylod is not a session object? What type of id is this?
cs_test_a1mSaqb6AtZrcyU2MjSp3gbWoOxqm4ciWKQfnXFnF4cw3HcyeHavkb32In
sesssion ID indentifier?
This is the session ID
Can you share the request that you're not able to see the expanded data via API?
OK. This when used to try and get expanded data silently fails when it is generated by the CLI trigger
Do you know why that might haoppen?
Here’s how you can find the request ID (req_xxx): https://support.stripe.com/questions/finding-the-id-for-an-api-request
Not sure I understand. Why do we need this?
Is there something different about a trigger generated session and a live one. The rason I ask is that our production code is working but the test.is not.
Something isnt;'s right
I would like have a look for the request that you're unable to see expanded data via API
cs_test_a1mSaqb6AtZrcyU2MjSp3gbWoOxqm4ciWKQfnXFnF4cw3HcyeHavkb32In
@versed forge if you don't mind, can we take a step back
when you say
the sample return session object when using the CLI (for local dev) and calling the checkout.sesison.completed test paylod doesn;t seem to allow us to get the session with expanded data using the ID sent back with to get expanded data from the session
can you share the exact command that you're running to trigger the sample return session object?
stripe trigger checkout.session.completed
alright, so once you run stripe trigger checkout.session.completed, the webhook event is sent to your server, and you've successfully received it - is all of this correct so far?
yes
when you receive this webhook event, i'm assuming that you're doing something with it in your server code. Can you share that particular section of your code?
var payloadsession = stripeEvent.Data.Object as Session;
StripeConfiguration.ApiKey = _Values.STRIPE_SECRET_KEY;
var requestOptions = new RequestOptions
{
StripeAccount = _Values.DEFAULT_LABEL_STRIPE_CONNECT_ACCOUNT,
};
var option = new SessionGetOptions();
option.AddExpand("customer");
option.AddExpand("payment_intent");
option.AddExpand("payment_intent.charges");
option.AddExpand("payment_intent.charges.data.balance_transaction");
option.AddExpand("line_items");
var sessionService = new SessionService();
Session session = sessionService.Get(payloadsession.Id, option, requestOptions);
this is where we parse the payload object, get the sssion id and send a requeset back to get expanded data
okay, gimme a couple of minutes to take a quick look at the requests you've sent from your account
use this one cs_test_a1mSaqb6AtZrcyU2MjSp3gbWoOxqm4ciWKQfnXFnF4cw3HcyeHavkb32In
that is from a returned payload from the trigger and the id of the session we used to send bakck to get expanded data. thanks!
are you not using the stripe-java SDK : https://github.com/stripe/stripe-java?
.net
ah
what's the response for this line Session session = sessionService.Get(payloadsession.Id, option, requestOptions); ?
i.e. what is session ?
no response. fails silently
session is a lkocal variable of the type Session
Session session = sessionService.Get(payloadsession.Id, option, requestOptions);
that is the call that silently fails
could it be:
firstly, i think you're going to need to take a look at why that line of code is "silently failing". I'm not seeing any .net requests to your Stripe account to retrieve the Checkout Session.
the paylod is not a session object after all so the call to the server via API cannot find the session
OR:
Does it have something to do with the connect account.
?
Testing these connected accounts has been nothing short of a nightmare
when you log payloadsession.Id, do you get something like cs_test_xxx?
yes. just like the one I sent
then it is a valid session id
The one I sent over. Can you find that actual session via the dashboard? we can't
cs_test_a1mSaqb6AtZrcyU2MjSp3gbWoOxqm4ciWKQfnXFnF4cw3HcyeHavkb32In
Where is it?
if you're trying to search directly for the checkout session id in the Dashboard Search bar it won't work
you need to search for the corresponding PaymentIntent id
If that is a valid session id, then it must have something to do with connected account. Which we have not been able to successfully test with either the CLI or using a third party tunnel (locally)
i'm afraid i don't really quite understand what you mean by then it must have something to do with connected account
Got it. I see it now. Loks like expanded data at least exists
We are testing direct charges mad on behalf of connected account. Stripe connect
Could not get it to work with third party tunnel endpoint and switched to the CLI
I'm guessing the CLI is not propely equipped to do this testing since we know the test session has expanded data. Unless of course there is some delay in availableilty but this should not be the case with the webhook
there's a lot of additional details which i'm going to need to understand to help you
OK. But let's both agree that connected accounts cannot be tested with the CLI. There is no way to specify the master/connected accounts correct?
Thatis why it is failing silently. Our code is (rightfully so) querying session from the connected account where the charge was made.
what specifically are you trying to test? there's a lot of scope here when you say "connected accounts cannot be tested with the CLI"
How do you send a triggered webhook payload using the CLI that will act like a charge made by a master account on behalf of a connected account?
It only seems to be possible through a master account. Is there a command to specify this scenario? That would do the trick.
you mentioned direct charges with OBO, are you doing direct charges, or destination charges with OBO? they're different things
or if you can share a live PaymentIntent / Checkout Session id, i can take a look
Sorry! Destination charges. Unless there is a command I am not seeing, it is not possible to specify that with the CLI. It;s makeing sense now that I see where the charge eneded up using the test trigger. it ended up as a session in the master account
onesec
while i try to put together the command to trigger a checkout.session.completed for destination charges with OBO, can you also share why you're setting the StripeAccount header?
var requestOptions = new RequestOptions
{
StripeAccount = _Values.DEFAULT_LABEL_STRIPE_CONNECT_ACCOUNT,
};
for a Destination Charge, the object will exist on the Platform (i.e. master) account, not the connected account
when you use the Stripe Account header, this means you're making the request on behalf on the connected account
for example, the Checkout Session exists on Platform, but you're attempting to retrieve the Checkout Session on the connected account
OK. I might have the terms confused then. When we make a charge, the transactiojn can be found in the connected account and our platform fee is collected (master account) at the POS. Is that direct or destination?
The code I sent over is working and in production, so there is no issue with the code. FYI
That is how we get the expanded session data back after getting the session id
then this probably means that you're doing a direct charge
Yes. They sound the same to me 🙂
if you want to trigger a checkout.session.completed event on the connected account, you can use this flag : https://stripe.com/docs/cli/trigger#trigger-stripe_account
example : stripe trigger checkout.session.completed --stripe-account acct_...
the acct _ is the connected account id I presume
yep, the acct_ is the connected account id
just so you know, it's also possible to override parameters too e.g.
stripe trigger checkout.session.completed --override checkout_session:payment_intent_data.application_fee_amount=1000
somewhat, the examples are a bit lacking though - https://stripe.com/docs/cli/trigger#trigger-override
i generally look at the fixtures : https://github.com/stripe/stripe-cli/blob/6a83b8414d93f29ef91debb2a57cfe80f5d8e4d4/pkg/fixtures/triggers/checkout.session.completed.json
and the available parameters to see how to structure the command : https://stripe.com/docs/api/checkout/sessions/create
Still failing though. cs_test_a1PrwSJMplxIgNfVnExIKVTOkQdtKq6zZQJchTZoRMG2jljwJ2XwI8LE8Y
I'm seeing the transaction in the connected acoutn though so that worked.
what is failing? that same line of code?
Yes. Any reason the generated test data would differ from a normal tunnel webhook generated by our app?
gimme a couple of minutes to look
Great info though about the triggers!
sooooo, you can see the list of your outgoing Connect requests here : https://dashboard.stripe.com/test/logs?method[]=get&direction[]=self&direction[]=connect_in
you have to select the correct filters, these aren't the default filters when you first open the logs page in your Dashboard
OK. But I'm not seeing the call we just made unless the time stamps are off
Not seeing the relevance of that page
if you do a cmd + f on that page for that checkout session id i.e. cs_test_a1PrwSJMplxIgNfVnExIKVTOkQdtKq6zZQJchTZoRMG2jljwJ2XwI8LE8Y, do you see anything?
no
otherwise, can you check what is your current account id? you can find your account id by navigating to https://dashboard.stripe.com/settings/account. It'll be in the upper right hand corner and looks like acct_123
i suspect you're actually on a different Stripe account, than where the requests were made
if your account id != acct_15n9ZnKTXOeT140n, then you're on a different account
I'm not sure what we are looking for here. When I look at the connected account I see the transaction there but that doesn't tell us why the request to get the expanded dtat to that session Id failed
i'm trying to explain how to debug your issue, the Dashboard logs is always a good place to start
but i can always jump right in
stripe trigger checkout.session.completed --stripe-account acct_1IIovFQSLDsUHC6B
here is the call that was made initially
in short, you're making the GET request with the Stripe-Account header as acct_1KZQ32QSv5bgTx2G
the direct charge was made to the correct account and paylod sent
but you're creating the Checkout Session with the Stripe-Account header as acct_1IIovFQSLDsUHC6B
When we used that session id to try to get expanded data it silently failed again.
Just to recap.
OK. Let me hard code it
i can see the most recent request seems to have succeeded
Yup. that was it. Good catch! It's working as expected now. This should do it for us. Thank you so much. I have been on this for days / many hours and you were the first person who actually figured out a solution. Thankd=s!
glad that we managed to figure things out!
Yes! me too! A lifesaver
it's probably late for you and i hope you manage to get some rest, but feel free to reach out again if you need any help 😄