#eamjr_api
1 messages Β· Page 1 of 1 (latest)
π 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/1479577215522967572
π 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.
- eamjr_api, 3 days ago, 25 messages
Hello π taking a look!
It appears the issuing bank declined the card for the reason invalid_pin so I wonder if the card required pin entry to be charged? Perhaps because it's a UK card being used in the US. What makes you think the card should have been chargable without a pin?
The did a pament link to the customer and ceated a pm and attached it to the rental. How would we know if it required a pin?
Do you have the PaymentLink or PaymentMethod ID?
Stand by
pm_1T82n8Jb61fXCXsLJ4khtwsO same guy same card but payemnt link
Hey there, just stepping in for jazz who needs to step away
Thanks
it looks like this card was inserted into the reader and the issuer wanted to collect a pin (do you know if this was entered?) and then declined for invalid PIN
The guys on the counter say this one did not ask for a pin.
Ultimately the customer would need to talk to their bank about that decline if they are certain the PIN is correct. It's possible that the decline was for other reasons like international usage etc.
The terminal never prompted the customer to enter the pin.
The S700 supports pin entry (even if thats uncommon in the US) so if it was required it could have been collected
They used a payment link and the card authorized: pm_1T82n8Jb61fXCXsLJ4khtwsO
But our understanding is the Stripe backend is prompting on the terminal for the pin correct?
And the terminal did not request a pin. Again I am not at the rental counter. Goin on what the counter agents are relaying to us regarding the pin entry.
The reader should prompt for a pin when the issuer requests it, yes.
The online payment works a bit different, pin entry doesnt apply there (you can ~loosely think of 3DS and PIN entry as online and in-person analogues)
The counter guys knew that. They wer quick enough to gereate a payment link so the customer could rent the car.
Right, so ultimately the issuer is declining this card, and indicating the invalid pin as the reason, but thats not always a perfect reflection of the actual reason the bank chose to decline
I'm glad they were quick thinking there to get that customer transaction completed successfully π
So if there were any other reason why would it get approval on the $500?
On the link
I don't think you shared that payment intent ID, but no i don't think so, just the bank making a different decision
pm_1T82n8Jb61fXCXsLJ4khtwsO
For example:
https://support.stripe.com/questions/pin-transaction-support-using-stripe-terminal-for-international-cards
- During the authorisation process, the card's issuing bank ultimately decides whether the card is approved or declined.
- International cards that get declined for in-person transactions with Terminal may be approved for online payments, so you can collect card details and process as card-not-present instead. This is because there is no requirement for PIN for online, card-not-present transactions.
Online PINs Some cards are issued with online PIN capabilities, where the PIN data is verified by the issuer when an authorization is run. Stripeβ¦
This sounds like what happened here, given the international card
Roger we say the documentation in the api docs regrading that. They had a similar isuse last week. We insert the card do a $1 pm to deterimine if the card is good, is it a debit/credit/prepaid because we will take diffeent actions based on that. Prepaid not allowed at rental. Debit credit check requrired at rental, regular go continue the rental proces. Af completiioin of the rental process if it is a credit card we try to do an incremental authorization on the $1 for the difference. The one last week prompted for the pin on the $1 but did not prompt on the inclremental . The incremental declined. They used the payment link trick again on that one. Any idea why it prompted once but not again?
Do you have an example of that incremental auth request? I'm curious, but i suspect its because it happened without the temrinal context, and PIN entry wouldn't make sense (customer not necessarily present etc).
The one last week was card present and asked for the pin. on the $1 . I am asking the counter to see if I can locate the secon acion. Standby
Doing these small charges is not recommend, instead using setup intents to collect cards instead, which can be inspected for the funding type like you're describing
https://docs.stripe.com/api/payment_methods/object#payment_method_object-card-funding
The reason it is that way is the platform owns the terminals and not the connected accounts. That was causing an issue with setup intent is my udnerstanding. The counter with the issue last week say they bailed on the first rental and started a new one with a payment link.
I don't think the payment vs setup intent would necessarily affect which account owns the readers or where the payment methods reside, but i can take at face value you've done what works for you.