#holfy
1 messages ยท Page 1 of 1 (latest)
Hi, you can test a processing payment intent with bank debits like this: https://stripe.com/docs/payments/ach-debit
As for required_payment_method, here are some options: https://stripe.com/docs/testing#non-card-payments
Ahh so essentially if we only allow card payments will we never receive these status'?
As I understand card payments will fail authentication before you get to this stage/
This could happen with 3DS
let me get you the correct link
This, https://stripe.com/docs/testing#authentication-and-setup is what you should test with
Ok and then intentionally fail the 3DS
I just tried but that does not return as a payment.intent status failure, it returns "An unexpected error occurred." which is from this bit https://stripe.com/docs/payments/quickstart#handle-immediate-errors
If you fail this authentication, you'd be able to get the requires_payment_method status
I just tested this on my end and seeing this: requires_payment_method status. Can you share this request id please?
Also, if you're just looking to see this status, if create the paymentIntent and leave it without adding a payment method, you should also get this status.
Ah I'm sure the status is there if I request it sorry, it's more the quickstart guide I am having issues testing
Following the Custom payment flow quickstart, I was under the impression that stripe was doing an HTML redirect to the redirect_url in the handleSubmit(e) function.
This is not 100% true, I thought you were looking to do so in test mode. But in live mode, you'd be able to see this with card payment, although it would be quick.
Got it, let me know if you have any other questions on this.
This return_url is a new page so I load a new JS file to run the checkStatus() function... Is this the correct way to do it?
If I run checkStatus() and it returns 'processing' then what do you suggest, keep firing it until I get a success or fail?
I don't understand how the example code works because of the redirect stripe is doing so checkStatus never gets fired? (or if the redirect is to the current page the user is on then I suppose it's fired but only once)
Sorry If I am not being clear
๐
Stepping in as pgskc needs to step away
Card payments are synchronous, you won't see a PaymentIntent in a processing status unless you are using async payment methods like a bank debit.
Can you clarify exactly what the question is here? I'm not sure I'm understanding where the confusion lies
I think that clears it up. If we are just using Card payments, Apple Pay and Google pay, and I am using the code from the quickstart, will I ever receive a processing or requires_payment_method status from the PaymentIntent status inside the checkStatus() function?
Your checkStatus is on your redirect page? Are you forcing a redirect? Or only setting to if_required? A PaymentIntent that fails confirmation will move back to requires_payment_method
But no you won't see processing
Yes my checkStatus is on the same page as my redirect page. I am forcing a redirect to maintain consistency.
My understanding was that once the user is redirected I should use the intent ID to run checkStatus ...
Yeah overall that's correctly. Mostly, if you are just using synchronous payment methods, then the PaymentIntent will be succeeded if your return_url is hit
But the recommendation is to retrieve it to both check the status and to show success details to your customer
Ok understood.
If the card fails 3DS though I'm guessing this will be caught by any immediate errors and the return_url will never be hit?
I need to know that with my current payments methods (card, apple pay and G pay) is there is a chance that when my return_url is loaded and I ping stripe with checkStatus I could get an error message and do I need to set up fallbacks to deal with it?
No, all this will take place on your payment page assuming you are letting Stripe.JS handle 3DS. The return_url is only hit on success.
Wonderful thanks.
So if I decide to add ASYNC payment methods going forward, then I need to set up fallbacks for processing and failed?
Guessing processing fallback would be 'keep pinging stripe until I get success or error'... and failed would render the payment fields again
(Sorry for all the questions ๐ )
You really want to set up Webhooks either way, but especially for async payment methods
Yes webhooks are actually all set up
I guess I should use webhooks too update the page based on the status and only run check status once
Oh okay then yeah you would just want to cater your return URL to send appropriate information based on the PaymentIntent status. But you would use Webhooks for the actual reconciliation process
Yeah exactly
Sweet makes sense to me now thank you!! Thanks for baring with me ๐