#BrianC-checkout

1 messages · Page 1 of 1 (latest)

vestal cypress
#

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

versed forge
#

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

vestal cypress
#

Yup, when the checkout page shows succeeds, then the payment is successful

versed forge
#

What is the webhook event fired at that time? charge.succeeded?

#

the moment the button turns green

#

Is this is docs somewhere?

vestal cypress
versed forge
#

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!

vestal cypress
#

Yup, I suggest trying out in the test mode first

versed forge
#

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!

vestal cypress
#

@versed forge please use the thread created for you

vestal cypress
versed forge
#

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?

vestal cypress
versed forge
#

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.

vestal cypress
#

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

versed forge
#

Yes, we do. It's aready in production but tryying tyo fix some things., The testing is really rough

vestal cypress
#

What is the issue that you're facing?

versed forge
#

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?

vestal cypress
#

checkout.scssion.completed doesn't contain the expanded data, but you can make a retrieve call to get the expanded data via API

versed forge
#

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?

vestal cypress
#

This is the session ID

#

Can you share the request that you're not able to see the expanded data via API?

versed forge
#

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?

vestal cypress
versed forge
#

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

vestal cypress
versed forge
#

cs_test_a1mSaqb6AtZrcyU2MjSp3gbWoOxqm4ciWKQfnXFnF4cw3HcyeHavkb32In

pliant forge
#

@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?

versed forge
#

stripe trigger checkout.session.completed

pliant forge
#

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?

versed forge
#

yes

pliant forge
#

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?

versed forge
#

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

pliant forge
#

okay, gimme a couple of minutes to take a quick look at the requests you've sent from your account

versed forge
#

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!

pliant forge
versed forge
#

.net

pliant forge
#

ah

#

what's the response for this line Session session = sessionService.Get(payloadsession.Id, option, requestOptions); ?

#

i.e. what is session ?

versed forge
#

no response. fails silently

#

session is a lkocal variable of the type Session

#

that is the call that silently fails

#

could it be:

pliant forge
#

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.

versed forge
#

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

pliant forge
#

when you log payloadsession.Id, do you get something like cs_test_xxx?

versed forge
#

yes. just like the one I sent

pliant forge
#

then it is a valid session id

versed forge
#

The one I sent over. Can you find that actual session via the dashboard? we can't

#

cs_test_a1mSaqb6AtZrcyU2MjSp3gbWoOxqm4ciWKQfnXFnF4cw3HcyeHavkb32In

#

Where is it?

pliant forge
#

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

versed forge
#

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)

pliant forge
#

i'm afraid i don't really quite understand what you mean by then it must have something to do with connected account

versed forge
#

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

pliant forge
#

there's a lot of additional details which i'm going to need to understand to help you

versed forge
#

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.

pliant forge
#

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"

versed forge
#

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.

pliant forge
#

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

versed forge
pliant forge
#

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

versed forge
#

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

pliant forge
#

then this probably means that you're doing a direct charge

versed forge
#

Yes. They sound the same to me 🙂

pliant forge
#

example : stripe trigger checkout.session.completed --stripe-account acct_...

versed forge
#

the acct _ is the connected account id I presume

pliant forge
#

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

versed forge
#

Fantastic. Is this all in the docs?

#

I'll try a simple one right now.

pliant forge
versed forge
#

Still failing though. cs_test_a1PrwSJMplxIgNfVnExIKVTOkQdtKq6zZQJchTZoRMG2jljwJ2XwI8LE8Y

#

I'm seeing the transaction in the connected acoutn though so that worked.

pliant forge
#

what is failing? that same line of code?

versed forge
#

Yes. Any reason the generated test data would differ from a normal tunnel webhook generated by our app?

pliant forge
#

gimme a couple of minutes to look

versed forge
#

Great info though about the triggers!

pliant forge
#

you have to select the correct filters, these aren't the default filters when you first open the logs page in your Dashboard

versed forge
#

OK. But I'm not seeing the call we just made unless the time stamps are off

#

Not seeing the relevance of that page

pliant forge
#

if you do a cmd + f on that page for that checkout session id i.e. cs_test_a1PrwSJMplxIgNfVnExIKVTOkQdtKq6zZQJchTZoRMG2jljwJ2XwI8LE8Y, do you see anything?

versed forge
#

no

pliant forge
#

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

versed forge
#

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

pliant forge
#

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

versed forge
#

stripe trigger checkout.session.completed --stripe-account acct_1IIovFQSLDsUHC6B

#

here is the call that was made initially

pliant forge
#

in short, you're making the GET request with the Stripe-Account header as acct_1KZQ32QSv5bgTx2G

versed forge
#

the direct charge was made to the correct account and paylod sent

pliant forge
#

but you're creating the Checkout Session with the Stripe-Account header as acct_1IIovFQSLDsUHC6B

versed forge
#

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

pliant forge
#

i can see the most recent request seems to have succeeded

versed forge
#

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!

pliant forge
#

glad that we managed to figure things out!

versed forge
#

Yes! me too! A lifesaver

pliant forge
#

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 😄