प्रॉम्प्ट-टू-पे वह प्रक्रिया है जिसे हर मोबाइल मनी ग्राहक बिना सोचे अपने हाथों से जानता है। मर्चेंट पैसे माँगता है, ग्राहक के फ़ोन पर एक प्रॉम्प्ट आता है, वह PIN डालता है, और काम हो जाता है। जिन बाज़ारों ने मोबाइल मनी को जल्दी अपनाया, वहाँ यह सबसे ज़्यादा इस्तेमाल होने वाला भुगतान तरीका है, और यह बिल्कुल सहज लगता है। यह सहजता अदृश्य रहने के लिए कड़ी मेहनत करने वाली हैरान कर देने वाली इंजीनियरिंग का नतीजा है। किसी भी हिस्से में गलती हुई, तो जादू दोहरी कटौती, अटके भुगतान, या ऐसे मर्चेंट में बदल जाता है जिसने कभी न पहुँचे पैसे के बदले सामान दे दिया।
प्रॉम्प्ट के पीछे असल में यह होता है, और इसे तुरंत, सुरक्षित और दोहरी कटौती से मुक्त बनाने के लिए यह चाहिए।
प्रॉम्प्ट आने के दो तरीके
"प्रॉम्प्ट आता है" के पीछे दो तंत्र हैं, और वे मायने रखते हैं क्योंकि उनकी पहुँच और विफलता के तरीके अलग-अलग हैं।
पारंपरिक तंत्र है SIM एप्लिकेशन टूलकिट (STK): SIM कार्ड पर ही चलने वाला कोड, इसलिए यह बिना किसी ऐप वाले साधारण फ़ीचर फ़ोन पर भी सुरक्षित PIN प्रॉम्प्ट भेज सकता है। शुरुआती मोबाइल मनी सिस्टम STK के ज़रिए ही हर किसी तक पहुँचे: मेनू और PIN डालना SIM से, नेटवर्क के ज़रिए, ऐसे हार्डवेयर पर चलते हैं जिस पर और कुछ नहीं होता। आधुनिक तंत्र है ऐप पुश: स्मार्टफ़ोन ऐप को भेजी गई सूचना जो पुष्टि स्क्रीन खोलती है। दोनों एक ही जगह खत्म होते हैं: ग्राहक अनुमति देता है, और एक चार्ज अपने जीवनचक्र से गुज़रता है। बनाने लायक प्लेटफ़ॉर्म दोनों को सपोर्ट करता है, क्योंकि ग्राहक दोनों का इस्तेमाल करते हैं।
चार्ज एक स्टेट मशीन है
प्रॉम्प्ट-टू-पे का सबसे अहम विचार यह है कि चार्ज कोई घटना नहीं है: यह एक स्टेट मशीन है, जिसमें स्थितियों और बदलावों का एक स्पष्ट, सुपरिभाषित समूह होता है। इसे "भेजो और भूल जाओ" कॉल मानना ज़्यादातर प्रोडक्शन घटनाओं की जड़ है। स्थितियाँ मोटे तौर पर ये हैं:
- लंबित: मर्चेंट ने चार्ज का अनुरोध किया है; प्रॉम्प्ट भेजा गया है; सिस्टम ग्राहक का इंतज़ार कर रहा है।
- अधिकृत: ग्राहक ने PIN डालकर पुष्टि की; सिस्टम ने बैलेंस और सीमाएँ जाँच ली हैं और लेन-देन दर्ज कर रहा है।
- पूर्ण: लेजर ने संतुलित एंट्री दर्ज कर दी हैं; पैसा चला गया है; मर्चेंट सामान दे सकता है।
- अस्वीकृत / समाप्त / विफल: ग्राहक ने मना किया, प्रॉम्प्ट का समय खत्म हुआ, या कोई जाँच विफल हुई; कोई पैसा नहीं गया, और चार्ज साफ़-सुथरे ढंग से बंद हो गया।
हर चार्ज किसी भी पल इनमें से ठीक एक स्थिति में होता है, और केवल परिभाषित बदलावों के ज़रिए ही आगे बढ़ सकता है। यह नौकरशाही नहीं है: यही प्रक्रिया को समझने योग्य और सुधारने योग्य बनाता है। जब कुछ गलत होता है, तो सवाल हमेशा यही होता है कि "यह चार्ज किस स्थिति में है, और कौन-सा बदलाव अटका?", एक ऐसा सवाल जिसका जवाब है, कंधे उचकाने के बजाय।
मर्चेंट को नतीजा कैसे पता चलता है
मर्चेंट के सिस्टम को जानना होता है कि चार्ज पूरा हुआ या नहीं: रसीद छापने, सामान देने, ऑर्डर अपडेट करने के लिए। जानने के दो तरीके हैं, और इनका अंतर सुस्त और चुस्त इंटीग्रेशन का अंतर है।
- पोलिंग। मर्चेंट बार-बार स्टेटस एंडपॉइंट से पूछता है, "हो गया?" यह काम करता है, पर फ़िज़ूल और धीमा है: बहुत बार पूछेंगे तो API पर बोझ पड़ेगा; बहुत कम पूछेंगे तो ग्राहक काउंटर पर खड़ा इंतज़ार करेगा।
- वेबहुक। चार्ज की स्थिति बदलते ही प्लेटफ़ॉर्म मर्चेंट को एक हस्ताक्षरित कॉलबैक भेजता है। मर्चेंट को पल भर में पता चल जाता है, कोई फ़िज़ूल कॉल नहीं होती, और काम करने के लिए एक साफ़ इवेंट मिलता है। यही सही आधार है, और अच्छा प्लेटफ़ॉर्म इसे डिफ़ॉल्ट बनाता है, पोलिंग को बैकअप के रूप में रखते हुए।
इसे भरोसेमंद क्या बनाता है
तीन गुण एक चलते हुए डेमो को ऐसे सिस्टम में बदलते हैं जिस पर मर्चेंट अपना व्यवसाय खड़ा कर सके।
आइडेम्पोटेंसी: दोहरी कटौती का इलाज
नेटवर्क दोबारा कोशिश करते हैं। अगर मर्चेंट का "चार्ज बनाओ" अनुरोध टाइमआउट हो जाए और वह उसे दोबारा भेजे, तो दूसरा चार्ज नहीं बनना चाहिए। हर चार्ज-निर्माण अनुरोध में एक आइडेम्पोटेंसी कुंजी होती है; प्लेटफ़ॉर्म उसे दर्ज करता है, और उसी कुंजी से दोहराया गया अनुरोध नया चार्ज शुरू करने के बजाय मूल चार्ज लौटाता है। यही अनुशासन पुष्टि वाले चरण की भी रक्षा करता है। ग्राहक जो भरोसा महसूस करता है, "मुझसे सिर्फ़ एक बार पैसे कटे", वह यही गुण है, जो उस बिंदु पर लागू होता है जहाँ पैसा चलता है, ऐप में कोई उम्मीद भरी जाँच नहीं।
हस्ताक्षरित वेबहुक
वेबहुक एक बिन माँगी HTTP कॉल है जो मर्चेंट के सर्वर पर आकर दावा करती है कि भुगतान पूरा हो गया। वह इस पर भरोसा क्यों करे? क्योंकि हर कॉलबैक हस्ताक्षरित होता है: एक HMAC-SHA256 हस्ताक्षर, जो सामग्री पर उस साझा रहस्य से गिना जाता है जिसे सिर्फ़ प्लेटफ़ॉर्म और मर्चेंट जानते हैं। मर्चेंट हस्ताक्षर दोबारा गिनता है और मेल न खाने वाली हर चीज़ को अस्वीकार करता है, जिससे नकली "आपको भुगतान मिल गया" कॉलबैक हमलावर के किसी काम के नहीं रहते। और क्योंकि नेटवर्क विफल होते हैं, वेबहुक बढ़ते अंतराल के साथ तब तक दोबारा भेजे जाते हैं जब तक प्राप्ति की पुष्टि न हो, ताकि मर्चेंट की ओर क्षणिक रुकावट से इवेंट खो न जाए: सर्वर के सफलता लौटाने तक उसे दोबारा पहुँचाया जाता है।
समाप्ति
बिना पुष्टि वाला चार्ज हमेशा लटका नहीं रह सकता। अगर ग्राहक PIN डाले बिना चला जाए, तो चार्ज को साफ़-सुथरे ढंग से समाप्त होना चाहिए, न कि एक खुली देनदारी बनकर बैठा रहना जो एक घंटे बाद रहस्यमय ढंग से पूरी हो जाए। एक सीमित और अनुमान योग्य समाप्ति अवधि ही मर्चेंट के नज़रिए को ग्राहक के नज़रिए से मेल खाती रखती है।
किनारे के मामले जो असली सिस्टम को डेमो से अलग करते हैं
खुशहाल रास्ता (भेजना, पुष्टि, पूरा) काम का आसान चौथाई हिस्सा है। दिलचस्प विफलताएँ दरारों में रहती हैं:
- ग्राहक पुष्टि करता है, पर नेटवर्क पावती गिरा देता है। प्लेटफ़ॉर्म पर चार्ज
completedहै; मर्चेंट को खबर नहीं मिली। वेबहुक का दोबारा भेजा जाना ठीक इसी के लिए है। मर्चेंट का हैंडलर भी अपनी ओर से आइडेम्पोटेंट होना चाहिए, ताकि दोबारा पहुँचा "पूर्ण" इवेंट सामान दो बार न भिजवाए। - दो पुष्टियाँ एक साथ आती हैं। दोबारा भेजी गई पुष्टि दो बार दर्ज नहीं होनी चाहिए। आइडेम्पोटेंसी कुंजी और स्टेट मशीन मिलकर सुनिश्चित करती हैं कि दूसरी पुष्टि पैसा फिर से भेजने के बजाय "पहले ही पूर्ण" देखे।
- ठीक उसी पल चार्ज समाप्त होता है जब ग्राहक पुष्टि करता है। स्टेट मशीन को एक ही विजेता तय करना होगा: बदलाव परमाणु (एटॉमिक) है, इसलिए चार्ज या तो अधिकृत है या समाप्त, दोनों कभी नहीं, और ग्राहक को साफ़ बताया जाता है कि कौन-सा।
- मिलान। दिन के अंत में हर
completedचार्ज संतुलित लेजर एंट्री के एक सेट और एक सेटलमेंट रिकॉर्ड से मेल खाना चाहिए। क्योंकि चार्ज का जीवनचक्र और लेजर जुड़े हुए हैं, पूरा होना ही पोस्टिंग है, इसलिए मिलान जाँच-पड़ताल से नहीं, बनावट से ही हो जाता है।
एक उदाहरण समय-रेखा
जब कोई मर्चेंट किराने के लिए ग्राहक से 1,250 चार्ज करता है, तो सेकंड-दर-सेकंड यह होता है। समय सामान्य हैं, गारंटीशुदा नहीं।
| समय | क्या होता है | चार्ज की स्थिति |
|---|---|---|
| 0.0 से | कैशियर ग्राहक का नंबर और राशि डालता है; काउंटर आइडेम्पोटेंसी कुंजी के साथ चार्ज-निर्माण अनुरोध भेजता है | लंबित |
| 0.3 से | प्लेटफ़ॉर्म मर्चेंट और ग्राहक को सत्यापित करता है और प्रॉम्प्ट भेजता है | लंबित |
| 2–20 से | ग्राहक मर्चेंट का नाम और राशि पढ़कर PIN डालता है | लंबित |
| +0.2 से | कोर PIN, बैलेंस और सीमाएँ जाँचता है, और संतुलित एंट्री दर्ज करता है | पूर्ण |
| +0.5 से | हस्ताक्षरित वेबहुक मर्चेंट तक पहुँचता है; ग्राहक और मर्चेंट को पुष्टि मिलती है | पूर्ण |
| बाद में | मर्चेंट का बैलेंस उसके शेड्यूल के अनुसार बैंक में सेटल होता है | पूर्ण, सेटल |
ज़्यादातर समय ग्राहक के पढ़ने और टाइप करने में जाता है। प्लेटफ़ॉर्म जो कुछ करता है वह एक सेकंड से काफ़ी कम समय लेता है, इसीलिए काम करने पर अनुभव तुरंत लगता है, और कभी-कभार आने वाला धीमा चरण तुरंत नज़र आता है।
मर्चेंट की ओर का हिस्सा सही बनाना
भरोसेमंद प्रॉम्प्ट-टू-पे इंटीग्रेशन का आधा हिस्सा मर्चेंट के सिस्टम में होता है। एक अच्छा वेबहुक हैंडलर:
- सामग्री की किसी भी चीज़ पर भरोसा करने से पहले हस्ताक्षर सत्यापित करता है।
- आइडेम्पोटेंट होता है: एक ही इवेंट की दूसरी डिलीवरी कुछ नहीं बदलती।
- जल्दी जवाब देता है और भारी काम बाद में करता है, ताकि प्लेटफ़ॉर्म टाइमआउट होकर बेवजह दोबारा कोशिश न करे।
- चार्ज रेफ़रेंस से मिलान करता है, कभी सिर्फ़ राशि और फ़ोन नंबर से नहीं।
- अगर अपेक्षित अवधि में कोई इवेंट न आए, तो विफलता मानने के बजाय स्टेटस एंडपॉइंट पर लौटता है।
- मिलने वाले हर इवेंट को लॉग करता है, ताकि विवादों का जवाब रिकॉर्ड से दिया जा सके।
समाप्ति अवधि चुनना
समाप्ति एक संतुलन है। बहुत छोटी हो, तो फ़ोन ढूँढ रहे ग्राहक पुष्टि से पहले ही चार्ज को खत्म होता देखते हैं। बहुत लंबी हो, तो मर्चेंट काउंटर पर सामान रखे इंतज़ार करते हैं, और पुराने प्रॉम्प्ट ग्राहक के जाने के बाद पहुँचते हैं। ज़्यादातर ऑपरेटर आमने-सामने भुगतान के लिए एक से दो मिनट चुनते हैं, और दूर से भेजे अनुरोधों के लिए, जैसे घर बैठे ग्राहक को भेजा गया बिल, इससे ज़्यादा। अवधि जो भी हो, उसे दिखाएँ: जो कैशियर जानता है कि प्रॉम्प्ट एक मिनट चलता है, वह जानता है कि दोबारा कब कोशिश करनी है।
ग्राहक जिन बारीकियों पर ध्यान देते हैं
प्रॉम्प्ट स्क्रीन के छोटे-छोटे विकल्प तय करते हैं कि ग्राहक उस पर भरोसा करेंगे या नहीं:
- मर्चेंट का पंजीकृत नाम दिखाएँ, कोई आंतरिक कोड नहीं, ताकि ग्राहक जानें कि कौन माँग रहा है।
- PIN फ़ील्ड से पहले राशि और रेफ़रेंस साफ़ दिखाएँ।
- अस्वीकार करने का स्पष्ट विकल्प दें, ताकि जिसे प्रॉम्प्ट की उम्मीद नहीं थी वह उसे अनदेखा करने के बजाय मना कर सके।
- शब्दों में और संदेश से पुष्टि करें: मर्चेंट, राशि और रेफ़रेंस वाली रसीद, स्क्रीन पर और SMS से।
- अनपेक्षित प्रॉम्प्ट के बारे में चेतावनी दें। धोखेबाज़ इस उम्मीद में प्रॉम्प्ट भेजते हैं कि ग्राहक आदतन मंज़ूरी दे देगा; "केवल तभी मंज़ूरी दें जब आप इस मर्चेंट को भुगतान कर रहे हों" जैसी छोटी पंक्ति यह जोखिम घटाती है।
एक जीवनचक्र, हर चैनल
इसे सही करने का आख़िरी हिस्सा यह है कि प्रॉम्प्ट-टू-पे ऐप, काउंटर और API में अलग-अलग जोड़ा गया कोई विशेष मामला न हो। यह एक ही चार्ज जीवनचक्र होना चाहिए जिसे हर चैनल चलाए: मर्चेंट का QR स्कैन करता ग्राहक, POS से चार्ज भेजता मर्चेंट, और डेवलपर API को कॉल करता पार्टनर, सभी एक ही तरह का चार्ज बनाते हैं, जो उन्हीं स्थितियों से गुज़रता है, उसी लेजर में दर्ज होता है, और वही हस्ताक्षरित वेबहुक भेजता है। इसे एक बार, सही ढंग से बनाइए, और हर चैनल को ये गारंटियाँ विरासत में मिलती हैं।
प्रॉम्प्ट-टू-पे, QR या टिल नंबर?
प्रॉम्प्ट-टू-पे ग्राहक से पैसे लेने के तीन आम तरीकों में से एक है। हर तरीका अलग स्थिति के लिए ठीक है:
| तरीका | कौन शुरू करता है | साधारण फ़ोन पर चलता है | किसके लिए सबसे अच्छा |
|---|---|---|---|
| प्रॉम्प्ट-टू-पे | मर्चेंट | हाँ, SIM-आधारित प्रॉम्प्ट से | काउंटर और चेकआउट जहाँ मर्चेंट को राशि पता है |
| QR कोड | ग्राहक स्कैन करता है | नहीं, स्मार्टफ़ोन ऐप चाहिए | ज़्यादा स्मार्टफ़ोन ग्राहकों वाली दुकानें; छोटे व्यापारियों के लिए स्थिर कोड |
| टिल या पे बिल नंबर | ग्राहक डालता है | हाँ, USSD से | कोई भी मर्चेंट; सबके लिए विकल्प |
मर्चेंट सबसे अच्छा तब करते हैं जब वे तीनों स्वीकार कर सकें, और प्लेटफ़ॉर्म इन्हें अलग-अलग रास्तों से आने वाला एक ही तरह का भुगतान माने।
प्रॉम्प्ट से जुड़ी धोखाधड़ी
क्योंकि प्रॉम्प्ट ग्राहक से भुगतान मंज़ूर करने को कहता है, यह सोशल इंजीनियरिंग को आकर्षित करता है। आम तरीका यह है कि धोखेबाज़ प्रॉम्प्ट भेजता है और फिर सेवा प्रदाता बनकर ग्राहक को फ़ोन करता है और उसे मंज़ूरी देने के लिए राज़ी करता है। बचाव कई स्तरों पर काम करता है: माँगने वाले मर्चेंट का सत्यापित नाम प्रमुखता से दिखाएँ; सीमित करें कि कोई मर्चेंट कम समय में एक ही नंबर पर कितने प्रॉम्प्ट भेज सकता है; ऐसे मर्चेंटों पर नज़र रखें जिनके प्रॉम्प्ट ज़्यादातर अस्वीकार या रिपोर्ट होते हैं; और ग्राहकों को बार-बार बताएँ कि सेवा प्रदाता उनसे कभी फ़ोन पर भुगतान मंज़ूर करने को नहीं कहेगा। मर्चेंट ऑनबोर्डिंग भी मायने रखती है, क्योंकि ट्रेस होने योग्य पहचान वाला सत्यापित मर्चेंट धोखाधड़ी के लिए खराब औज़ार है।
प्रॉम्प्ट-टू-पे को मापना
| मापदंड | क्यों मायने रखता है |
|---|---|
| मंज़ूरी दर | ग्राहक जितने प्रॉम्प्ट मंज़ूर करते हैं उसका हिस्सा; अचानक गिरावट डिलीवरी की समस्या या भ्रम की ओर इशारा करती है |
| मंज़ूरी में लगने वाला समय | ग्राहक कितना समय लेते हैं; लंबा समय अस्पष्ट स्क्रीन या धीमी डिलीवरी का संकेत है |
| समाप्ति दर | बिना जवाब खत्म होने वाले प्रॉम्प्ट; समाप्ति अवधि और कैशियर के निर्देश ठीक करें |
| पहली कोशिश में वेबहुक सफलता | मर्चेंटों को बिना दोबारा कोशिश के नतीजे कितनी भरोसेमंदी से मिलते हैं |
| रिपोर्ट किए गए अनपेक्षित प्रॉम्प्ट | धोखाधड़ी की कोशिशों का शुरुआती संकेत |
काउंटर से आगे: दूर से अनुरोध
यही तंत्र तब भी काम करता है जब ग्राहक काउंटर पर खड़ा न हो। स्कूल अभिभावकों को फ़ीस अनुरोध भेज सकता है, यूटिलिटी कंपनी बिल का भुगतान माँग सकती है, डिलीवरी करने वाला पहुँचने पर भुगतान माँग सकता है। दूर के अनुरोधों में कुछ बदलाव चाहिए: लंबी समाप्ति अवधि, किस चीज़ का भुगतान है इसका साफ़ विवरण, अनुरोधकर्ता का सत्यापित नाम, और ऐसा रेफ़रेंस जिसे ग्राहक बिल या संदेश से पहचान सके। स्टेट मशीन, हस्ताक्षर और आइडेम्पोटेंसी बिल्कुल वैसे ही रहते हैं, इसीलिए एक ही चार्ज जीवनचक्र काउंटर, बिल और API सबकी सेवा करता है।
प्रॉम्प्ट-टू-पे इंटीग्रेशन की जाँच
किसी मर्चेंट के लाइव होने से पहले, सैंडबॉक्स में ये मामले चलाएँ:
- एक प्रॉम्प्ट मंज़ूर करें, एक अस्वीकार करें और एक को समाप्त होने दें, और जाँचें कि मर्चेंट का सिस्टम हर मामले में सही नतीजा दिखाता है;
- एक ही आइडेम्पोटेंसी कुंजी के साथ एक ही चार्ज-निर्माण अनुरोध दो बार भेजें और पुष्टि करें कि केवल एक चार्ज बना;
- मर्चेंट के वेबहुक एंडपॉइंट को कुछ मिनट के लिए विफल करें और पुष्टि करें कि ठीक होने पर इवेंट पहुँचते हैं;
- गलत हस्ताक्षर वाला वेबहुक भेजें और पुष्टि करें कि मर्चेंट उसे अस्वीकार करता है;
- ग्राहक की सीमा से ज़्यादा का चार्ज आज़माएँ और पुष्टि करें कि वह साफ़-सुथरे ढंग से अस्वीकार होता है;
- जाँचें कि रिफ़ंड मूल चार्ज से जुड़े हैं।
जो इंटीग्रेशन ये जाँचें पास कर ले, वह अपने सबसे व्यस्त दिन भी अच्छा व्यवहार करेगा।
अक्सर पूछे जाने वाले प्रश्न
अगर ग्राहक के पास डेटा कनेक्शन न हो तो?
SIM-आधारित प्रॉम्प्ट बिना डेटा के मोबाइल नेटवर्क पर काम करते हैं। ऐप-आधारित प्रॉम्प्ट के लिए, बिना डेटा वाले ग्राहक फिर भी USSD पर मर्चेंट का टिल नंबर डालकर भुगतान कर सकते हैं।
क्या मर्चेंट ग्राहक की मंज़ूरी के बिना चार्ज कर सकता है?
नहीं। चार्ज तभी पूरा होता है जब ग्राहक अपने PIN से उसे अधिकृत करता है। मर्चेंट अनुरोध कर सकता है; मंज़ूरी केवल ग्राहक दे सकता है।
रिफ़ंड कैसे संभाले जाते हैं?
रिफ़ंड मर्चेंट से ग्राहक की ओर एक नया लेन-देन है, जो मूल चार्ज से जुड़ा होता है। मूल लेन-देन इतिहास में बना रहता है, ताकि दोनों पक्ष देख सकें कि क्या चुकाया गया और क्या लौटाया गया।
अगर ग्राहक कहे कि उसने मंज़ूरी दे दी पर काउंटर पर कुछ न दिखे, तो कैशियर क्या करे?
दोबारा भुगतान लेने के बजाय नतीजे का इंतज़ार करें। काउंटर को रेफ़रेंस से चार्ज की स्थिति पूछनी चाहिए। अगर चार्ज पूरा हुआ है, तो नतीजा पल भर में दिखेगा; अगर समाप्त हो गया, तो कैशियर सुरक्षित रूप से नया प्रॉम्प्ट भेज सकता है। पुष्टि के स्क्रीनशॉट को कभी भुगतान का सबूत न मानें।
क्या बड़ी राशियों के लिए प्रॉम्प्ट-टू-पे सुरक्षित है?
ग्राहक की श्रेणी की सीमाएँ ठीक वैसे ही लागू होती हैं जैसे किसी अन्य भुगतान पर, और PIN वाला चरण भी वही है। बड़े व्यावसायिक भुगतानों में, मर्चेंट अक्सर प्रॉम्प्ट को बिल रेफ़रेंस के साथ जोड़ते हैं ताकि दोनों पक्ष भुगतान को किसी दस्तावेज़ से मिला सकें।
इस तरह किया जाए तो प्रॉम्प्ट-टू-पे तुरंत लगता है और इसमें दोहरी कटौती असंभव होती है, इसलिए नहीं कि कभी कुछ विफल नहीं होता, बल्कि इसलिए कि हर विफलता की एक परिभाषित स्थिति, एक दोबारा कोशिश, और सुसंगति की ओर लौटने का रास्ता होता है। PesaBridge यही देता है, ऐप्स और डेवलपर API दोनों में, एक ही चार्ज जीवनचक्र पर।