#tobytimer-auth-capture
1 messages · Page 1 of 1 (latest)
@trim bough I recommend simply creating the PI yourself with code instead to trigger the right one you want. The problem is that by default a PI might require an action (for example 3DS) and it's just easier to write code to reproduce exactly what you need
sorry, i might not have been super clear in my question
we've been doing auth and capture in one step until now (for the past year or so)
i've updated the code so that capture_method=manual
that seems to work fine
but now my webhook listener that looks for the payment_intent.succeeded event is no longer going to work (ie, i need it to be triggered on payment_intent.amount_capturable_updated (i think))
i've updated the webhook code to look for event.type == 'amount capturable_updated' but when i test that event via the CLI with stripe trigger payment_intent.amount_capturable_updated i get the two events instead (created and requires_action)
i should also note for completeness that for both of those events, amount_capturable=0 via the test CLI
Sure sure but my advice is: do not use the CLI for this. Write code to create and confirm a payment intent successfully server-side but with manual capture disabled
just to make sure i understand you correctly, you're suggesting we move away from the existing flow where the payment gets confirmed client side and our server performs the confirmatory actions via a webhook listener to one where we confirm server side, then receive and handle the response there (and ditch the webhook altogether)?
not at all, I'm sorry. All I'm saying is: do not test this manually using the CLI (since you seem confused by the flow) and just cause this to happen with real code in Test mode
ah i see
is there a recommendation on the most efficient way to do this while running a server on localhost?
Create a PaymentIntent with the 4242 test cards, easiest is to pass confirm: true and payment_method: 'pm_card_visa'
You can also do this manually in the Dashboard
Does that make sense?
that does
but my local server won't be able to listen for stripe webhook events (unless i'm missing something)
Hmmm
Sorry, all I meant was "don't use stripe trigger for that specific flow"
Sorry I think I must be misunderstanding what's blocking you entirely
no worries!
let me try to rephrase
right now in production, i create the payment intent server side then confirm (and capture) client side. i then have a server that listens for webhook events (specifically payment_intent.succeeded) which then triggers confirmatory actions (recognizing a paid order, sending confirmations etc)
i've updated the payment intent creation and client side confirmation code so that it now handles auth only (with capture to be done at a later stage). I've tested that part as you suggested (i.e. with test cards etc) and that's working fine
i now just want to test that my updated webhook listener works with the amount_capturable_updated event (instead of succeeded) so i wanted to hit that test listener with a test event. in the past, i've used the CLI to do this, but here it doesn't seem to be working
So what isn't working? Because I did try stripe trigger payment_intent.amount_capturable_updated and I get ```2021-09-13 13:50:35 --> charge.succeeded [evt_]
2021-09-13 13:50:36 --> payment_intent.amount_capturable_updated [evt_]
2021-09-13 13:50:36 --> payment_intent.created [evt_*]
it triggers 2 events
2021-09-13 16:52:13 <-- [200] POST http://localhost:8000/stripe-payment [evt_3JZM8MCRCQcICM3a1STLze3E]
2021-09-13 16:52:13 --> payment_intent.created [evt_3JZM8MCRCQcICM3a1swyNfIw]
2021-09-13 16:52:13 <-- [200] POST http://localhost:8000/stripe-payment [evt_3JZM8MCRCQcICM3a1swyNfIw]```
do you use a custom fixture? Yours incorrectly passes confirmation_method: 'manual'
you mean capture_method?
and i don't understand what you mean by custom fixture
if i don't pass capture_method='manual' it captures the payment immediately (which is what our production code does now and isn't what we're looking to do)
just googled custom fixtures - answer is no, i'm not using that but maybe i should be in this case?
there are 2 separate parameters: capture_method and confirmation_method. The API request made by the CLI for your example is incorrectly passing both and the second one (which you don't know about) is the issue which the CLI should not pass on its own
https://stripe.com/docs/cli/fixtures Are you sure you don't use this (or someone on your team)?
100% sure we definitely don't use fixtures
Ack let me look into this
for completeness, i'm using the latest version of the cli (1.7.1)
gotcha okay the confirmation_method is our weird config so not your fault and not relevant
someone on my team flagged something else, still looking
no worries, thank you!
Seems that you have a Radar rule that requires 3DS when 3DS is supported and so it causes your PaymentIntent to go in requires_action so that you do 3DS client-side
ah i see
so if my understanding is correct, when i trigger amount_capturable_updated it doesn't just trigger that event but all the necessary preceding events
because my account requires 3DS
correct
it's basically stuck there
the trigger what it does is make the right API calls your code would make to end up in that state
it doesn't just send a "fake event"
i see
is there a way to have the cli use the test environment (where i don't have radar rules set up)?
It does use the Test environment right now
and you do have those rules setup there otherwise this wouldn't happen
ah, let me check
you're absolutely right
i disabled those rules and i get 2 events now created and amount_capturable_updated
so just to complete the picture
in production where we have 3DS required
when the client successfully authenticates using 3DS, that'll trigger that event (it's just that via the CLI i wasn't able to do that because i didn't have a client ui)?
correct!