#brian-johnson_error
dry egretBOT
👋 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/1217518858152316978
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
hot yarrowBOT
soft dagger
hi 👋
How did you create this payment method?
narrow shoal
via an API call - I can see if I can get the API request
soft dagger
I shared with you the confirmation request that saved this payment method
narrow shoal
Hmm that link you sent is for a PI made on a terminal
I don't think this one is from a terminal
soft dagger
Yes it is
That's that the card_present means
Unless you used a payment method you didn't intend to
narrow shoal
Hmmm
Sorry looking at our API call log
When we make an API call to create a payment intent we hard code the type - "cnp" - card not present, "cp" - card present
terminal is always card present
soft dagger
Yeah I'm looking in our Admin interface. I can go from the request ID you provided that the Payment Method ID used corresponds to ta card_present type PM.
It was created because the Payment Intent that was confirmed with this card had setup_future_usage: "off_session"
narrow shoal
Yeah this call did not originate during a terminal checkout on our side
Yeah so this looks like a saved card checkout
that's why the type (for us) is CNP
soft dagger
Except it's not
narrow shoal
So is this error indicating that the payment method used in this is not valid?
hot yarrowBOT
narrow shoal
Sorry I apologize for confusion on my side but based on our API calls it's not making sense to me
soft dagger
You need to review this doc: https://docs.stripe.com/terminal/features/saving-cards/save-after-payment
narrow shoal
Yeah I have
soft dagger
I think what you need to do is attach the generated_card to the Customer during creation
soft dagger
But that isn't the PM that was used
narrow shoal
We do thousands of these a day
narrow shoal
Yep I'm not doubting you
sorry if it sounds that way
I just was not expecting it to go this direction
because it doesn't make sense looking at the API calls on our side
soft dagger
Okay, I just want to make sure we are clear there. So then we can try to understand why your system used that PM instead of the one attached to the Customer
narrow shoal
Yep - so to be clear
this eror is because we're basically using the wrong payment method on the PI
Is it possible to see if that PM was saved as a generated_card on a terminal checkout?
"saved" = created
I need to track down where we can possibly be saving or getting the wrong PM
narrow shoal
OK - in this case "generated_card" is null
so we would not have saved that PM
hmm
but I DO see that is the payment method on that request
soft dagger
Status is "requires_capture". When did you capture that charge?
narrow shoal
""payment_method": "pm_1OmnQEDbVO0r1ghHjJlH2a8R","
Let me look
Here's the capture
yeah generated_card is still null
hmm
I do se it is "apple_pay"
does that mean they might have used the iOS wallet on this one?
soft dagger
Yes that does appear to be the case here
Okay I did some digging on my end and it looks like this is a known issue with digital wallets (Apple/Google pay)
narrow shoal
OK so my suspicion is that for some reason the business chose to "save" this card, but it was an apple pay checkout so no generated_card was created, and for some reason we end up saving the payment method anyway with the wrong value, then tried to re-use it
OK
by "known issue" does that mean there's something I can check for?
soft dagger
By "known issue" I meant it's something we have raised internally and we know it's a pain but have not found a work-around for it yet
However, we should do a better job documenting it
soft dagger
Oh wait 🤦
Unless your business is a car rental service or hotel, you can’t save mobile wallets (for example, Apple Pay or Google Pay) for later reuse while transacting
It's in that doc
narrow shoal
OK yeah that is what I am suspecting. What's weird though is we look explicitly for generated_card only - so I'm not sure how we're "saving" the wrong payment method ID
but that at least gives me the direction to investigate
soft dagger
Okay so that's a different area to research.
narrow shoal
Yep - I appreciate your help