#slowgen-paymentrequestbutton
graceful swan
That's correct! The new Payment Element works with apple/google pay so you don't need to implement a separate PRB if you don't want to
jagged talon
That's great news
I am a little confused about this if you can clarify: inspecting the paymentIntent for a status after payment for success or failure etc on the client side using js, if the the status is processing is the client notified aync?
graceful swan
Yeah async payment methods will be notified of payment success/failure through the webhook
jagged talon
Are any of the cards or apple pay or google pay async methods?
We're not planning on intentionally using methods that require further intervention outside of 3ds
graceful swan
No, cards should not have any delay like that
graceful swan
happy to help!
jagged talon
Are bank redirects method supported in the UK?
graceful swan
A lot of them are, yes - are you interested in a specifc one?
distant tartan
@jagged talon
jagged talon
I am not sure, I thought bank redirects are customers redirected to their bank website? Am I right in thinking that?
Or are there providers for that
graceful swan
Yeah I believe most (if not all) will redirect to the bank website - https://stripe.com/docs/payments/bank-redirects
jagged talon
Ah I see, none of the listed ones have UK mentioned but you reckon they're supported?
graceful swan
Ah I realized I should've asked this earlier - are you asking if there are any bank redirect methods that support a UK customer, or a UK merchant?
jagged talon
so all our customers are uk based bank accounts, and we're in the UK too if that's what you mean by merchant
graceful swan
Gotcha - so as a UK merchant you can accept bank redirects from customers in any of the countries listed at (https://stripe.com/docs/payments/bank-redirects) using the appropriate bank redirect method. For your UK customers that have UK based bank accounts, I don't believe they can use bank redirects
jagged talon
That's fair enough. I need help with a few more things if that's ok with you
graceful swan
Yeah go ahead!
jagged talon
cheers
Our current integration uses confirmCardPayment but the new integration looks like it's replaced it with confirmPayment we pass billing_details is this possible still in the new integration?
graceful swan
Yup! You should still be able to pass in billing_details (see https://stripe.com/docs/js/payment_intents/confirm_payment#confirm_payment_intent-options-confirmParams-payment_method_data-billing_details)
jagged talon
Ah great!
So currently we wait for the intent status to if it's succeeded then post the form with items, customer, etc to populate our database as their was no return_url parameter. I am just thinking ahead, about how we would now post data if stripe redirect to the return_url
hope that makes sense
We don't want to populate our internal database with orders if payment wasn't successful
graceful swan
I'd rely on a combination of return_url and listening for the webhook event - customers can always accidentally leave your page or lose internet or just not complete the redirect for whatever reason, so you want to be sure you handle that case gracefully
jagged talon
Do you reckon posting the data always then checking status of the intent on the server before saving to database?
Do webhooks generally require cron jobs?
graceful swan
No webhooks shouldn't need cron jobs
Can you elaborate on this a bit more: "Do you reckon posting the data always then checking status of the intent on the server before saving to database?"
jagged talon
The customer is buying xyz products we save those details in our database only if a payment is successful. To do this we normally just post a web form if intent responds success all on the client side. Now with the return_url I am not sure how I will post that data and keep our current way of only saving if payment successful. So I was thinking of posting everything before hand and only save if payment is successful the difference would be we check intent status on the server
graceful swan
You can make that post request from the return_url so that the request is made when your customer gets to that page.
jagged talon
Problem is how to pass all the form data to the return_url without exposing it as example.com?name=abc&password=123&email=...
Unless I am missing something?
Sorry for the noobis questions
graceful swan
Give me one minute...
jagged talon
NP whenever you're ready
graceful swan
Sorry about that - got a bit busy there for a minute
Yeah if you have sensitive things like a password you wouldn't want to pass it on in a query param
Something you can think about - if you want to leave your integration the same, you don't have to use the return_url with the payment element
jagged talon
fair, isn't return_url mandatory?
graceful swan
With confirmPayment you can pass in redirect: 'if_required' to only do the redirect if it's necessary for the payment method (cards do not require a redirect). Then, the behavior will be similar to the card element integration
jagged talon
That leads me to
Setting if_required requires that you handle successful confirmations for redirect-based and non-redirect based payment methods separately. When a non-redirect based payment method is successfully confirmed, stripe.confirmPayment will resolve with a {paymentIntent} object.
How can I inspect the response if the object is returned? Current integration shows inspecting the return_url for query parameters then retrieving the payment intent
graceful swan
You already have a Card Element integration right?
jagged talon
Yes I do
graceful swan
Great, so when you turn the redirect off stripe.confirmPayment should behave exactly the same as stripe.confirmCardPayment that you're already doign in your card element integration
It'll resolve to a Payment Intent which you can check the status of
(you can see how the old docs used to do this here: https://stripe.com/docs/payments/accept-card-payments?platform=web&ui=elements#web-submit-payment)