#oleg-codaio

1 messages · Page 1 of 1 (latest)

primal yarrowBOT
elder ocean
#

Hi there, let me take a look.

void basin
#

Thanks for taking a look. So those other events are actually associated with different charges.

If you look at the events associated with that invoice: https://dashboard.stripe.com/events?related_object=in_1M8dj4AegRHrUhUqdzBOvIx4

The API call occurred at 12/1/22 10:58:59 AM PST. The subsequent invoice.payment_failed event happened 12 hours later at but it was for a different charge (initiated by Stripe)

elder ocean
#

The charges are different, but the invoice is the same.

void basin
#

Right, but in this case what happened is that charge failed, and no subsequent invoice event was generated. So in our system, the customer object was locked for half a day

#

It seems odd to me that I initiated payment for the invoice using invoice.pay, and there was a charge.failed event, but no invoice.payment_failed event

elder ocean
#

Hmm? I thought I just sent you two invoice.payment_failed event IDs?

void basin
#

Yeah you did, but those were for different payment attempts

#

For the payment attempt at 12/1/22 10:58:59 AM PST, there was no invoice.payment_failed event

elder ocean
#

Can you share me the charge ID?

void basin
#

ch_3M8djHAegRHrUhUq0GWTDGBQ

elder ocean
#

OK. the invoice.payment_failed is fired if the invoice payment is triggered by Stripe subscription engine. So since this ch_3M8djHAegRHrUhUq0GWTDGBQ is triggered manually, no invoice.payment_failed is fired.

void basin
#

The only thing that's unique about this case is there was a processing_error. So it seems that processing_errors aren't resulting in the same error handling logic as other kinds of errors like card_declined, which smells like a bug to me (or is at least unexpected)

#

Hence my original question if processing_errors are special (and need to be handled differently)