#morteza-tp-1990_api

1 messages · Page 1 of 1 (latest)

cerulean juncoBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1433478368959135846

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

cedar narwhal
#
  1. on Tap to pay app how can I know if a payment can be tried again on the frontend ? for example imagine a test card is used , the collect payment emits an error, how can i know if I can retry that payment ??
#

thanks in advance

#

Great team of developers at Stripe

zealous minnow
#

Hi again, what Event types is your endpoint configured to listen to? Do you have the IDs of the Events that were created that you didn't receive?

Wallets are part of the card Payment Method. LPM stands for Local Payment Methods, and are the other non-card payment method types.

For 3, what is blocking you from retrying the payment currently? What are situations where you wouldn't want to retry the payment?

cedar narwhal
#

payment_intent_payment_failed, cancel, success just the 3

#

so in tap to pay other payment methods can happen right ? that I should also consider the LPM errors ?

zealous minnow
#

No, tap to pay is for cards

cedar narwhal
#

first tell me please if i make a test card in live tap to pay app, does stripe make that payment method failed ??

zealous minnow
#

What do you mean by "make a test card in live"?

cedar narwhal
#

we have a test card

cerulean juncoBOT
cedar narwhal
#

using test card in live environment I mean

#

is using test card in live mode make the payment intent fail ??

zealous minnow
#

Is it one of our terminal test cards? Or are you referring to some other physical test card that we offer?

cedar narwhal
#

yes

zealous minnow
#

Yes, that request should return an error (I think, you've flipped between talking about a payment method and a payment intent, so I'm not 100% sure I know what request you're asking about making)

cedar narwhal
#

sorry i meant payment intent

zealous minnow
#

I would expect a request trying to confirm a Payment Intent using a physical test card in live mode to return an error, or at least not successfully result in a payment.

cedar narwhal
#

ok does this make the payment intent fail ?? by fail I mean should I expect to receive payment_fail event in the webhook ?

#

pi_3SNxHYLmjdnG8GX01jNjvfOW

languid trench
#

👋 stepping in as toby needs to step away

#

Really you shouldn't be using a test card in production nor testing in production.

#

You should just be testing in test mode.

cedar narwhal
#

great, how can I know in the frontend that I can retry the payment ???

#

I mean collect payment returns a Promise which yields an error in that case

#

how can i know if that error is something like test card usage which can be retried or something elase that fails the payment intent tottaly

languid trench
#

You don't need to handle the case of a test card -- it is a test card. All real card attempts will result in the promise resolving / a Webhook.

cedar narwhal
#

i have another question

#

if i get success from the collectPaymentMethod on tap to pay app can I 100% trust that ? or still I should wait for the webhook , too ??

#

is it possible for card payment method that collectpayment is success but webhook will respond with failure ???

languid trench
cedar narwhal
#

so if confirmPaymentIntent is success that money is 100% collected and no need to wait for webhook, am I right ??

#

I guess in the terminal sdk we use , it's auto captured

languid trench
#

Yes, the auth is successful and if you are using auto capture then funds are captured immediately.

You should still listen for Webhooks here as it is always possible that the connection is lost during the confirmation process and the confirm succeeds but you never get the promise resolution.

cedar narwhal
#

in our integration after collecting payment method and confirm the payment, we check the payment status with the bank , I wanna know if we can ommit that steps that sometime takes some time !!

languid trench
#

How do you do that? Like using a third party or something?

cedar narwhal
#

sorry

languid trench
#

But yeah no, no need to do that. Once the confirmation is successful and the capture occurs then the funds are in your Stripe account.

cedar narwhal
#

I meant with our backend which is updated with webhook

languid trench
#

Gotcha yeah no need to wait for that. You should have that in place for fulfillment but you can go ahead and proceed client-side without waiting for the Webhook.

cedar narwhal
#

this is true only for card as payment method ? and card_present

languid trench
#

For any synchronous payment method type, yes.

#

You can still proceed for async payment method types without waiting for the Webhook but it doesn't necessarily mean the charge will be successful at that point.

#

Like with bank debits for instance.

#

You need to check the response though client-side for card confirmation requests....

#

The PaymentIntent can go into requires_action for 3DS to be completed in that case. That doesn't apply with card_present.

cedar narwhal
#

ok

#

that was useful information

#

thanks