प्लेटफ़ॉर्म आर्किटेक्चर

एक कोर, कई सतहें — प्लेटफ़ॉर्म असल में कैसे काम करता है।

लेजर से ऊपर की ओर प्लेटफ़ॉर्म की एक सैर: अकाउंट, KYC, कार्ड और क्रिप्टो, जो एक ही डबल-एंट्री कोर साझा करते हैं; एक पेमेंट create से reconcile तक कैसे चलता है; और ऐप लेयर, ऑपरेटर कंसोल तथा रेगुलेटेड रेखा कहाँ स्थित हैं।

हमसे बात करें प्रोडक्ट देखें

कोर

सबके नीचे एक लेजर।

प्लेटफ़ॉर्म के केंद्र में एक ही अकाउंट लेजर है। हर अकाउंट — कस्टमर वॉलेट, मर्चेंट बैलेंस, फ़ीस अकाउंट, सेटलमेंट अकाउंट — इस लेजर का एक नोड है, और मूल्य की हर गतिविधि एक डबल-एंट्री पोस्टिंग है: एक अकाउंट डेबिट, दूसरा क्रेडिट, और दोनों पक्ष हमेशा बराबर। लेजर append-only है। एंट्री कभी बदली या मिटाई नहीं जातीं; सुधार एक नई, विपरीत एंट्री होती है, इसलिए किसी बैलेंस के मौजूदा मूल्य तक पहुँचने का पूरा इतिहास हमेशा दोबारा बनाया जा सकता है। अकाउंट, KYC स्थिति, जारी किए गए कार्ड और क्रिप्टो एड्रेस सब एक ही अकाउंट मॉडल से जुड़ते हैं। इसी कारण कार्ड ऑथराइज़ेशन, बैंक ट्रांसफ़र और ऑन-चेन डिपॉज़िट बिना अलग-अलग सिस्टम जोड़ने वाली किसी रिकंसिलिएशन लेयर के एक ही बैलेंस पर पोस्ट हो सकते हैं।

01डबल-एंट्री: हर पोस्टिंग संतुलित, डेबिट बराबर क्रेडिट
02Append-only: सुधार नई एंट्री से, एडिट से नहीं
03फ़िएट, कार्ड और क्रिप्टो के लिए एक अकाउंट मॉडल
04KYC स्थिति अकाउंट के साथ चलती है, किसी अलग टेबल में नहीं

एक पेमेंट, शुरू से अंत तक

एक पेमेंट, create से reconcile तक।

पेमेंट एक कॉल नहीं, बल्कि एक छोटा जीवनचक्र है, और हर चरण एक ऐसी स्थिति है जिसे लेजर और आपके सिस्टम दोनों देख सकते हैं। हर स्थिति-बदलाव एक webhook भेजता है, और हर राइट idempotent है — वही key दोबारा भेजने पर वही नतीजा मिलता है, इसलिए रीट्राई किया गया अनुरोध कभी दो बार चार्ज नहीं करता।

01
Create
एक intent खुलता है: राशि, करेंसी, शामिल अकाउंट। अभी कुछ हिला नहीं है — लेजर एक pending एंट्री दर्ज करता है।
02
Authorize
रेल फ़ंड और रिस्क जाँचकर होल्ड लगाती है। कार्ड के लिए यही ऑथराइज़ेशन है; ट्रांसफ़र के लिए डेबिट रिज़र्व हो जाता है।
03
Capture
होल्ड की गई राशि पक्की हो जाती है। लेजर वह डबल-एंट्री पोस्ट करता है जो दोनों अकाउंट के बीच मूल्य असल में हिलाती है।
04
Settle
फ़ंड नीचे की रेल — कार्ड स्कीम, बैंक या चेन — पर क्लियर होते हैं, और सेटलमेंट अकाउंट असली पैसे से रिकंसाइल होते हैं।
05
Reconcile
प्लेटफ़ॉर्म अपनी पोस्टिंग को रेल की सेटलमेंट रिपोर्ट से मिलाता है; जो मेल नहीं खाता, उस पर फ़्लैग लगता है, उसे छिपाया नहीं जाता।

Webhook और idempotency इस फ़्लो के हर सिरे पर हैं। आपके सिस्टम को पेमेंट के हिलने की खबर पोलिंग से नहीं, इवेंट मिलने से होती है, और टाइमआउट के बाद आप जो भी अनुरोध रीट्राई करें, वह अपनी idempotency key के ज़रिए उसी नतीजे पर पहुँचता है, इसलिए दोहराव कभी दो बार चार्ज नहीं करता। ऑथराइज़ और कैप्चर चलाने वाली सर्विस है पेमेंट गेटवे.

ऐप लेयर

ऊपर whitelabel ऐप, नीचे एक प्लेटफ़ॉर्म।

कोर क्षमताएँ उपलब्ध कराता है; ऐप लेयर उन्हें प्रोडक्ट में बदलती है। हर कस्टमर-फ़ेसिंग ऐप — वेब और मोबाइल — एक whitelabel क्लाइंट है जो वही अकाउंट, पेमेंट और कार्ड अपने ब्रांड में दिखाता है। थीमिंग टोकन-आधारित है: रंग, टाइप, रेडियस और स्पेसिंग एक डिज़ाइन-टोकन सिस्टम (PDS) से आते हैं, इसलिए ऑपरेटर ऐप को फ़ोर्क किए बिना, सिर्फ़ टोकन बदलकर पूरी सतह की स्टाइल बदल सकता है। यही प्लेटफ़ॉर्म बहुत अलग दिशाओं में लगाया जा सकता है — कंज़्यूमर नियोबैंक, मर्चेंट एक्वायरिंग ऐप, कार्ड-इश्यूइंग प्रोग्राम, क्रिप्टो on/off-ramp या आंतरिक ऑपरेशंस टूल — और पाँच अलग प्रोडक्ट नहीं बनता। यह एक प्लेटफ़ॉर्म है जो अलग-अलग रूप धारण करता है, हर रूप कॉन्फ़िगर किया गया, दोबारा बनाया नहीं गया।

01साझा API पर whitelabel वेब + मोबाइल क्लाइंट
02टोकन-आधारित थीमिंग (PDS): कॉन्फ़िग से स्टाइल बदलें, फ़ोर्क से नहीं
03पाँच उदाहरण दिशाएँ — नियोबैंक, एक्वायरिंग, इश्यूइंग, ramp, ops
04नई सतहें कॉन्फ़िगर होती हैं, दोबारा नहीं बनतीं

ऑपरेशंस

कंसोल से चलाएँ, कारण रिकॉर्ड पर रखकर।

हर ऐप के पीछे एक ऑपरेटर कंसोल है। यहीं सपोर्ट एजेंट किसी अकाउंट को देखता है, रिस्क एनालिस्ट कार्ड फ़्रीज़ करता है, या ऑपरेशंस लीड कोई पोस्टिंग रिवर्स करता है। रीड एक्सेस व्यापक है; विशेषाधिकार वाली कार्रवाइयाँ नहीं। जो भी कार्रवाई पैसे को हिलाती है, लिमिट बदलती है या कस्टमर के फ़ंड को छूती है, उसे चलने से पहले कारण बताना होता है और वह एक अपरिवर्तनीय ऑडिट एंट्री लिखती है — किसने किया, किस पर, कब और क्यों। एक्सेस least privilege पर चलता है, इसलिए हर ऑपरेटर वही देखता और करता है जो उसकी भूमिका अनुमति देती है। यह मॉडल ऑपरेटर कंसोल Protocore Center में है, और यही रुख प्लेटफ़ॉर्म के हर सिस्टम में बना है: संवेदनशील कार्रवाइयाँ सोच-समझकर होती हैं, किसी के नाम दर्ज होती हैं और बाद में जाँची जा सकती हैं।

01व्यापक रीड, नियंत्रित राइट — विशेषाधिकार वाली कार्रवाइयाँ अपवाद हैं
02फ़ंड छूने वाली हर कार्रवाई से पहले कारण अनिवार्य
03अपरिवर्तनीय ऑडिट ट्रेल: कौन, क्या, कब, क्यों
04हर ऑपरेटर भूमिका के लिए least privilege

क्रिप्टो ब्रिज

क्रिप्टो और फ़िएट, एक ही लेजर पर।

प्लेटफ़ॉर्म पर क्रिप्टो कोई अलग साइलो नहीं है; क्रिप्टो एड्रेस उसी लेजर पर बस एक और अकाउंट है। on/off-ramp किनारे पर फ़िएट और डिजिटल एसेट के बीच बदलाव करता है — कस्टमर कार्ड या ट्रांसफ़र से बैलेंस भरकर क्रिप्टो पाता है, या क्रिप्टो बेचकर बैंक अकाउंट में निकाल लेता है। ऑन-चेन मूल्य बैंक रेल तक सेटल हो सकता है: आने वाला ऑन-चेन पेमेंट अकाउंट में क्रेडिट होता है, कन्वर्ट होता है और IBAN पर पेआउट हो जाता है, इसलिए पाने वाले को साधारण बैंक अकाउंट में साधारण पैसा दिखता है। चूँकि दोनों चरण एक ही डबल-एंट्री लेजर पर पोस्ट होते हैं, जो लेन-देन ऑन-चेन शुरू होकर बैंक ट्रांसफ़र पर खत्म होता है, वह एक ही रिकंसाइल्ड इतिहास है, हाथ से मिलाए गए दो सिस्टम नहीं।

01क्रिप्टो एड्रेस किसी भी अन्य अकाउंट जैसा अकाउंट है
02On/off-ramp: फ़िएट और डिजिटल एसेट का किनारे पर कन्वर्ज़न
03ऑन-चेन सेटलमेंट से IBAN पेआउट तक
04दोनों चरणों का एक रिकंसाइल्ड इतिहास

बिल्ड सतह

API, webhook और बिल्ड करने के लिए sandbox।

ऐप जो कुछ भी करते हैं, एक दस्तावेज़ीकृत API से करते हैं — अकाउंट बनाना, पेमेंट खोलना, कार्ड जारी करना, ramp शुरू करना। उदाहरण के तौर पर कॉल कुछ ऐसे दिखते हैं: POST /v1/wallets या POST /v1/payments; शैली REST है और हर राइट पर एक idempotency key होती है। स्थिति के बदलाव webhook के रूप में पहुँचते हैं, ताकि आपके सिस्टम पोल करने के बजाय इवेंट पर प्रतिक्रिया दें। डेवलपमेंट sandbox टेनेंट पर होता है — प्लेटफ़ॉर्म की अलग-थलग प्रति, टेस्ट रेल के साथ, जहाँ आप असली पैसा हिलाए बिना पूरा create-से-reconcile फ़्लो चला सकते हैं। हर प्रोडक्ट आपको क्या और किस टियर पर देता है, यह उसके access band से तय होता है; प्रोडक्ट पेज बताते हैं कि किसी band में क्या शामिल है।

01दस्तावेज़ीकृत REST API, idempotent राइट
02हर स्थिति-बदलाव पर webhook — इवेंट-आधारित, पोलिंग नहीं
03टेस्ट रेल वाला sandbox टेनेंट, प्रोडक्शन से अलग
04दायरा और लिमिट प्रति-प्रोडक्ट access band से तय

ईमानदार सीमा

Protocore सॉफ़्टवेयर बनाता है। रेगुलेटेड रेखा लाइसेंस के पास है।

पेमेंट प्रोडक्ट दो चीज़ों का मेल है: पैसा रखने और चलाने की रेगुलेटेड अनुमति, और वह सॉफ़्टवेयर जो उसे निर्देश देता, दर्ज करता और रिकंसाइल करता है। Protocore सॉफ़्टवेयर बनाता है। रेगुलेटेड गतिविधि — कस्टमर फ़ंड रखना, अकाउंट जारी करना, स्कीम पर पैसा चलाना — ऑपरेटर के अपने लाइसेंस या किसी लाइसेंसधारी पार्टनर के पास रहती है: बैंक, EMI या पेमेंट इंस्टीट्यूशन। प्लेटफ़ॉर्म इस तरह बना है कि आप जो भी रेगुलेटेड रेल लाएँ, उस पर फ़िट बैठे, और कार्ड डेटा रेल पर ही रहे, आपके सर्वर को कभी न छुए; यह उस अनुमति का विकल्प नहीं है, और कोई सॉफ़्टवेयर नहीं होता। रेगुलेटेड रेखा कहाँ पड़े, यह फ़ैसला आप अपने पार्टनर के साथ करते हैं, और आर्किटेक्चर इसके दोनों ओर सहजता से बैठने के लिए डिज़ाइन किया गया है।