#kevinx-connect-webhooks

1 messages · Page 1 of 1 (latest)

near cargoBOT
merry jolt
last bison
#

thanks, let me take a look

#

ok, read through it and double check, nothing seems wrong

#

one question here, when I use CLI to listen to localhost, it gives me a webhook signing secret which is different from the webhook secret from the dashboard, how to use this one from CLI

#

do I need to replace the Webhook secret with one from CLI ?

#

ah, that's the reason

merry jolt
#

Yup

last bison
#

I thought the webhook secrect from the dashboard can work with testing etc

merry jolt
#

The CLI uses a different secret because it's a separate endpoint

last bison
#

Got it, thanks, btw, is there anyway to copy webhook setup from Test mode to production? just like product? or do I have to redo everything in production

#

I didn't find a way to do so

merry jolt
#

I'm not sure what you mean there. The only difference is the URL it points to.

#

All the code that handles the webhook event lives on your server

last bison
#

no, I meant the webhook endpoint settings from the dashboard

merry jolt
#

Like what events to listen to?

last bison
#

one more question here, when trigger charge.dispute.created, I got below error

stripe trigger charge.dispute.created
Setting up fixture for: payment_intent
Running fixture for: payment_intent
Trigger failed: Request failed, status=400, body={
  "error": {
    "message": "A `return_url` must be specified because this Payment Intent is configured to automatically accept the payment methods enabled in the Dashboard, some of which may require a full page redirect to succeed. If you do not want to accept redirect-based payment methods, set `automatic_payment_methods[enabled]` to `true` and `automatic_payment_methods[allow_redirects]` to `never` when creating Setup Intents and Payment Intents.",
    "request_log_url": "https://dashboard.stripe.com/test/logs/req_mjpIndGzDSJLrN?t=1692913207",
    "type": "invalid_request_error"
  }
}
last bison
merry jolt
#

Ah, yes because you are on the latest API version and automatic_payment_methods is on

#

Can you try updating your CLI?

last bison
#

Ok, here I need a little bit help to understand it

merry jolt
#

Sure

last bison
#

as I never experienced a charge dispute in real situation

#

What does this error mean

merry jolt
#

It doesn't actually involve a charge dispute

#

It is attempting to create a Payment Intent.

#

And not passing all the parameters required because you are on the latest API version

last bison
#

ok, so how to solve this problem lol

#

I just reinstalled the CLI to latest

#

still giving me the same error

merry jolt
#

Can you try running the command with --add payment_intent:return_url=https://example.com

last bison
#

Thanks ,this works and looking at the evecnt.data.object, I didn't find any attribute relates to the Connect Account at all, the same thing for payment_intent.succeeded

#

Well, how should we link these two the connect account to handle them

#

Here are the returned obj

merry jolt
#

What is the command you wrote exactly?

last bison
merry jolt
#

Okay there is nothing Connect related there

last bison
#

Here is what was returned
merry jolt
#

What are you looking for?

last bison
#

I'm setting up the webhook for Connect Standard account based on the doc

#

and here are a few events I'm listening

#

charge.dispute.created

#

payment_intent.succeeded

merry jolt
#

Okay but the CLI doesn't know that

last bison
#

well, the returned object should at least including an attribute, even if the value is null

merry jolt
last bison
#

ok, I don't see an account id or similar attribute from the link you just sent either

#

how should people know which account where this dispute is related

#

the same thing for payment_intent.succeeded

#

or am I missing something here

merry jolt
#

The link I sent shows you the flag you need to pass

#

--stripe-account acct_XXXXXX

#

That flag will ensure the objecst are created for the Connected Account you identify with the ID you provide

last bison
#

added the flag, still don't see the account id from response

#

it gives me 200

# 
id: 'dp_1Nill9FK1YId5EcvSm3IkhjF',
  object: 'dispute',
  amount: 100,
  balance_transaction: null,
  balance_transactions: [],
  charge: 'ch_3Nill8FK1YId5Ecv1ESnYzT0',
  created: 1692915131,
  currency: 'usd',
evidence: {
},
  evidence_details: {
},
  is_charge_refundable: true,
  livemode: false,
  metadata: {},
  payment_intent: 'pi_3Nill8FK1YId5Ecv1l5hR7xg',
  payment_method_details: { card: { brand: 'visa', network_reason_code: '10' }, type: 'card' },
  reason: 'fraudulent',
  status: 'warning_needs_response'
}
near cargoBOT
merry jolt
#

This was a direct charge, so you would see the application identifying the platform associated with these objects

last bison
#

ok, we are the platform, and need to identify connect account for the dispute and payment intent right

lapis slate
#

👋 taking over! Are you trying to do this on the Event in your webhook handler?

last bison
#

yes

case "charge.dispute.created":
      const chargeDisputeCreated = event.data.object;
lapis slate
#

Gotcha, let me have a quick look to see what we send you. The CLI is a bit "weird" with Connect webhooks and I wonder if it's the problem

last bison
#

Thank you, appreciate. the help

lapis slate
#

Okay so your code right now look at event.data.object that would be the Dispute object for a charge.dispute.created Event right?

last bison
#

yes, based on the doc

#

here is the response I got, too long to paste, so it's a pic

lapis slate
#

and what you are looking for right now is which connected account is the Event from right?

last bison
#

Yes, exactly, when the webhook gets it, we need to identify which account it is related to right, so that we can handle it properly

lapis slate
#

you want connectedAccountId = event.account in that code

#

Like if you dump the entire JSON from the Event you get something like this ```{
"id": "evt_1234",
"object": "event",
"account": "acct_ABC",
"api_version": "2023-08-16",
"created": 123456,
"data": {
"object": {
"id": "dp_EFG",
"object": "dispute",
...

#

and you were deep in data.object and didn't realize there's more info top-level, if that makes sense

#

kevinx-connect-webhooks

last bison
#

Got you, thanks, let me check

#

Yeah, you are right, it's in the event, thanks @lapis slate !

lapis slate
#

Awesome! This is easy to miss since even in the Dashboard we show the raw JSON of what's inside event.data.object instead

last bison
#

Yes, I was wondering where it is 😁

#

Again, thanks , I guess experience is more valuable

lapis slate
#

it's under the "webhook conversation" at the bottom of the page

#

but it's harder with the CLI to notice

#

especially because you're testing Connect so you have to look at the connected account's own Dashboard and it's a bit of a pain

#

my advice: always always dump the raw JSON of the raw Event/payload you get in your webhook handler when debugging

last bison
lapis slate
#

I have a PHP script I wrote years ago and the first thing it does is that so that no matter what I do after I always get the JSON dumped in a file I can look at

last bison
#

Yes, it's a good practice for sure

#

Alright, thank you man, for the help

lapis slate
#

Sure thing! Let me know if you have follow up questions after playing with it

last bison
#

😀 thanks, will do

lapis slate
#

will take a while to review/merge/release though