#DusanCar
undone geode
Hello! Some payment IDs would be handy: pi_xxx
Also how are you deriving the 'type' of purchase? Where are you seeing that?
atomic ocean
pi_3Nx4SXDQxxrFqRtq2TUbsIC0
pi_3Nx4TbDQxxrFqRtq2HMv8QBP
pi_3NxFhQDQxxrFqRtq1C055LJQ
pi_3NxQkgDQxxrFqRtq2XBlfxu3
pi_3NxQmkDQxxrFqRtq2AmZ9oLG
pi_3NxR5IDQxxrFqRtq00F4Fowu
Here are some payment IDS from all the attempts we made. First 5 were failures, while the last one succeeded. The type of transaction we've found from the customers bank since he provided us with a screenshot where it says that it was a POS terminal instead of web payment (attaching that screenshot as well)
undone geode
Do these 6 separate Payment Intents represent one transaction/payment?
The type of transaction we've found from the customers bank since he provided us with a screenshot where it says that it was a POS terminal instead of web payment (attaching that screenshot as well)
Unfortunately that's not something we control. Perhaps the bank mark Stripe procesed payments as POS? Not sure, that's something they'd need to flag with their bank
None of those payments are Terminal (our POS/in-person product) so it wouldn't be flagged as such by us
atomic ocean
Not sure I understand what you mean exactly when you say 6 separate payment intents representing one transaction ?
They were created for the purpose of charging the same thing but 6 different payment intents as 6 different attempts were made if thats what you meant
undone geode
Yep, that's what I meant. Out of interest why are you doing it that way?
In reality you should only require a single intent per 'payment'. They can be re-confirmed if an initial attempt fails (as per the above examples)
They transition to requires_payment_method status, then you can just confirm again with new payment details from the user
mellow yewBOT
atomic ocean
They are not checkout payments, but rather offline payments performed with customers previously added payment methods by doing setup intent, so we are not actually following up on customer changing payment method details immediately.
I guess when customer comes back to pay manually we could maybe utilize the approach you mentioned, but it seemed more standardized to always do it with clean one. Are there any downsides to it ?
undone geode
If they're off-session payments as you describe, then the general recommended procedure is to handle the payment_intent.requires_action event and bring your customer back on-session to provide new payment details and re-confirm. Simply retrying the same payment will likely just result in the same decline/failure (I guess in this instance it was 'forced' through)
atomic ocean
The idea behind simple retries was that if customer had no money and now he has enough money and that was the reason for decline that in that case the payment would pass, but in other cases I understand your point.
undone geode
Even in that scenario you describe you can re-confirm the same intent
Which facilitates another attempt to charge a card (that you/your customer provide) for the amount on the intent
Creating another intent is just an additional API call that is mostly redundant and will pollute your Dashboard
Notice how on the examples you shared they'd all status: 'requires_payment_method? That's not a terminal state: https://stripe.com/docs/payments/paymentintents/lifecycle#:~:text=If the payment attempt fails (for example due to a decline)%2C the PaymentIntent’s status returns to requires_payment_method so that the payment can be retried.
atomic ocean
Okay this makes sense. We will reconsider the cost-benefit of reworking it a bit and see about it. Thanks a lot about suggestions