Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Square: implement webhooks for payments received #1556

Open
jim opened this issue Jun 21, 2024 · 0 comments
Open

Square: implement webhooks for payments received #1556

jim opened this issue Jun 21, 2024 · 0 comments
Assignees

Comments

@jim
Copy link
Member

jim commented Jun 21, 2024

There have been a couple instances over the past few months where someone was charged by Square for a membership but this wasn't recorded in the Circulate database. The current implementation relies on someone being redirected from the Square checkout page back to Circulate for a Membership to be created and the payment to be recorded. We don't have great logs for this (yet), but the most likely cause is that the member didn't get redirected successfully back to Circulate.

Square supports sending webhooks to applications when various events occur. To solve the above issue and make the app more resilient, we should implement a webhook so that we can perform the various post-payment actions more reliably and not rely on the user's browser to complete payment flow processing.

To work on this, you'll need to setup a developer account with Square.

jim added a commit that referenced this issue Jun 22, 2024
# What it does

We had an instance of a member taking longer than 30 minutes to complete
the signup steps, and it timed out just as they were paying for their
membership. You can see [the sample of this occurrence in
AppSignal](https://appsignal.com/chicago-tool-library/sites/60596f9214ad662e17191689/performance/incidents/59/samples/60596f9214ad662e17191689-158228531489123241821718233200?selectedTime=2024-06-12T23%3A05%3A00.000Z&activeFilter=date).
This meant that the callback from Square was rejected and their
membership payment wasn't recorded correctly in our system. The logic to
calculate if the time had passed was also hard to follow as it was
previously implemented.

This change gives people 2 hours to get through signup. The original
time was chosen arbitrarily, and in hindsight I can't say why it needs
to be so short. I'm open to making it even longer; the main risk I can
think of is on shared computers where folks might enter some of their
info, walk away, and leave the window open for someone else to complete.

The other part of a complete solution to this problem is to implement
web hooks for payments, which it captured by #1556.
@jim jim self-assigned this Jun 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: 🏗 In progress
Development

No branches or pull requests

1 participant