brandontrytn | Stripe Developers | Page 1

grand nightBOT Jul 19, 2023, 3:43 PM

#

sage eagle Jul 19, 2023, 3:43 PM

#

👋

#

Yep if you can provide the PaymentIntent ID I can let you know what I can see

robust goblet Jul 19, 2023, 3:45 PM

#

126.25: pi_3NRIfwLunEUcvTyc17nqFWKr
575.70: pi_3NRIfwLunEUcvTyc17nqFWKr

315: ch_3NRIcELunEUcvTyc1ytKjeaW

sage eagle Jul 19, 2023, 3:47 PM

#

So the overall confusion is around the $315 charge, correct?

#

Like you aren't expecting that charge?

robust goblet Jul 19, 2023, 3:48 PM

#

correct, we deal in payment intents, so the two payment intent charges are correct. our system doesn't make charges and the customer got charged that 315 but we don't know where it came from

#

it has since been refunded so just trying to figure out where it came from

sage eagle Jul 19, 2023, 3:50 PM

#

Alright well to be clear Charges are created from confirming a PaymentIntent. And that Charge is associated to a PaymentIntent (it wasn't created directly). https://dashboard.stripe.com/logs/req_rnMv0lzSxrDpCl is the creation request and https://dashboard.stripe.com/logs/req_EpQvIDB7tARDRP is the confirmation request.

Comparing to one of the other PaymentIntents, I can see that this one was created using the same IP as the other -- so it does seem like it was deliberately created from your server (if it was a different IP then that could indicate your key was leaked or something).

#

Overall nothing looks amiss to me here. I think the two options are either that something failed with the data ingestion on your end for this Charge and thus it is "unexpected", or there is some sort of bug that caused it to be created/confirmed though to me that seems more unlikely

robust goblet Jul 19, 2023, 3:52 PM

#

so to understand the workflow we have a pending payment intent. when we call confirmPayment from the JS SDK it creates the charge record and then confirms the payment intent?

sage eagle Jul 19, 2023, 3:53 PM

#

Yep

#

Are you using Webhooks for data ingestion?

robust goblet Jul 19, 2023, 3:55 PM

#

we do utilize webhooks for some data ingestion, like recording gateway processessing fees and sending meta data over to stripe to attach to the payment records

sage eagle Jul 19, 2023, 3:55 PM

#

How do you record Charges on your end?

robust goblet Jul 19, 2023, 3:56 PM

#

we get the charge succeeded webhook from stripe and then store a record of it with our payment record on our end

sage eagle Jul 19, 2023, 3:57 PM

#

Gotcha okay that seems fine.

#

So why is this Charge "unexpected"?

#

The customer just said they didn't make that purchase?

robust goblet Jul 19, 2023, 3:57 PM

#

we don't have a record of the charge and the customer complained to the operator they got an erroneous charge

sage eagle Jul 19, 2023, 3:58 PM

#

Got it

#

Yeah I mean we have pretty limited insight here

#

So nothing really looks weird from my perspective

#

Is this the first time this has happened?

robust goblet Jul 19, 2023, 3:59 PM

#

this is the first time I've heard of it happening

sage eagle Jul 19, 2023, 4:00 PM

#

I can see that your Webhook handler responded successfully to the Webhook: https://dashboard.stripe.com/events/evt_3NRIcELunEUcvTyc19sL4HfM

#

So I would mostly be concerned for why you don't have the data on your end.

#

I think adding some logging to capture each step of that data ingestion process is the way to go. Then if this happens again you can look at those logs to try and debug what happened.

robust goblet Jul 19, 2023, 4:01 PM

#

we log a ton of stuff, let me see what I have in the way of logs around that area. the event link didn't seem to work for me but all the others have

sage eagle Jul 19, 2023, 4:02 PM

#

Ah that Event is on the Connected Account

#

Try using https://dashboard.stripe.com/acct_1JfreOLunEUcvTyc/events/evt_3NRIcELunEUcvTyc19sL4HfM

robust goblet Jul 19, 2023, 4:06 PM

#

that one works

#

so we do have logging for this. I see 3 webhooks with that charge ID in it. the only way we have to tie a transaction on our side to the data sent from your side is by looking up the pi_ ID. it looks like this charge was a different pi_ than the two other charges

sage eagle Jul 19, 2023, 4:09 PM

#

I'm not positive what you mean by that. Each successful Charge will be associated to a unique PaymentIntent

#

A PaymentIntent is a state-machine object. So if a Charge attempt fails then you can have multiple Charges associated to a PaymentIntent. But once there is a successful confirmation, then there would just be one successful Charge for each PaymentIntent

#

So what do you mean by "the two other charges"?

robust goblet Jul 19, 2023, 4:10 PM

#

earlier the 575 and 126 charges both appear to have the same pi_ id

#

oh nevermind, I was looking at the wrong thing

sage eagle Jul 19, 2023, 4:11 PM

#

👍

robust goblet Jul 19, 2023, 4:15 PM

#

ok, tracing things back, it appears when it came back from stripe from the confirmPayment call it was in a semi-error state. meaning there was an error object of payment_intent_unexpected_state but the payment_intent.status field shows as succeeded. since it was an error state our system does not continue with the purchase on our end. should we not look flatly at the error object but also the status for this?

#

currently if we receive anything for an error object we fault and do not continue

sage eagle Jul 19, 2023, 4:17 PM

#

Ah okay I do see that there were multiple confirmation attempts here -- there were 3 confirmation attempts after the initial successful one.

#

Are you disabling the button on click?

#

Also yeah you shouldn't really care about this error object at all when it comes to data ingestion

#

You should rely on the Webhook itself

robust goblet Jul 19, 2023, 4:18 PM

#

disable it as well as pop an overlay, but on error we re-enable so they could try again with a different payment method to self-correct

sage eagle Jul 19, 2023, 4:18 PM

#

Ah okay so you'll want to do some amount of debugging here on your frontend for how the customer was able to confirm the PaymentIntent again even though there was a successful attempt

#

Looks like these confirmation attempts happened 10 seconds apart

robust goblet Jul 19, 2023, 4:19 PM

#

yeah I believe they hit an error state and we allowed them to submit again, but seems like even though there was an error it really wasn't

#

I see the first attempt. stripe came back with error incomplete_number

sage eagle Jul 19, 2023, 4:20 PM

#

That is validation of the Element itself

#

There was no error/decline with the PaymentIntent

robust goblet Jul 19, 2023, 4:23 PM

#

so we can't currently rely on the webhook to determine success as we need to create the payment record after succes in order to tell the user the payment was successful. the entire time we've used the payment element we've looked at the response from confirmPayment to determine if it was successful. to continue this path we can't look at only the error object but also the payment intent status, would that be a fair statement?

sage eagle Jul 19, 2023, 4:25 PM

#

Yeah you should certainly check the PaymentIntent status and that is how I would determine to show the customer a success message.

That all said, I would recommend not tying this process to your data ingestion. You should have a separate process for data ingestion based on Webhooks since your customer could drop off at any point after starting the confimration flow and before you get to that promise actually resolving

robust goblet Jul 19, 2023, 4:26 PM

#

yeah it's in the backlog. just a very large undertaking

#

is there a support doc that gives the various status that could be returned for this?

sage eagle Jul 19, 2023, 4:27 PM

#

https://stripe.com/docs/api/payment_intents/object#payment_intent_object-status

#

Mostly you want to just care about whether it is succeeded or not when confirmPayment() resolves

robust goblet Jul 19, 2023, 4:28 PM

#

cool

#

as always, this was exceptionally helpful! thanks so much!

#brandontrytn