Page MenuHomePhabricator

How will we expose payment processor errors/issues with gravy
Closed, ResolvedPublic

Description

Historically we have had the failmail system setup so when a payment processor does something we don't expect (returns a status we hadn't seen before, is down, etc) it will send a failmail alerting us that something unexpected has happened.

With gravy inbetween us and the payment processor, gravy will now be getting the unexpected responses which gravy normalizes to a failure response and we handle accordingly. So far there have been two incidents with paypal donations where something was not working right but we had no failmail visibility as the gravy response was something we could handle.

Incidents so far:

How do we want to try and find these issues going forward?

Suggestions so far:

  • Someone in Donor Relations/fr-tech keeping an eye on the gravy console for any error wave (I think we should have something more automated set up than this but its what we should be doing in the meantime)
  • fr-tech builds something that further looks into the responses gravy sends back and create failmail if its not something we are expecting
  • We build more analytic dashboards to keep an eye on overall metrics

Event Timeline

Change #1167601 had a related patch set uploaded (by Jgleeson; author: Jgleeson):

[wikimedia/fundraising/SmashPig@master] Extract out Gravy response status normalizing to own class

https://gerrit.wikimedia.org/r/1167601

Change #1167602 had a related patch set uploaded (by Jgleeson; author: Jgleeson):

[wikimedia/fundraising/SmashPig@master] Extract error detection logic into dedicated ErrorChecker

https://gerrit.wikimedia.org/r/1167602

Change #1167603 had a related patch set uploaded (by Jgleeson; author: Jgleeson):

[wikimedia/fundraising/SmashPig@master] Relocate ErrorMapper from Mapper to Errors namespace

https://gerrit.wikimedia.org/r/1167603

Change #1167604 had a related patch set uploaded (by Jgleeson; author: Jgleeson):

[wikimedia/fundraising/SmashPig@master] WIP: Implement Gravy payment error threshold monitoring

https://gerrit.wikimedia.org/r/1167604

Change #1167601 merged by jenkins-bot:

[wikimedia/fundraising/SmashPig@master] Extract out Gravy response status normalizing to own class

https://gerrit.wikimedia.org/r/1167601

Change #1167602 merged by jenkins-bot:

[wikimedia/fundraising/SmashPig@master] Extract error detection logic into dedicated ErrorChecker

https://gerrit.wikimedia.org/r/1167602

Change #1167603 merged by jenkins-bot:

[wikimedia/fundraising/SmashPig@master] Relocate ErrorMapper from Mapper to Errors namespace

https://gerrit.wikimedia.org/r/1167603

While working on this, I noticed that some Gravy Connector Errors are retryable, which might be something we want to return to the calling code, i.e., payments-wiki and CiviCRM. We could send back a retryable flag so that the clients have the option to try again after a period.

Change #1180871 had a related patch set uploaded (by Jgleeson; author: Jgleeson):

[wikimedia/fundraising/SmashPig@master] Move redis connection settings outside data-store namespace

https://gerrit.wikimedia.org/r/1180871

Change #1180871 merged by jenkins-bot:

[wikimedia/fundraising/SmashPig@master] Move redis connection settings outside data-store namespace

https://gerrit.wikimedia.org/r/1180871

Change #1167604 merged by jenkins-bot:

[wikimedia/fundraising/SmashPig@master] Add Gravy payment error threshold monitoring & alerting system.

https://gerrit.wikimedia.org/r/1167604

XenoRyet set Final Story Points to 8.