How to include trust status in Memberstack webhooks for managing fraudulent users in an external system? Answered
I'd like to include the trust-status in my updated member webhook. What is the field name (e.g. trust-status) and what are the specific values of each trust status (e.g. default, trusted, banned)? Also, do I need to specify this in customFields, meta data or other?
We have a external system that manages our member transactions and we're using webhooks to create and maintain those records (e.g. orders that relate to a member).
There is a fair amount of fraud in our industry and the best advice I've found on managing fraudsters is to keep them off your platform in the first place. Thus we have partners integrated with our main system to check for fraudulent signals based on email or mobile number.
Thus when we determine someone shouldn't be a member, Trust Status = banned seems like a good way to keep them off the platform. Being able to manage those banned users in our system would be great (e.g. include it in the update webhook) and being able to change the value in our system and update the Memberstack record would be even better.
Comments
4 comments
Love it! Makes total sense. As a fall back - if the banned tag does't work I recommend using Metadata to store that information instead. You can reference it in the frontend or backend, but it's only editable in the backend.
https://docs.memberstack.com/hc/en-us/articles/7389627062299-Understanding-Member-Data-[…]_M18GBY4NJ0%2AMTczMzQxNDM5OC42My4wLjE3MzM0MTQzOTguNjAuMC4w
We're going to need Josh Lopez or Julian Galluzzo’s input on that one 😁 My dev knowledge is pretty limited once you get into the details
Good idea. While I've got you, when editing the custom transformations within a webhook, when I return to edit again the previous edits don't pull up. Even though they don't show when editing again do they save? Just want to make sure I'm understanding correctly how to package the payload of the webhook with custom fields.
Josh Lopez / Julian Galluzzo I'm using Make.com's Memberstack App to webhook new members into Salesforce as Person Accounts.
Thought I'd share how Memberstack integrates into this process since Person Accounts are not commonly documented in SFDC or online.
Person Accounts are technically both Accounts and Contacts at the same time. The recommended approach for creating Person Accounts is to create them as Account Records with the Record Id of a Person Account. This is somewhat counterintuitive as we think of Contacts as people and Accounts as companies.
This works if you implement it as:
Create a Memberstack Webhook via Make.com to upsert new members as Account records with the matching identifier being the Memberstack Id field on the Account Record (external Id so that is indexed).
Create a Memberstack Webhook via Make.com to upsert updated member profiles as Contact records with the matching identifier being the Memberstack Id field on the Contact Record (external Id).
This seems counterintuitive because you're creating the member as an Account and subsequently updating the member via their Contact record. However, by specifying the Person Account record type via the Member Creation, SFDC automatically creates the Contact record.
It also seems odd to do an upsert instead of an update but when doing an update Make.com/SFDC require you to use the SFDC Id as the unique record identifier. However, as an update only occurs after the initial creation I don't see any downside to this.
It doesn't appear that I can push the Trust value via this process as the Trust key:value pair isn't included in the Update payload.
If you have a solution how to do this via JSON please forward.
I talked it over with Claude.ai and it recommended creating the trust status field using Metadata, JSON, or custom fields during the creation step.
If that's not good advice, hopefully Julian or Josh can jump in to advise 😁 And here's the link to the JSON docs you asked for. https://docs.memberstack.com/hc/en-us/articles/15719004543643-Using-Member-JSON-Data-with-Memberstack-s-DOM-Package
Hello,
I have read the whole thread I'm not sure I understand the problem yet. I'll try to focus only on the Memberstack part of it 🤔
I think what you need is to be able to determine if the person is trusted by using a trust status, right? If that's so, since fraud is a high concern, I would recommend you to store the key value pair in the metadata of each user. These fields can only be updated via the backend, or to restrict a custom field to admin-only to prevent user access via the frontend. Internally you can document and validate what values are you expected to obtain, since this fields only store plain text.
Webhooks are triggered via update or creation of members, and their responses are equivalent to the payload that was sent to update or create the users. If you need to update or create a new users (with specific fields), you can use a different module in Make that triggers a create or update action and in there you can update the field that you want to make.
Please sign in to leave a comment.