#SoloGeneral - CLI trigger issuing auth request

1 messages · Page 1 of 1 (latest)

final latchBOT
thick briar
#

Interesting

#

I have one theory to test, just a moment

#

I am assuming the same happens without the connected account, correct?

#

(ie, that's not a factor here)

fresh widget
#

I believe so.

#

We are listening for if event.type == "issuing_authorization.request" but I do not see that event being shown in the log when I trigger it.

thick briar
#

Yea you'd see it in the listen logs if it were

#

Ok i think this is because issuing_authorization.request is a special event

#

The command works for me on my test Issuing account, i suspect because I have a webhook endpoint configured to receive that event type

#

Then try the trigger command again

#

note that if you want to use a connected account, you should configure a Connect type endpoint

thick briar
#

SoloGeneral - CLI trigger issuing auth request

twilit knot
#

So to clarify here we can't test that using stripe local endpoint we would have to use something like ngrok to get that to our local setup?

thick briar
#

Not exactly -- i can test it via CLI listen, i just need to set up a test endpoint subscribed to that event to tell Stripe I need them

#

It's a bit roundabout, and I agree the CLI should probably get them automatically

#

I'm going to file some feedback to that effect

twilit knot
#

I just did that and I still can't access it locally

#

stripe listen --events issuing_authorization.request --forward-to localhost:3000/api/v1/stripe_webhooks

thick briar
#

I was about to ask if specifying events helped

twilit knot
#

I even limited it

#

I see the code in the CLI SDK but this trigger business is driving me nuts

thick briar
#

🤔

#

Can you set up the same kind of test endpoint as an Account endpoint and try the trigger without the connected account?

twilit knot
#

Looks like that worked

#

So its an issue with connect?

#

However, doesn't seem like its hitting the local endpoint smh

thick briar
#

When you say the local endpoint, do you mean the CLI listen or the server you fwd that to?

twilit knot
#

CLI listen

thick briar
#

So it's still not appearing in the stripe listen output?

twilit knot
#

it appears but normal you would see a [200] POST etc

#

It just shows all the commands

#
2022-12-05 16:02:05   --> issuing_card.created [evt_1MBlndJcIAKVEIOPeXXJVwMJ]
2022-12-05 16:02:06   --> issuing_authorization.request [evt_1MBlneJcIAKVEIOPwjPuI9Ah]
2022-12-05 16:02:06   --> issuing_cardholder.updated [evt_1MBlneJcIAKVEIOPhTcvpW5S]
2022-12-05 16:02:09   --> issuing_authorization.created [evt_1MBlnhJcIAKVEIOPwMf8SPgr]```
thick briar
#

Those are responses related to the forwarding

#

If you're not forwarding you shouldn't expect to see those

#

200 refers to the success 200 response form the local endpoint you forwarded to

twilit knot
#

stripe listen --forward-connect-to localhost:3000/api/v1/stripe_webhooks

#

oh

#

connect-to

thick briar
#

right, so that's saying to forward connect events, but the test we did to eventually make this work was not a connected account event

twilit knot
#

yup got it now

thick briar
#

if you did --forward-to i think you'll see those results

twilit knot
#

Yep that worked

#

Thanks.

thick briar
#

But, taking a step back, do you actually need this to be happening on the connected account?

#

ie, is that what you're trying to build?

twilit knot
#

yes

#

but for testing I think it should be fine

#

we have this already in production but we are changing the way we are doing auths so I wanted to make sure we can fully test this

thick briar
#

Gotcha

#

Is the custom account as you used in your test representative of what you're doing in prod?

twilit knot
#

Yes

#

Whats the best way to override a specific value in the event data object?

#

i.e. card id

twilit knot
#

--override data:card.id=ic_XXXXXXX

thick briar
#

you're trying to override on the issuing auth request?

twilit knot
#

yeah

#

oh

#

I guess I am not understanding the syntax

spring hull
#

Hi there 👋 I'm jumping in so my teammate can take a break. I believe you'd be looking to override issuing.authorization:cardholder.

#

So I think you might need something like (but overrides can be tricky, especially in multi-fixture triggers, so this may not be exactly right):
--override issuing.authorization:cardholder=ich_123

twilit knot
#

card id rather

spring hull
#

Gotcha, can you try:
--override issuing.authorization:card=ic_123

twilit knot
#

That didn't work

spring hull
#

Can you elaborate on how it didn't work? Did it throw an error, or did it trigger the events as before without adjusting the underlying data?

twilit knot
#

sorry. It didn't override the value

spring hull
#

Hm, pointing that override to the exact right place can be tricky. Are you able to test this flow by taking the actions in your account that would trigger these events? Testing that way makes it easier to control what objects will be included in the events that are sent.

twilit knot
#

unfortunately no

spring hull
#

I'm struggling to figure out how to override the card's ID, and believe that is because the trigger process is creating a new Card each time it's called and is using that newly created Card's ID.