#SoloGeneral - CLI trigger issuing auth request
1 messages · Page 1 of 1 (latest)
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)
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.
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
Can you try setting up an endpoint for that here: https://dashboard.stripe.com/test/webhooks
Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.
Then try the trigger command again
note that if you want to use a connected account, you should configure a Connect type endpoint
SoloGeneral - CLI trigger issuing auth request
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?
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
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
I was about to ask if specifying events helped
I even limited it
I see the code in the CLI SDK but this trigger business is driving me nuts
🤔
Can you set up the same kind of test endpoint as an Account endpoint and try the trigger without the connected account?
Looks like that worked
So its an issue with connect?
However, doesn't seem like its hitting the local endpoint smh
When you say the local endpoint, do you mean the CLI listen or the server you fwd that to?
CLI listen
So it's still not appearing in the stripe listen output?
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]```
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
stripe listen --forward-connect-to localhost:3000/api/v1/stripe_webhooks
oh
connect-to
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
yup got it now
if you did --forward-to i think you'll see those results
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?
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
Gotcha
Is the custom account as you used in your test representative of what you're doing in prod?
Yes
Whats the best way to override a specific value in the event data object?
i.e. card id
--override data:card.id=ic_XXXXXXX
you're trying to override on the issuing auth request?
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
card id rather
Gotcha, can you try:
--override issuing.authorization:card=ic_123
That didn't work
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?
sorry. It didn't override the value
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.
unfortunately no
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.