ग्लॉसरी

खाता आईडी

असोसिएशन फ़्लो के दौरान, खाता आईडी को इंटिग्रेटर के सर्वर से वापस भेजा जाता है. दो तरीकों से खाते की पहचान करने में Google की मदद करने के लिए इसका इस्तेमाल किया जाता है. पहला, जोखिम और धोखाधड़ी का आकलन करने के लिए, ऐसे कई तरीकों की पहचान करना जो एक ही उपयोगकर्ता खाते का इस्तेमाल करते हैं. दूसरा, इस खाते की पहचान करने के लिए Google के ग्राहक सेवा एजेंट इसका इस्तेमाल करते हैं. इस वैल्यू को असोसिएशन के सभी अनुरोधों में, उपयोगकर्ता खाते की खास तरह से पहचान करनी चाहिए. साथ ही, यह ज़रूरी है कि किसी खाते के लिए, उसमें कोई बदलाव न किया जा सके. साथ ही, यह भी ज़रूरी है कि उपयोगकर्ता उस खाते की पहचान कर सके.

उदाहरण के लिए, अगर कोई इंटिग्रेटर, पहचान के लिए किसी ईमेल पते का इस्तेमाल करता है, तो यह ईमेल पता हो सकता है. हालांकि, अगर इंटिग्रेटर, लॉगिन के लिए किसी ईमेल पते का इस्तेमाल करता है, लेकिन उस पते को बदला जा सकता है, तो खाता आईडी के लिए ईमेल पता सही नहीं है. चाहे जो भी चुना जाए, एक ही पेमेंट इंटिग्रेटर उपयोगकर्ता की पहचान से कई असोसिएशन के लिए एक जैसी वैल्यू चुनी जानी चाहिए.

Android ऐप्लिकेशन पैकेज (APK)

पैकेज फ़ाइल फ़ॉर्मैट, जिसे Android ऑपरेटिंग सिस्टम मोबाइल ऐप्लिकेशन के डिस्ट्रिब्यूशन और इंस्टॉल करने के लिए इस्तेमाल करता है.

API वर्शनिंग

यह स्पेसिफ़िकेशन, वर्शन के साथ काम करता है. 'Google सर्वर' पर काम करने वाले वर्शन कॉन्फ़िगर किए जाते हैं. N से M (जहां M का मेजर वर्शन N से बड़ा है) पर ले जाते समय, इंटिग्रेटर को N और M, दोनों वर्शन पर काम करना चाहिए. ऐसा तब तक होगा, जब तक Google यह पुष्टि नहीं कर लेता कि पूरा ट्रैफ़िक M पर माइग्रेट हो गया है. कॉन्टेक्स्ट के हिसाब से, वर्शन की पहचान अलग-अलग तरीके से की जाती है. Android API और WebRedirect API, अनुरोध के लिए पैरामीटर के तौर पर एपीआई वर्शन पास करेंगे. सर्वर-टू-सर्वर कॉल, वर्शन को यूआरएल पाथ के एक हिस्से के तौर पर पास करते हैं.

फ़्लो के हिसाब से वर्शन तय नहीं किए जाते. इसलिए, N से M में माइग्रेट करने के दौरान, इंटिग्रेटर को M वर्शन वाला कैप्चर दिख सकता है. साथ ही, उसी लेन-देन के लिए, वर्शन N के साथ रिफ़ंड भी मिल सकता है. असोसिएशन के दौरान, इंटिग्रेटर को वर्शन M की पुष्टि करने का अनुरोध मिल सकता है. यह अनुरोध वर्शन N के असोसिएशन अनुरोध के साथ किया जाता है.

असोसिएशन आईडी

associationID, ग्राहक के खाते और Google के तरीके के बीच संबंध की पहचान करता है. associationId, GPT से काफ़ी हद तक मिलता-जुलता है. असल में, यह GPT जैसा ही होता है और इसमें GPT के लिए 1:1 एलिमेंट की संख्या होती है. associationId, जीपीटी से अलग है. GPT एक संवेदनशील टोकन है जिसका इस्तेमाल पेमेंट के लिए किया जाता है. associationId एक सार्वजनिक आइडेंटिफ़ायर है जो एक जैसे रिश्ते को दिखाता है, लेकिन यह उतना संवेदनशील नहीं होता.

associateAccount के दौरान, associationId को पेमेंट इंटिग्रेटर को पास किया जाता है. फिर से पुष्टि करने के दौरान, इसी वैल्यू को इंटिग्रेटर को पास किया जाता है. इससे इंटिग्रेटर को इस बात की जानकारी मिलती है कि किस खाते की पुष्टि की जानी चाहिए. अगर असोसिएशन आईडी दिया जाता है, तो मूल असोसिएशन के दौरान जिस खाते की पहचान की गई थी उसे पहले से भरा हुआ होना चाहिए और उसकी पुष्टि की जानी चाहिए.

पेमेंट इंटिग्रेटर से उम्मीद की जाती है कि वह सभी असोसिएशन आईडी को सेव कर ले. साथ ही, वह उन्हें किसी खास इंटिग्रेटर खाते से जोड़ेगा. ऐसा, पेमेंट इंटिग्रेटर और Google के बीच हुए कानूनी समझौते की अवधि के दौरान किया जाएगा.

पुष्टि करने के अनुरोध का आईडी

refreshToken, associateAccount, और (ज़रूरी नहीं) कैप्चर किए गए तरीके, पुष्टि करने की प्रक्रिया का रेफ़रंस लेते हैं. यह रेफ़रंस, पुष्टि करने के एक खास तरीके के requestId के रूप में है, जिसके बारे में Google बता रहा है. इस फ़ील्ड का इस्तेमाल, पेमेंट इंटिग्रेटर करेगा. इससे यह पुष्टि की जा सकेगी कि पुष्टि करने के इस तरीके को सही तरीके से आगे बढ़ाया गया है या नहीं.

कैप्चर करने के तरीकों में, पुष्टि करने वाला requestId भरा जा सकता है. ऐसा दो मामलों में होता है. अगर Google, कैप्चर करने से ठीक पहले उपयोगकर्ता की पुष्टि करता है, तो Google, पुष्टि करने वाले requestId फ़ील्ड की जानकारी अपने-आप भर देता है. साथ ही, Google अक्सर सेट अप के समय अपने-आप होने वाले पेमेंट का शेड्यूल सेट अप होने पर, उपयोगकर्ता की पुष्टि करता है. Google इस शेड्यूल के हिसाब से, पुष्टि करने वाले requestId को लिखता है और उस खास शेड्यूल से जुड़े हर कैप्चर के साथ requestId भेजता है.

पेमेंट इंटिग्रेटर से उम्मीद की जाती है कि वे पुष्टि करने वाले सभी requestIds को 30 दिनों तक सेव रखेंगे. अगर पेमेंट इंटिग्रेटर, पुष्टि करने के उस requestIds का ऑडिट करना चाहता है जो कैप्चर करने के अनुरोध पर मौजूद हो सकता है और इसमें पेमेंट के शेड्यूल भी शामिल हैं, तो इंटिग्रेटर को पुष्टि करने वाले सभी requestId को, इंटिग्रेटर और Google के बीच हुए कॉन्ट्रैक्ट की अवधि के लिए सेव करना होगा.

कंपनी

कंपनी का मतलब Google के कॉन्फ़िगरेशन और कॉन्ट्रैक्ट में शामिल सिद्धांत है. कंपनी, इंटिग्रेटर और Google के बीच के संबंध के बारे में बताती है. PGP कुंजियां और (ज़रूरी नहीं) एसएसएल रूट सीए, कंपनी से जुड़े होते हैं. सबसे अहम बात यह है कि कोई कंपनी, एक या उससे ज़्यादा पेमेंट इंटिग्रेटर खाता आईडी से जुड़ी होती है. कंपनी में बनाए गए GPT, ज़्यादातर कंपनी में सभी पेमेंट इंटिग्रेटर खाता आईडी के लिए काम करते हैं. कुछ अपवाद लागू होते हैं. उदाहरण के लिए, अगर GPT किसी ऐसे खाते से जुड़ा है जो एक मुद्रा में काम करता है (और FX शुल्क की सुविधा नहीं देता है) और वह किसी दूसरी मुद्रा में पेमेंट इंटिग्रेटर खाता आईडी से खरीदारी करने की कोशिश कर रहा है.

पैसे चुकाने का तरीका (एफ़ओपी)

सभी लेन-देन में, पैसे चुकाने के एक या उससे ज़्यादा तरीके (एफ़ओपी) शामिल होते हैं. जैसे, क्रेडिट कार्ड या इलेक्ट्रॉनिक फ़ंड ट्रांसफ़र. इनका इस्तेमाल उपयोगकर्ता को प्रॉडक्ट या सेवाओं के लिए Google को पैसे चुकाने के लिए करते हैं. वहीं, AdSense उपयोगकर्ताओं और Google Play डेवलपर के मामलों में Google, पैसे चुकाने के तरीकों का इस्तेमाल करता है. पैसे चुकाने के तरीकों को अक्सर पेमेंट के तरीके, पैसे चुकाने के तरीके, और पैसे चुकाने के तरीके भी कहा जाता है.

Google पेमेंट टोकन (GPT)

जीपीटी एक रैंडम और वेब के हिसाब से सुरक्षित, base64 कोड में बदली गई वैल्यू है. इसे Google सर्वर असोसिएशन के समय जनरेट करता है और इंटिग्रेटर सर्वर को भेज देता है. GPT एक निजी आइडेंटिफ़ायर है, जो उपयोगकर्ता के खाते को इंटिग्रेटर और Google इंस्ट्रुमेंट के साथ लिंक करने के तरीके को दिखाता है. GPT एक ऐसा टोकन है जो उपयोगकर्ता क्रेडेंशियल या खाता आईडी की जगह लेता है. इस टोकन का इस्तेमाल खरीदारी के दौरान, क्रेडिट या डेबिट खाते की पहचान करने के लिए किया जाता है. यह दोनों पक्षों के लिए गोपनीय होता है. GPT को कभी भी साफ़ टेक्स्ट में नहीं भेजा जाना चाहिए. यह निजता बनाए रखने के लिए एन्क्रिप्ट (सुरक्षित) होना चाहिए.

GPT, associationId से अलग है, क्योंकि associationId सुरक्षित नहीं है और इसे सार्वजनिक तरीकों (यूआरएल, असुरक्षित कनेक्शन) के ज़रिए आसानी से पास किया जाता है. GPT को सिर्फ़ Google और इंटिग्रेटर ही इस्तेमाल करते हैं.

पेमेंट इंटिग्रेटर से उम्मीद की जाती है कि वह सभी GPTS को स्टोर करेगा. साथ ही, उसे इंटिग्रेटर और Google के बीच हुए समझौते की अवधि के लिए, एक खास इंटिग्रेटर खाते से जोड़ेगा.

पहचान न कर पाना

बिना किसी बदलाव के, नतीजे को बदले बिना या शुरुआती लागू करने के बाद, नए खराब असर के बावजूद, कई बार बिना किसी कार्रवाई को लागू किया जा सकता है. आम तौर पर, एक जैसे अनुरोध की पहचान करने के लिए, साइट की पहचान बदलने के लिए एक “कुंजी” का इस्तेमाल किया जाता है. दो सर्वर के बीच तय किए गए सभी अनुरोध, अनुरोध के हेडर में तय की गई पहचान कुंजी का इस्तेमाल करते हैं. अनुरोध के हेडर में एक अनुरोध आईडी होता है, जिसका इस्तेमाल आईडीम्पॉएंसी कुंजी के तौर पर किया जाता है. अनुरोध आईडी दुनिया भर में यूनीक होता है. पहचान से जुड़े अनुरोध, एक अपवाद के साथ, JSON बॉडी में बिलकुल एक जैसे होने चाहिए. हर अनुरोध के लिए requestTimestamp अलग होगा. यह एक अहम अंतर है. requestTimestamp वह समय है जब सर्वर ने यह अनुरोध भेजा है. और यह हर कोशिश के लिए खास होता है. इससे रीप्ले अटैक की संभावना कम हो जाती है. इसी तरह, बिना किसी जवाब के, JSON का मुख्य हिस्सा एक जैसा होना चाहिए. हालांकि, हर जवाब के लिए responseTimestamp अलग-अलग होगा.

Echo तरीके को छोड़कर, सर्वर-टू-सर्वर के सभी तरीके idempotent होने चाहिए. इंटिग्रेटर के यूज़र इंटरफ़ेस (यूआई) पर पुष्टि करने के अनुरोध (चाहे वह Android हो या वेब हो) के लिए काम के नहीं होते.

छिपी हुई गतिविधि के उदाहरण देखने के लिए, रेफ़रंस दस्तावेज़ देखें.

आइडेंटिफ़ायर (आईडी)

आइडेंटिफ़ायर, पेमेंट इंटिग्रेटर और Google के बीच होने वाले लेन-देन या बातचीत को दिखाते हैं.

भुगतान का माध्यम

यह तरीका, Google के किसी एक ग्राहक से जुड़े पेमेंट के सेव किए गए तरीके को दिखाता है. इंस्ट्रुमेंट के उदाहरण:

• फ़ाइल में क्रेडिट कार्ड का नंबर मौजूद है
• बैंक खाता और रूटिंग नंबर

उपयोगकर्ता के पास, उनकी Google पहचान के साथ कई तरीकों से जुड़े विकल्प हो सकते हैं.

माइक्रो

इस एपीआई में मॉनेटरी वैल्यू को "माइक्रो" फ़ॉर्मैट का इस्तेमाल करके दिखाया जाता है. यह Google के स्टैंडर्ड फ़ॉर्मैट में उपलब्ध है. माइक्रो, पूर्णांक पर आधारित और तय सटीक फ़ॉर्मैट होते हैं. किसी मॉनेटरी वैल्यू को माइक्रो में दिखाने के लिए, स्टैंडर्ड मुद्रा की वैल्यू को 10,00,000 से गुणा करें.

उदाहरण के लिए:

• 1.23 डॉलर = 1,230,000 माइक्रो डॉलर
• 0.01 डॉलर = 10,000 माइक्रो डॉलर

पेमेंट इंटिग्रेटर

उपयोगकर्ता के ट्रांज़ैक्शन के लिए पेमेंट प्रोसेस करने वाला बाहरी इंटिग्रेटर.

पेमेंट इंटिग्रेटर खाता आईडी

यह आइडेंटिफ़ायर, Google और इंटिग्रेटर के बीच के अनुबंध से जुड़ी पाबंदियों को दिखाता है. इंटिग्रेटर खाता आईडी, Google जनरेट करता है और सेटअप के दौरान, इंटिग्रेटर को असाइन किया जाता है. आम तौर पर, इसे "MID" कहा जाता है. सभी अनुरोधों और जवाबों में यह आईडी शामिल होना चाहिए. यह आइडेंटिफ़ायर ओपेक है और इसे कभी भी पार्स नहीं किया जाना चाहिए. ऐसा हो सकता है कि इस आइडेंटिफ़ायर का फ़ॉर्मैट, जारी किए गए सभी आईडी के लिए एक जैसा न हो.

यह आइडेंटिफ़ायर, लेन-देन के पूरे समय के लिए कभी नहीं बदलता. कैप्चर और रिफ़ंड के मामले में, एक ही आइडेंटिफ़ायर का इस्तेमाल किया जाता है.

इंटिग्रेटर खाता आईडी की सीमाएं, कॉन्ट्रैक्ट से तय होती हैं. आम तौर पर, पाबंदियां इनवॉइस से जुड़ी होती हैं. उदाहरण के लिए, इंटिग्रेटर के हिसाब से सीएडी और एमएक्सएन का इनवॉइस अमेरिकी डॉलर के तौर पर दिया जाता है, लेकिन इसके लिए यूरो में लेन-देन का इनवॉइस भी यूरो में देना ज़रूरी है. इस मामले में, दो अलग-अलग पेमेंट इंटिग्रेटर खाता आईडी का इस्तेमाल किया जाएगा, एक डॉलर इनवॉइस के लिए और दूसरा यूरो इनवॉइस के लिए.

नए आइडेंटिफ़ायर के बजाय, आइडेंटिफ़ायर को हटाया जा सकता है. अगर किसी आइडेंटिफ़ायर के इस्तेमाल पर रोक लगाई जा रही है, तो Google उस आइडेंटिफ़ायर को कैप्चर करना बंद कर देगा. हालांकि, इंटिग्रेटर को उस आइडेंटिफ़ायर के साथ किए गए लेन-देन के लिए, आखिरी बार कैप्चर किए जाने (कैप्चर करने की प्रोसेस requestHeader में मिली requestTimestamp) के तौर पर बताए गए एक साल के लिए रिफ़ंड देना होगा.

व्यक्तिगत पहचान से जुड़ी जानकारी

व्यक्तिगत पहचान से जुड़ी जानकारी (पीआईआई), किसी व्यक्ति और ऐसे दूसरे डेटा की पहचान करती है जिसे Google, उपयोगकर्ता का नाम, ईमेल पता, डाक पता या टेलीफ़ोन नंबर जैसी जानकारी से लिंक करता है.

अनुरोध आईडी

requestId, Google और पेमेंट इंटिग्रेटर के बीच सभी कम्यूनिकेशन की पहचान करता है.

एसपीआईआई

व्यक्तिगत पहचान से जुड़ी संवेदनशील जानकारी (एसपीआईआई), व्यक्तिगत पहचान से जुड़ी जानकारी का एक सबसेट है. अगर इसका गलत इस्तेमाल किया जाता है या इसके साथ छेड़छाड़ की जाती है, तो लोगों के लिए इससे जोखिम की आशंका बढ़ जाती है. एसपीआईआईवी में अक्सर कानूनी, नियामक या अनुपालन करने वाली इकाइयों की ओर से लगाई गई पाबंदी वाली हैंडलिंग और स्टोरेज की ज़रूरी शर्तें होती हैं.

टोकन

Google और इंटिग्रेटर के बीच व्यक्तिगत पहचान से जुड़ी जानकारी या एसपीआईआई का लेन-देन होने पर, टोकन सुरक्षा की एक अतिरिक्त लेयर जोड़ते हैं.

उपयोगकर्ता का पता

इंस्ट्रुमेंट बनाते समय, Google यह जांच करता है कि उपयोगकर्ता Google Payments ग्राहक है या नहीं. यह Google का ग्राहक होने से अलग है. Google Payments ग्राहक बनने के लिए, हमें उपयोगकर्ता के बिलिंग पते की ज़रूरत होती है. कुछ कानूनी एजेंसियों के लिए, हमें उपयोगकर्ता का पूरा पता बताना ज़रूरी होता है. हालांकि, अन्य एजेंसियों को पते के एक सबसेट की ज़रूरत होती है.

अगर पेमेंट इंटिग्रेटर के पास इस उपयोगकर्ता का पता फ़ाइल में है, तो Google चाहता है कि असोसिएशन फ़्लो के दौरान वह पता, उपयोगकर्ता के पते वाले फ़ॉर्म में पहले से भरा जा सके. उपयोगकर्ता के पास पहले से भरे गए पते को बदलने का विकल्प होता है. उपयोगकर्ता पता पहले से भरने से, इंस्ट्रुमेंट जोड़ने में होने वाली परेशानी कम हो जाती है और इन इंस्ट्रुमेंट को जोड़ने वाले उपयोगकर्ताओं की कन्वर्ज़न दर बढ़ जाती है.

अगर पता शेयर किया जाता है, तो Google इसका इस्तेमाल अपने जोखिम के मॉडल में गणना के तौर पर भी करता है. इससे Google के रिस्क इंजन को यह समझने में मदद मिलती है कि उपयोगकर्ता ने किस आईपी पते पर अपनी बिलिंग की जानकारी दी है.

पता शेयर करने की सुविधा पूरी तरह से एक ऑप्टिमाइज़ेशन है. यह ठीक है और उम्मीद की जाती है कि कुछ इंटिग्रेटर के पास उपयोगकर्ता का बिलिंग पता नहीं होगा या वे यह पता शेयर नहीं कर सकेंगे.

वेब-सुरक्षित Base64-एन्कोडिंग

आरएफ़सी 4648 के सेक्शन 5, यूआरएल के साथ बेस 64 एन्कोडिंग, और Filename Safe Alphabet में बताए गए एन्कोडिंग स्टैंडर्ड को, कभी-कभी "वेब-सेफ़ Base64" या "base64url" एन्कोडिंग भी कहा जाता है. (यह आरएफ़सी 3548 के सेक्शन 4 में बताए गए, यूआरएल और फ़ाइल नाम सुरक्षित वर्णमाला के साथ base64 कोड में बदलने के तरीके जैसा ही है.) एन्क्रिप्ट की गई और साइन की गई सभी वैल्यू को इस स्टैंडर्ड का इस्तेमाल करके एन्कोड किया जाना चाहिए.