#tobytimer-auth-capture

1 messages · Page 1 of 1 (latest)

weary fjord
#

@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

trim bough
#

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

weary fjord
#

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

trim bough
#

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

weary fjord
#

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

trim bough
#

ah i see

#

is there a recommendation on the most efficient way to do this while running a server on localhost?

weary fjord
#

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?

trim bough
#

that does

#

but my local server won't be able to listen for stripe webhook events (unless i'm missing something)

weary fjord
#

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

trim bough
#

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

weary fjord
#

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_*]

trim bough
#

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]```
weary fjord
#

do you use a custom fixture? Yours incorrectly passes confirmation_method: 'manual'

trim bough
#

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?

weary fjord
#

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

trim bough
#

100% sure we definitely don't use fixtures

weary fjord
#

Ack let me look into this

trim bough
#

for completeness, i'm using the latest version of the cli (1.7.1)

weary fjord
#

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

trim bough
#

no worries, thank you!

weary fjord
#

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

trim bough
#

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

weary fjord
#

correct

trim bough
#

it's basically stuck there

weary fjord
#

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"

trim bough
#

i see

#

is there a way to have the cli use the test environment (where i don't have radar rules set up)?

weary fjord
#

It does use the Test environment right now

#

and you do have those rules setup there otherwise this wouldn't happen

trim bough
#

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

weary fjord
#

correct!

trim bough
#

that's perfect

#

thanks for your help today!