Page MenuHomePhabricator

Spike: Lots of 21000050 errors for Globalcollect, since July
Closed, ResolvedPublic1 Estimated Story Points


What is this about?

orphans: globalcollect_gateway_tr 27169358:4479613483 processResponse Error 21000050 : Blocking validation problems with this payment. Investigation required!

We received 20 of these today, from the frontend and the orphan slayer. Grepping through the logs, I see that we got 1,326 of these in July, 111 in June, and only 2 in May. I don't like that it's growing bigger. Doesn't look like it's proportional to traffic.

Also: We seem to be in danger of losing some institutional knowledge, let's document the common errors and investigate what constitutes a "flood of errors" for each one. I've never heard of this error, but as recently as a year ago someone lovingly crafted code paying homage to this particular error.

Event Timeline

awight raised the priority of this task from to High.
awight updated the task description. (Show Details)
awight added a subscriber: awight.
atgo edited a custom field.

Change 231186 had a related patch set uploaded (by Ejegg):
Log original GlobalCollect validation error

Change 231186 merged by jenkins-bot:
Log original GlobalCollect validation error

@Ejegg do the patches on this mean that this is either in review or deployed? Should we add Fundraising Sprint Queen ?

Atgo, the patch just lets us catch more information, and was deployed on Thursday. I'll see if it's caught any of these yet.

ah ok. just doing some cleanup in advance of Prawning, so no hurry.

Oops, that last patch was useless. Logging our generic error message instead of the actual error message from GC! Let me fix that...

Change 232761 had a related patch set uploaded (by Ejegg):
Log real GC error on validation problem

Change 232761 merged by jenkins-bot:
Log real GC error on validation problem

Caught one! From the Japan form, trying to donate via JCB: '21000050 REQUEST 10380495 VALUE *** OF FIELD CVV IS NOT A NUMBER WITH MINLENGTH 1, MAXLENGTH 4 AND PRECISION 0'

What's up with that? We're not collecting CVV for GlobalCollect.

We aren't...? I thought we were.

Nah, for GC that's all in their iframe. But we're even seeing some expiry date validation fails from them, so it looks like they're just screwing up their iframe's client-side validation somehow and still bouncing donors back to our return URL.

Chiming in, we get CVV validation results back from GC, so that might be why it looks like we're collecting the number ourselves.

Emailed GC 10/14 asking that they look into improving validation in their iframe.

Ejegg moved this task from Backlog to Done on the Fundraising Sprint UB40 board.

Saw another one of these on March 29, 34622232:1667666430