Ability to monitor and edit team permissions by API (workaround to prevent Refund permission abuse)

We’d like to avoid employees being able to refund arbitrarily large number of payments, up to a year back.

If we could limit the refund window without manager approval to a ~day that would be a big deal.

Ideally we could have a velocity limit on refunds that an employee with the permission can only issue N refunds an hour / or X per day. This prevents someone upset using the Register and refunding everything. (As a refund cannot be reversed, this could erase the sales of an entire business - very unlikely but still a risk we’d like to avoid).

If the api allowed the Team permissions to be edited we could manually monitor refunds and lock the role/permission so all refunds would be blocked.

But the API doesn’t expose any permissions Square Developer

We’re constantly working to improve our features based on feedback like this, so I’ll be sure to share your request to the API product team. :slightly_smiling_face:

Thanks, thinking more:

Technically I think we could implement this crudely with the api disabling someone entirely:

  1. Listen to refunds and velocity per team member
  2. If we see it exceeds what we allow then call UpdateTeamMember endpoint to set status = INACTIVE PUT /v2/team-members/{team_member_id} - Square API Explorer

Q: does that immediately lock out the team member? Would it be within 10 min? (Probably ok). And then after we resolve it can we mark them active again?

Here’s a related discussion in seller community Solved: Re: Limiting Refund Abuse by employees with refund... - The Seller Community

And 3 proposed workarounds (all requiring Square features)

The complexity lies in how our team would handle the setup of a rule-based permission like this.
I think it could be very simple.

  1. Setting of how many # or $ volume refunds to allow in a day or N hour period before. Could be a settable value based on the merchant, for some $1000 may be a very safe limit that shouldn’t ever be hit, and if it was, it’s probably a problem.
  2. Needing someone else to do the refund.

This would be a new permission, “Limited Refund” and if it can’t do it due to hitting a limit anyone with the existing “Refund” permission can do it.

  • OR - likely simpler even:
  1. new “Limited Refund” permission, same as above
  2. This permission only allows refunding over the past N days / hours. That could be hard coded e.g. 7 days or 30 days or it could be a setting. This could have more customer service issues so the above to monitor suspicious / excessive volume behavior would be a safer customer experience probably. (Avoid blocking a valid refund).
  • OR - expose existing permissions on the API, and enterprises that need this can implement revoking a permission from a team member if they see any suspicious things on their side.

Setting the employee profile inactive would disable there ability to function on the POS. You can then reactivate them once the issue is resolved. :slightly_smiling_face:

1 Like

Thanks, appreciate it! Would be curious how quickly it disables after marking them inactive, but we can test this out.