Building a Scalable Digital Membership Card System for Large Organizations
Hello Developers I am exploring how to build a scalable digital membership card system for large organizations and would really appreciate guidance from this community. I am trying to understand how such systems can be designed and implemented in a scalable and secure way. The idea is to allow organizations to issue and manage digital membership cards with features like secure member authentication, API based integration with external systems, QR code based validation, mobile wallet support for digital cards, and a central dashboard for managing memberships at scale. While researching, I came across platforms like MembershipAnywhere that offer digital membership card and member management solutions for large organizations, which helped me understand the possible scope of such systems. What I have done so far is design a basic API flow for issuing membership cards, build a simple prototype for QR based validation, and start researching token based authentication systems. Where I need help is understanding scalable architecture for large scale membership systems, best practices for secure QR or token based validation in real time, how such systems handle synchronization across multiple devices and platforms, and what tools SDKs or design patterns are commonly used for this type of product. I am building this for learning and system design understanding and not for any commercial purpose at this stage. Any guidance from developers who have worked on similar systems would be really helpful9Views0likes0CommentsAccessibility Feature Request: Conversation Focus Mode for Ray-Ban Meta Display Glasses
Hi everyone! I’m a Ray-Ban Meta display glasses user who is hard of hearing and wears hearing aids daily. I’d love to see a conversation focus mode added that prioritizes voices directly in front of the wearer and reduces background noise. In busy environments, this would make a big difference for hearing-aid users and others who rely on clearer speech in real time. If this type of accessibility feature is ever developed, I would absolutely love the ability to have it added to my glasses and would be happy to provide feedback or participate in any beta or user-testing opportunities. I’ve also submitted this through support channels, but wanted to share here in case the team is gathering feedback.163Views1like0CommentsAadvanced matching with pre-hashed PII – clarification on Meta’s expectations
Hi everyone 👋 I’m working on a browser-only setup for conversion tracking and I’d like to double-check a few details specifically on the Meta side (naming, hashing detection, and what the Pixel actually expects). Context the lead/conversion event fires on a thank-you page the user data (email, phone, name…) is collected on the previous page I can’t fire the event on the form page as the tracking wouldn't be always truthful I don’t have a server / CAPI in this flow, so this is 100% client-side To bridge the two pages, I’m doing this: on the form page I collect the user fields I normalize them in two ways (Google-style and Meta-style) I hash the Meta-normalized version with SHA-256 I temporarily store it in sessionStorage on the thank-you page I read it and want to send it with the Meta Pixel event So far, so good. What I’d like to confirm 👇 Does the Pixel reliably accept SHA-256 hashed customer data sent via fbq('track', 'Lead', ..., { …customer data… })? In other words: if I send the customer info already hashed, Meta will still match it, right? Do I need to tell Meta explicitly that the values are already hashed (like a flag or a specific param), or will the Pixel detect it automatically from the format? I know Google makes you use different parameter names for hashed values – I couldn’t find something equally explicit for Meta. What’s the most “standard” way to send hashed user data client-side right now? - plain fbq('track', ...) with customer data object - GTM template (e.g. facebookarchive or Stape style?) - other approach you’ve seen working better in production I’m trying to avoid situations where the template re-hashes what I already hashed and we end up with double-hash and no matching. - In your experience, do current Meta templates auto-hash by default? If yes, is there a clean way to say “I’m already sending hashed values, please don’t touch them”? I’m aware that server-side CAPI would make all of this nicer, but in this scenario I need to stay client-only and make sure I’m not breaking matching just because the actual event is on a different page. Any real-world examples/snippets from would be super helpful 🙏Solved72Views0likes1Comment