WeChat ऑथेंटिकेशन आणि Guest WiFi Captive Portals चे एकत्रीकरण

सारांश

जेव्हा एखादा चीनी अभ्यागत तुमच्या कॉर्पोरेट नेटवर्कशी कनेक्ट होतो आणि त्याला केवळ ईमेल, Facebook किंवा क्रेडेंशियल कोड ऑफर करणारे Captive Portal दिसते, तेव्हा अडथळा निर्माण होतो. Tencent च्या २०२४ च्या डेटाच्या मते, WeChat कडे १.३८ अब्ज मासिक सक्रिय वापरकर्ते आहेत. अतिथी WiFi सह WeChat लॉगिन समाकलित करणे ही केवळ आदरातिथ्य सुविधा नाही; तर या लोकसंख्येचा फर्स्ट-पार्टी डेटा विनाअडथळा गोळा करण्यासाठी ही एक तांत्रिक आवश्यकता आहे.

हे मार्गदर्शक WeChat OAuth 2.0 ऑथेंटिकेशनला captive portals सोबत समाकलित करण्याच्या तांत्रिक आर्किटेक्चरचे तपशील देते. हे WeChat इन-अॅप ब्राउझरसह मानक मोबाईल ब्राउझरला सपोर्ट करण्यासाठी आवश्यक असलेले ड्युअल-प्लॅटफॉर्म रजिस्ट्रेशन स्पष्ट करते, डेटा संकलनासाठी snsapi_base आणि snsapi_userinfo स्कोपमधील तडजोड आणि मूल्यमापन करते आणि RADIUS Change of Authorization (CoA) किंवा MAC Authentication Bypass चा वापर करून नेटवर्क ॲक्सेस कसा लागू केला जातो याचे वर्णन करते. हे Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme आणि Fortinet इन्फ्रास्ट्रक्चरवर मोठ्या प्रमाणात डिप्लॉयमेंट करण्यासाठी आवश्यक असणारी सुरक्षा कॉन्फिगरेशन्स आणि अनुपालन निर्देश - GDPR आणि चीनचा Personal Information Protection Law (PIPL) - देखील कव्हर करते.

तांत्रिक सखोल माहिती: WeChat OAuth 2.0 आर्किटेक्चर

एक Captive Portal अनऑथेंटिकेटेड डिव्हाइसेसवरील HTTP ट्रॅफिकला अडवते आणि त्यांना पोर्टल सर्व्हरवर होस्ट केलेल्या लँडिंग पेजवर रिडायरेक्ट करते. WeChat ऑथेंटिकेशन जोडल्याने या फ्लोमध्ये OAuth 2.0 प्रोटोकॉलचा वापर करून थर्ड-पार्टी आयडेंटिटी प्रोव्हाइडर समाविष्ट होतो, हा तोच मानक प्रोटोकॉल आहे जो Google, Microsoft Entra ID आणि Okta द्वारे फेडरेटेड आयडेंटिटीसाठी वापरला जातो.

अथेंटिकेशन फ्लो खालीलप्रमाणे काम करतो: एक व्हिजिटर SSID शी कनेक्ट होतो. ॲक्सेस पॉइंट किंवा वायरलेस कंट्रोलर न-ऑथेंटिकेट केलेले सेशन शोधून काढतो आणि HTTP ट्रॅफिकला Captive Portal URL कडे रीडायरेक्ट करतो. व्हिजिटर Portal पेजवर WeChat लॉगिन निवडतो. Portal सर्व्हर ब्राऊझरला open.weixin.qq.com येथील WeChat ऑथरायझेशन एंडपॉईंटवर रीडायरेक्ट करतो, ज्यामध्ये AppID, रीडायरेक्ट URI, code चा रिस्पॉन्स टाईप आणि विनंती केलेली Scope पाठवली जाते. WeChat स्वतःच्या सर्व्हरवर ऑथेंटिकेशन हाताळते. जर व्हिजिटर WeChat च्या बिल्ट-इन ब्राऊझरमध्ये snsapi_base Scope वापरत असेल, तर ऑथेंटिकेशन सायलेंट असते - कोणताही ऑथरायझेशन संमतीचा प्रॉम्ट दिसत नाही. जर snsapi_userinfo वापरले असेल, तर WeChat एक ऑथरायझेशन संमती पेज दाखवते. त्यानंतर WeChat एका तात्पुरत्या ऑथरायझेशन कोडसह पुन्हा Portal च्या रीडायरेक्ट URI कडे रीडायरेक्ट करते. Portal सर्व्हर AppID, AppSecret, कोड आणि authorization_code च्या ग्रँट टाईपसह api.weixin.qq.com/sns/oauth2/access_token वर API कॉल करून या कोडच्या बदल्यात Access Token मिळवतो. WeChat कडून Access Token, Refresh Token, युझरचा OpenID आणि मंजूर केलेली Scope परत मिळते. जर snsapi_userinfo मंजूर झाली असेल, तर सर्व्हर युझरचे टोपणनाव, प्रोफाईल पिक्चर, लिंग आणि शहर मिळवण्यासाठी दुसरा API कॉल सुरू करतो.

Dual-Platform Registration Requirements

बहुतेक अंमलबजावणी नोंदणीच्या टप्प्यावरच अयशस्वी ठरतात. WeChat दोन स्वतंत्र डेव्हलपर प्लॅटफॉर्म चालवते, आणि एंटरप्राइझ डिप्लॉयमेंटसाठी सहसा दोन्हीची आवश्यकता असते.

WeChat च्या इन-ॲप ब्राऊझरमध्ये Portal वापरणाऱ्या व्हिजिटर्ससाठी, तुम्हाला Official Accounts Platform वर Service Account आवश्यक आहे. सबस्क्रिप्शन खाती चालणार नाहीत - त्यांच्याकडे OAuth वेबपेज ऑथरायझेशन परवानग्या नसतात. Android वरील Chrome किंवा iOS वरील Safari वरून Portal वापरणाऱ्या व्हिजिटर्ससाठी, तुम्हाला Open Platform वर Web Application आवश्यक आहे, जे snsapi_login Scope वापरते आणि युझरला स्कॅन करण्यासाठी QR कोड दाखवते.

व्यवहारात, बहुतेक ठिकाणी दोन्ही वापरले जातात. हॉटेलमधील एखादा पाहुणा कदाचित Chrome मध्ये Portal उघडू शकतो, त्याला QR कोड दिसू शकतो, तो WeChat ने तो स्कॅन करू शकतो आणि ऑथेंटिकेट करू शकतो. किंवा ते थेट WeChat मध्ये एखाद्या लिंकवर टॅप करू शकतात, इन-ॲप ब्राऊझरमध्ये जाऊ शकतात आणि snsapi_base द्वारे सायलेंटली ऑथेंटिकेट करू शकतात.

Scope Selection: Data Harvesting vs. User Friction

तुम्ही विनंती करत असलेली scope तुम्ही गोळा करत असलेला डेटा आणि व्हिजिटरला येणाऱ्या अडचणी ठरवते. हा नियम अनुपालनाशी संबंधित असणारा एक व्यावहारिक निर्णय आहे.

snsapi_base फक्त OpenID रिटर्न करते — तुमच्या Official Account अंतर्गत त्या युझरसाठीचा युनिक आयडेंटिफायर. यासाठी युझरच्या संमतीच्या प्रॉम्प्टची गरज नसते. व्हिजिटरसाठी ऑथेंटिकेशन शांतपणे (silent) होते. हे अशा परत येणाऱ्या व्हिजिटर्ससाठी आदर्श आहे ज्यांचे प्रोफाईल तुमच्याकडे आधीपासूनच आहेत, किंवा जेव्हा तुम्ही विनाव्यत्यय ॲक्सेसला प्राधान्य देता. GDPR आणि PIPL डेटा मिनिमायझेशन तत्त्वांनुसार, snsapi_base चे समर्थन करणे खूप सोपे आहे.

snsapi_userinfo OpenID सोबत युझरचे निकनेम, प्रोफाईल पिक्चर, जेंडर (लिंग) आणि शहर रिटर्न करते. यासाठी स्पष्ट ऑथरायझेशन संमती पेज आवश्यक असते. हे पहिल्यांदा येणाऱ्या व्हिजिटरच्या नोंदणीसाठी आदर्श आहे जिथे तुम्हाला प्रोफाईल तयार करायचे असते, जे तुमच्या Portal पेजवरील सुसंगत संमती ओव्हरलेशी जोडलेले असते.

मल्टि-साईट डिप्लोयमेंट्ससाठी UnionID

OpenID हा युझर आणि विशिष्ट Official Account च्या कॉम्बिनेशनसाठी युनिक असतो. २० प्रॉपर्टीज असणारा एक हॉटेल ग्रुप, ज्यातील प्रत्येक प्रॉपर्टी स्वतःचे Official Account चालवत आहे, त्याला एकाच व्हिजिटरसाठी २० वेगवेगळे OpenIDs दिसतील. UnionID या समस्येचे निराकरण करतो. हा एकच आयडेंटिफायर आहे जो एकाच Open Platform अकाउंट अंतर्गत लिंक केलेल्या सर्व Official Accounts आणि ॲप्लिकेशन्सवर युझरचे प्रतिनिधित्व करतो. तुमचे Official Accounts तुमच्या Open Platform अकाउंटशी लिंक करा आणि OAuth रिस्पॉन्समध्ये UnionID रिटर्न केला जाईल. क्रॉस-साईट व्हिजिटर ओळखीसाठी हा पाया आहे.

अंमलबजावणी मार्गदर्शक (Implementation Guide)

नेटवर्क एन्फोर्समेंट मेकॅनिझम्स

फक्त OAuth टोकन मिळवणे ओळख सिद्ध करते; यामुळे नेटवर्क सुरू होत नाही. ट्रॅफिकला परवानगी देण्यासाठी तुम्ही कंट्रोलरला सिग्नल देणे आवश्यक आहे.

RADIUS Change of Authorization (CoA) (RFC 3576 मध्ये परिभाषित) ही शिफारस केलेली एंटरप्राइझ-ग्रेड पद्धत आहे. यशस्वी OAuth व्हॅलिडेशननंतर, Portal सर्व्हर नेटवर्क कंट्रोलरला CoA रिक्वेस्ट पाठवतो. कंट्रोलर डिव्हाइसला प्री-ऑथेंटिकेशन VLAN मधून गेस्ट VLAN मध्ये हलवतो. हे Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme आणि Fortinet ला लागू होते.

MAC Authentication Bypass (MAB) डिव्हाइसचा MAC ॲड्रेस RADIUS डेटाबेसमध्ये ऑथराईज्ड क्लायंट म्हणून नोंदणीकृत करते. कंट्रोलर या MAC वर आधारित ॲक्सेसला परवानगी देतो. MAB ची अंमलबजावणी करणे सोपे आहे परंतु ते कमी विश्वासार्ह आहे: आधुनिक iOS आणि Android डिव्हाइसेस डीफॉल्टनुसार MAC ॲड्रेसेस रँडमाईज करतात, ज्यामुळे पुन्हा कनेक्ट करताना सेशन असोसिएशन खंडित होते.

Purple चे Guest WiFi प्लॅटफॉर्म हे ट्रान्झिशन स्वयंचलित करते. एकदा WeChat OAuth पूर्ण झाले की, Purple चे क्लाउड ओव्हरले नेटवर्क संबंधित हार्डवेअरला योग्य CoA किंवा MAB सिग्नल पाठवते, ज्यामुळे मॅन्युअल VLAN कॉन्फिगरेशनचा त्रास दूर होतो.

सिक्युरिटी कॉन्फिगरेशन

खालील तीन कॉन्फिगरेशन महत्त्वाचे आहेत.

1. AppSecret सुरक्षित ठेवा. AppSecret कधीही क्लायंट-साइड JavaScript मध्ये दिसू नये. तो तुमच्या सर्व्हरवरच राहिला पाहिजे. तडजोड झाल्यास, हल्लेखोर तुमच्या ॲप्लिकेशनचे सोंग घेऊ शकतात आणि तुमच्या वतीने WeChat API कॉल करू शकतात.
2. CSRF प्रोटेक्शन लागू करा. क्रिप्टोग्राफिकरित्या रँडम state व्हॅल्यू जनरेट करा, ती युझर सेशनमध्ये स्टोअर करा आणि WeChat रिडायरेक्ट परत आल्यावर ती व्हॅलिडेट करा. हे RFC 6749 मध्ये परिभाषित केल्यानुसार क्रॉस-साईट रिक्वेस्ट फॉर्जरी हल्ल्यांना प्रतिबंधित करते.
3. सर्व Redirect URI व्हेरिएशन्स रजिस्टर करा. WeChat तुमच्या नोंदणीकृत डोमेनच्या विरूद्ध redirect URI प्रमाणित करते. 40029 एरर (invalid code) टाळण्यासाठी तुम्ही वापरत असलेले प्रत्येक सबडोमेन आणि पाथ व्हेरिएंट (स्टेजिंग एन्व्हायर्नमेंटसह) रजिस्टर करा.

इन-अ‍ॅप ब्राउझर शोधणे (In-App Browser Detection)

WeChat चा इन-अ‍ॅप ब्राउझर एक युझर-एजंट स्ट्रिंग सेट करतो ज्यामध्ये MicroMessenger समाविष्ट असते. तुमच्या Captive Portal ने ही स्ट्रिंग शोधली पाहिजे आणि त्यानुसार मार्ग निर्देशित केला पाहिजे: इन-अ‍ॅप ब्राउझर Official Account फ्लो वापरतो, तर मानक ब्राउझर Open Platform QR कोड फ्लो वापरतात. ही स्ट्रिंग शोधण्यात अयशस्वी ठरल्यास खराब अनुभव किंवा ऑथेंटिकेशन एरर येऊ शकतात.

सर्वोत्तम पद्धती आणि अनुपालन (Best Practices and Compliance)

GDPR अनुपालन

तुम्ही युरोपियन अभ्यागतांना सेवा देत असल्यास किंवा युरोपमध्ये कार्यरत असल्यास, WeChat OAuth द्वारे तुम्ही गोळा करत असलेल्या डेटावर GDPR लागू होतो. तुम्ही एक सुसंगत प्रक्रिया आधार स्थापित केला पाहिजे - सामान्यतः संमती किंवा कायदेशीर स्वारस्य. ऑथेंटिकेशन होण्यापूर्वी, तुम्ही Captive Portal वर स्पष्ट गोपनीयता सूचना दिली पाहिजे. तुम्ही विषय प्रवेश विनंत्या (subject access requests) आणि हटवण्याच्या विनंत्यांना प्रतिसाद दिला पाहिजे. तपशीलवार अनुपालन फ्रेमवर्कसाठी, Compliance Playbook: GDPR and Guest WiFi Data Privacy पहा.

PIPL अनुपालन

जेव्हा तुम्ही चीनी नागरिकांचा वैयक्तिक डेटा हाताळता, तेव्हा चीनी वैयक्तिक माहिती संरक्षण कायदा (PIPL) लागू होतो. GDPR प्रमाणेच, PIPL साठी स्पष्ट उद्देश मर्यादा, डेटा मिनिमायझेशन आणि लिखित कायदेशीर आधार आवश्यक आहे. डेटा मिनिमायझेशनच्या तत्त्वांतर्गत, snsapi_userinfo पेक्षा snsapi_base चे समर्थन करणे खूप सोपे आहे. तुम्ही जो काही डेटा गोळा कराल, लाइव्ह जाण्यापूर्वी तुमचा कायदेशीर आधार आणि धारणा कालावधी (retention periods) दस्तऐवजीकरण करा.

नेटवर्क आयसोलेशन (Network Isolation)

कॉर्पोरेट नेटवर्कपासून गेस्ट WiFi ट्रॅफिक वेगळे करण्यासाठी VLAN सेगमेंटेशन वापरा. WeChat द्वारे ऑथेंटिकेट केलेल्या पाहुण्यांना समर्पित गेस्ट VLAN वर ठेवले पाहिजे ज्यामध्ये फक्त इंटरनेटचा अ‍ॅक्सेस असेल - अंतर्गत सिस्टमचा अ‍ॅक्सेस नसेल. हे कार्डहोल्डर डेटा एन्व्हायर्नमेंट आयसोलेशन आणि सामान्य कॉर्पोरेट सुरक्षा पद्धतींसाठी PCI-DSS आवश्यकतांशी सुसंगत आहे. आयसोलेशन आर्किटेक्चरबद्दल अधिक माहितीसाठी, Bandwidth Management: A Practical Guide for 2026 पहा.

फॉलबॅक ऑथेंटिकेशन

WeChat चा API अनुपलब्ध असल्यास, तुमच्या पोर्टलने पर्यायी लॉगिन पद्धतीवर रिडायरेक्ट केले पाहिजे. पाहुण्यांना रिकाम्या स्क्रीनकडे पाहत सोडू नका. ईमेल किंवा SMS फॉलबॅक प्रदान केल्याने सातत्य सुनिश्चित होते. हे विशेषतः Transport आणि Healthcare एन्व्हायर्नमेंट्समध्ये अत्यंत महत्त्वाचे आहे, जेथे नेटवर्क कनेक्टिव्हिटी हे सेवा बंधन आहे.

वास्तविक जगातील केस स्टडीज

हॉस्पिटॅलिटी: लक्झरी हॉटेल ग्रुप

लंडनमधील एका ४०० खोल्यांच्या लक्झरी हॉटेलमध्ये मुख्य भूप्रदेश चीनमधील (mainland China) मोठ्या संख्येने पाहुणे येत होते. त्यांच्या मूळ Captive Portal ला ईमेल पत्ता आणि SMS पडताळणीची आवश्यकता होती. चिनी मोबाईल क्रमांकांना युरोपियन वाहकांकडून (carriers) वारंवार SMS मिळत नव्हते आणि अनेक पाहुण्यांच्या उपकरणांवर स्थानिक ईमेल खाती कॉन्फिगर केलेली नव्हती. यामुळे पोर्टल सोडण्याचा (abandonment) दर ६०% इतका जास्त होता.

हॉटेलने Official Accounts प्लॅटफॉर्मवर एक सर्व्हिस अकाउंट आणि Open Platform वर एक वेबसाइट ॲप्लिकेशन नोंदणीकृत केले. पोर्टलने MicroMessenger युझर-एजंट शोधून काढला आणि इन-ॲप ब्राउझर युझर्ससाठी snsapi_base ट्रिगर केले - ज्यामुळे त्यांना कोणत्याही ऑथोरायझेशन प्रॉम्प्टशिवाय तीन सेकंदांपेक्षा कमी वेळात जोडले गेले. Chrome किंवा Safari वापरणाऱ्या पाहुण्यांना QR कोड दाखवला गेला. पुढील भेटींवर, सिस्टमने समान OpenID ओळखला आणि कोणतीही क्रेडेन्शियल्स न मागता पाहुण्याला शांतपणे ऑथेंटिकेट केले. हॉटेलच्या CRM ने पाहुण्याच्या परत येण्याची नोंद केली, ज्यामुळे आगमनापूर्वीचे लक्ष्यित संभाषण करणे शक्य झाले. हॉस्पिटॅलिटीमध्ये WiFi तैनात करण्याबद्दल अधिक माहितीसाठी, Hospitality पहा.

रिटेल: शॉपिंग सेंटर ॲनालिटिक्स

एका मोठ्या शॉपिंग सेंटरला भाडेकरूंचे मिश्रण (tenant mix) आणि मार्केटिंग धोरणे ठरवण्यासाठी चिनी ग्राहकांकडून लोकसंख्याशास्त्रीय (demographic) माहिती मिळवायची होती. त्यांना त्यांचे मूळ शहर, लिंग आणि भेटींची वारंवारता समजून घेणे आवश्यक होते. येथे, snsapi_base अपुरे होते - त्यांना snsapi_userinfo ची आवश्यकता होती. पोर्टलने पूर्ण userinfo कव्हरेजची विनंती केली. पाहुण्यांना WeChat ऑथोरायझेशन प्रॉम्प्ट दिसला आणि त्यांनी 'allow' वर क्लिक केले. शॉपिंग सेंटरच्या ॲनालिटिक्स प्लॅटफॉर्मने, जे Purple च्या WiFi Analytics सोबत समाकलित (integrate) आहे, पडताळणी केलेल्या लोकसंख्याशास्त्रीय डेटाचा प्रवाह प्राप्त केला. शनिवारच्या दुपारी, ४०% WiFi युझर्स एका विशिष्ट प्रदेशातील होते. या डेटाचा थेट परिणाम पॉप-अप ॲक्टिव्हेशन्ससाठी कोणत्या ब्रँड्सशी संपर्क साधायचा यावर झाला. रिटेल WiFi उपयोजनांबद्दल (deployments) अधिक माहितीसाठी, Retail पहा.

-

त्रुटी निवारण (Troubleshooting) आणि जोखीम कमी करणे

WeChat OAuth Captive Portal उपयोजनांमधील पाच सर्वात सामान्य त्रुटी खालीलप्रमाणे आहेत:

Redirect URI विसंगती (Error 40029). WeChat नोंदणीकृत डोमेनच्या विरूद्ध redirect URI ची पडताळणी करते. सबडोमेन, पाथ किंवा प्रोटोकॉलमधील कोणत्याही विसंगतीमुळे कोड एक्सचेंज अयशस्वी होईल. स्टेजिंग वातावरणासह सर्व व्हेरिएंट्सची नोंदणी करा.

AppSecret उघड होणे. क्लायंट-साइड कोडमध्ये AppSecret एम्बेड करणे ही सर्वात गंभीर सुरक्षा चूक आहे. कृपया सर्व टोकन एक्सचेंज लॉजिक सर्व्हर बाजूला हलवा.

CSRF संरक्षणाचा अभाव. state पॅरामीटर पडताळणीकडे दुर्लक्ष केल्याने पोर्टल Cross-Site Request Forgery हल्ल्यांसाठी असुरक्षित राहते. प्रति सेशन एक क्रिप्टोग्राफिक यादृच्छिक (random) मूल्य तयार करा आणि कॉलबॅकवर त्याची पडताळणी करा.

इन-ॲप ब्राउझर शोधण्यात अपयश. युझर एजंटमध्ये MicroMessenger शोधण्यात अपयशी ठरल्यास इन-ॲप ब्राउझर युझर्सना चुकीचा OAuth फ्लो दाखवला जाईल, ज्यामुळे त्रुटी निर्माण होतील. MAC address randomisation मुळे MAB सेशन्स खंडित होतात. आधुनिक मोबाईल ऑपरेटिंग सिस्टम्स MAC addresses यादृच्छिक (randomise) करतात. MAB अंमलबजावणीवर अवलंबून असणारे पाहुणे पुन्हा कनेक्ट झाल्यावर त्यांचे सेशन गमावतील. विश्वसनीय सेशन व्यवस्थापनासाठी RADIUS CoA वर अपग्रेड करा. सुरक्षित WiFi कॉन्फिगरेशनच्या मार्गदर्शनासाठी, What is Secure WiFi: The 2026 Enterprise Essential Guide पहा.

ROI आणि व्यावसायिक प्रभाव

पाहुण्यांच्या WiFi साठी WeChat लॉगिन तैनात केल्याने तीन मोजण्यायोग्य प्रभाव मिळतात.

सुधारित प्रमाणीकरण (authentication) दर. SMS पडताळणीतील त्रुटी आणि ईमेल इनपुटची आवश्यकता दूर केल्याने यशस्वीरित्या कनेक्ट होणाऱ्या चीनी अभ्यागतांचे प्रमाण वाढते. WeChat सपोर्ट नसलेल्या Captive Portals साठी, ६०% अर्धवट सोडण्याचा (abandonment) दर हे एक वास्तववादी बेसलाईन आहे.

फर्स्ट-पार्टी डेटा गुणवत्ता. WeChat-व्हेरिफाइड प्रोफाईलमध्ये वैध OpenID समाविष्ट असतो आणि snsapi_userinfo द्वारे सोशल प्लॅटफॉर्मवरील डेमोग्राफिक वैशिष्ट्यांमध्ये थेट प्रवेश मिळतो. हा डेटा थर्ड-पार्टी कुकीजवर अवलंबून न राहता लक्ष्यित मार्केटिंग चालवण्यासाठी अ‍ॅनालिटिक्स प्लॅटफॉर्ममध्ये समाविष्ट केला जाऊ शकतो.

कमी झालेला सपोर्ट ओव्हरहेड. अखंड लॉगिनमुळे आंतरराष्ट्रीय अभ्यागतांच्या कनेक्शन समस्यांचे निवारण करण्यासाठी फ्रंट डेस्क आणि आयटी सपोर्ट स्टाफवरील कॉल्सचे प्रमाण कमी होते.

Purple ८०,००० पेक्षा जास्त ठिकाणी कार्यरत आहे आणि २०२४ मध्ये ४४ कोटी logins प्रक्रिया केले आहेत (Purple अंतर्गत डेटा). हा प्लॅटफॉर्म ISO 27001 प्रमाणित, GDPR आणि CCPA चे पालन करणारा आहे आणि ९९.९९९% अपटाइम राखतो. Retail आणि Hospitality क्षेत्रातील ठिकाणांसाठी, WeChat प्रमाणीकरण नेटवर्कला खर्च केंद्रातून एका मजबूत फर्स्ट-पार्टी डेटा कॅप्चर चॅनेलमध्ये रूपांतरित करते.