#barry_96217

1 messages · Page 1 of 1 (latest)

wicked bronzeBOT
ruby charm
#

Hello! Do you have an example Payment Intent I can take a look at?

steel marsh
#

pi_3NmoVaGPoenFLLiH1BdIAT7b

#

That fails, and then immediately after it, the same card succeeds..
pm_1NmqphGPoenFLLiHKJqs5nBC

#

Sorry... pi_3NmqpVGPoenFLLiH0735ckJA

ruby charm
#

Taking a look now! Give me a couple minutes...

#

Hmm... I'm not fully sure why it's not working - the only visibility I have is that the card network is declining the card with the do_not_honor code like you already mentioned.

#

Quick question - which of our SDKs/libraries are you using? and which command specifically are you using for step 3 (collecting the payment method)

steel marsh
#

I'm using the Stripe Terminal SDK for Android. I know this is an issue with the payment flow because it is happening with almost every card and then the cards work immediatly after.

#

Is there a limitation to updating a payment intent for "in person payments' with Stripe Terminal?

ruby charm
#

Can you give me specifics on which exact call you're using for step 3?

steel marsh
#

Terminal.getInstance().collectPaymentMethod()

ruby charm
#

and when it's time to close process and capture the payment are you just calling processPaymentIntent (you don't call collectPaymentMethod again)?

steel marsh
#

No, I don't call collectPaymentMethod again.

ruby charm
#

Hmm... theoretically collectPaymentMethod shouldn't be timing out.

#

We do enforce a 30 second timeout for the wise pad 3, but it looks like that payment was with the m2, which should have that issue

steel marsh
#

It

#

It's not a collectPayment timeout.

#

I think it may have something to do with updating the original payment intent an hour or two later. Does this flag something as a security risk?

#

Here is one though with the same exact logic. The paymentIntent was updated about 1 1/2 hours after it was created and it worked fine. pi_3NmnutGPoenFLLiH0Wk9GrJj

ruby charm
#

If there is some kind of 1-2 hour limit on this it's not on our end, it's on the card networks and it would be out of our control - it could be something specific to each card network as well

#

The one that was failing earlier was visa, while the one you just gave was amex, so it's very possible they have different logic on their ends to check which payments should/shouldn't be honored

steel marsh
#

Do the card networks get informed of updates to the payment intent?

#

Is there another work around to my use case? Seems like this would be a very common scenario for Stripe Terminal.

ruby charm
#

Well generally, your usage of the collectPaymentMethod is not really how it's supposed to be used - generally, collectPaymentMethod is supposed to be if you want to check something on the payment method right before payment collection/processing

steel marsh
#

Previously I was using readReusableCard() for this use case, but the fees are quite a bit more because it charges the online payment fees.

ruby charm
#

Gotcha

#

and to answer you're earlier question - I don't the card networks are specifically caring about updates to the payment intent (although I could be wrong here). I think the bigger issue is just the time in between when the card is collected and when it's being used

#

and it's possible something is timing out on the card networks end

#

The only way to really handle this would be to be resilient to it in your code/integration - if you get a decline then you'd need to recollect the payment method and process the payment again

steel marsh
#

That would work in most cases, but we also want to be able to process if a customer walks out without closing their tab (this happens multiple times per day). We were able to negotiate fees for in person payments, do you know if there is anyway to negtiate fees for online payments?

ruby charm
#

But yeah, if you need the 100% guarantee that your customer can walk away and you'll still be able to collect payment you're much safer using readReusableCard