#tyrzaphir_unexpected

1 messages · Page 1 of 1 (latest)

halcyon grailBOT
#

👋 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/1387088054422081580

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

sick kelp
#

Here's a screenshot from Google Pay

GpayToken.png
hollow pendant
#

Hello, do be clear are you trying to investigate the declines, why the setup also shows up as a transaction, or both?

#

Do you have the ID of that payment intent? (pi_123)

sick kelp
#

We are investigating why there is both a decline and a successful transaction for a single PaymentIntent. I'll look for the payment intent ID but it may take a little while to find.

hollow pendant
#

Gotcha, payment intents are state machines meant to handle potentially multiple attempts at paying for a single thing. Each time you try to confirm a payment intent we will attempt to charge the card, so this would be expected if the user initially got a decline, tried again, and then got approved (gotta love ML fraud models 🤷)

#

So it would be surprising if this is happening every time, or for intents that succeeded on the first try, but its hard to say what may be happening at this point.
Another possibility for that screenshot is two separate payment intents each of which separately tried to charge the card.

sick kelp
#

I believe this is the payment intent in the screenshot, there's a few others for the same amount but this one seemed to have the right time pi_3RbB74I9KoULkM4U0hKxctl6

#

For context, we used this functionality at an 8000 person music festival this past weekend, and this behavior occured often enough that our on-site team started instructing guests to use a physical card at the kiosk (where we create the SetupIntent) specifically to avoid confusion later when they make a purchase later through our system.

hollow pendant
#

Do you have any payment IDs that you know for sure saw this issue? I'm trying to think of how to look in to this, but having an ID that we know for sure exhibited this behavior will be very helpful in investigating

sick kelp
#

Okay I just got a better example. The customer cus_SWCQL4hbH9VX0b has only two payments, both succeeded. Here is a screenshot of that customer's Apple Wallet, where you can see two declined and two succeeded transactions.

IMG_8805.PNG
#

Payment intents pi_3RbA7mI9KoULkM4U1k33Vfpm and pi_3RbA57I9KoULkM4U0lbEfLBw

#

For each transaction, this customer reported seeing a notification from their wallet app saying that the transaction was declined. It was only when he opened up the wallet app that he saw both the decline and the success

hollow pendant
#

Gotcha thank you. Looking in to this. And to be clear, the entire API process on your side was confirming a SetupIntent with a terminal, then creating payment a payment intent to charge them?

sick kelp
#
  1. Create and confirm a SetupIntent via the Android Terminal SDK
  2. Create and confirm a PaymentIntent via the API using the payment method from that SetupIntent
  3. Capture that PaymentIntent
#

Thanks for your help! Also, the first customer, with the $2.17 google pay transaction, is someone on my staff. So if you want me to do another transaction now to his payment method and then send a new screenshot of what he sees in his Google Pay app, we can do that

halcyon grailBOT
raw stream
#

👋 stepping in -- taking a look but will need a few minutes.

#

Okay so what is happening here is Adaptive Acceptance: https://docs.stripe.com/payments/analytics/acceptance#adaptive-acceptance

Basically we do initially receive a decline from the issuer and then we immediately retry with slightly tweaked parameters since our models indicate that these transactions aren't fraudulent. Unfortunately, it looks like the wallet providers here are showing this initial decline when typically they don't -- for instance the actual issuers won't show the initial decline.

#

Overall, Adaptive Acceptance leads to big uplifts in conversion. But, if you really want to, I believe you can request that it be turned off for your account. You would need to contact our Support team via https://support.stripe.com/contact/login about that.

sick kelp
#

Gotcha, so if I am reading this right, Stripe is making a charge attempt with one set of parameters which declines, and then retrying with a different set of parameters which succeeds. Can anything be done to ensure that the first charge attempt uses the correct set of parameters? It's strange that it happens so consistently and it is always the second attempt that succeeds.

raw stream
#

Nothing you can do right now -- I'll file some feedback internally about this to see if there is anything we can tweak on our end. I have a suspicion this might be related to CVC checks on the initial authorization and then we do some tweaking to properly indicate that the card was collected via a PoS.

#

I agree this isn't great and we should figure out how to improve it since it is seems to be happening pretty consistently.

sick kelp
#

That makes sense. Thanks for your help and let me know if yall are able to make any improvements!