অ্যাকাউন্ট আইডি
অ্যাসোসিয়েশন ফ্লো চলাকালীন অ্যাকাউন্ট আইডি ইন্টিগ্রেটরের সার্ভার থেকে ফেরত পাঠানো হয়; এটি Google কে দুটি উপায়ে অন্তর্নিহিত অ্যাকাউন্ট সনাক্ত করতে সাহায্য করতে ব্যবহৃত হয়। প্রথমত, ঝুঁকি এবং জালিয়াতি মূল্যায়নের জন্য একই অন্তর্নিহিত ব্যবহারকারী অ্যাকাউন্ট ব্যবহার করে এমন একাধিক উপকরণ সনাক্ত করা। দ্বিতীয়ত এটি এই অ্যাকাউন্টটি সনাক্ত করতে Google গ্রাহক পরিষেবা এজেন্টরা ব্যবহার করে। এই মানটি অবশ্যই অ্যাসোসিয়েশন অনুরোধ জুড়ে ব্যবহারকারীর অ্যাকাউন্টটিকে অনন্যভাবে সনাক্ত করতে হবে এবং এটি অবশ্যই নির্দিষ্ট অ্যাকাউন্টে অপরিবর্তনীয় হতে হবে এবং এটি ব্যবহারকারীর দ্বারা সনাক্তযোগ্য হতে হবে।
উদাহরণস্বরূপ, যদি একজন ইন্টিগ্রেটর পরিচয়ের জন্য একটি ইমেল ঠিকানা ব্যবহার করে, এটি ইমেল ঠিকানা হতে পারে। তবে যদি ইন্টিগ্রেটর লগইন করার জন্য একটি ইমেল ঠিকানা ব্যবহার করে কিন্তু সেই ঠিকানাটি পরিবর্তন করা যেতে পারে, তাহলে অ্যাকাউন্ট আইডির জন্য ইমেল ঠিকানাটি একটি খারাপ পছন্দ। যা বেছে নেওয়া হোক না কেন, একই পেমেন্ট ইন্টিগ্রেটর ব্যবহারকারী পরিচয় সহ একাধিক অ্যাসোসিয়েশন প্রচেষ্টার জন্য এর মান অবশ্যই একই হতে হবে।
অ্যান্ড্রয়েড অ্যাপ্লিকেশন প্যাকেজ (এপিকে)
মোবাইল অ্যাপ্লিকেশানগুলির বিতরণ এবং ইনস্টলেশনের জন্য Android অপারেটিং সিস্টেম দ্বারা ব্যবহৃত প্যাকেজ ফাইল বিন্যাস৷
API সংস্করণ
এই স্পেসিফিকেশন সংস্করণ সমর্থন করে. সমর্থিত সংস্করণগুলি Google সার্ভারে কনফিগার করা হয়েছে৷ সংস্করণ N থেকে M-তে যাওয়ার সময় (যেখানে M হল N-এর চেয়ে বড় একটি বড় সংস্করণ) ইন্টিগ্রেটরকে অবশ্যই N এবং M উভয়কেই সমর্থন করতে হবে যতক্ষণ না Google যাচাই করে যে সমস্ত ট্র্যাফিক M-তে স্থানান্তরিত হয়েছে। প্রসঙ্গের উপর ভিত্তি করে সংস্করণগুলিকে আলাদাভাবে চিহ্নিত করা হয়। অ্যান্ড্রয়েড এপিআই এবং ওয়েবরিডাইরেক্ট এপিআই অনুরোধের পরামিতি হিসাবে API সংস্করণটি পাস করবে। সার্ভার-টু-সার্ভার কল URL পাথের একটি অংশ হিসাবে সংস্করণটি পাস করে।
সংস্করণ প্রবাহ দ্বারা স্থির করা হয় না. সুতরাং N থেকে M তে মাইগ্রেশনের সময়, একজন ইন্টিগ্রেটর একই লেনদেনের জন্য সংস্করণ M সহ একটি ক্যাপচার এবং N সংস্করণের সাথে একটি ফেরত দেখতে পারে। অ্যাসোসিয়েশন চলাকালীন ইন্টিগ্রেটর সংস্করণ N-এর একটি অ্যাসোসিয়েশন অনুরোধের সাথে সংস্করণ M-এর একটি প্রমাণীকরণ অনুরোধ পেতে পারে।
অ্যাসোসিয়েশন আইডি
associationID গ্রাহকের অ্যাকাউন্ট এবং Google যন্ত্রের মধ্যে সংযোগ চিহ্নিত করে৷ associationId জিপিটি-এর সাথে খুব মিল। প্রকৃতপক্ষে, এটি একটি GPT হিসাবে একই জীবনকাল আছে এবং একটি GPT এর 1:1 কার্ডিনালিটি আছে। associationId তার সংবেদনশীলতায় GPT থেকে আলাদা। GPT হল একটি সংবেদনশীল টোকেন যা অর্থপ্রদানের জন্য ব্যবহৃত হয়। associationId হল একটি সর্বজনীন শনাক্তকারী যা একই সম্পর্ককে প্রতিনিধিত্ব করে, কিন্তু প্রকৃতিতে ততটা সংবেদনশীল নয়৷
associateAccount চলাকালীন পেমেন্ট ইন্টিগ্রেটরের কাছে associationId পাঠানো হয়। এই একই মানটি ইন্টিগ্রেটরের কাছে পুনরায় প্রমাণীকরণের সময় পাস করা হয়। এটি ইন্টিগ্রেটরকে কোন অ্যাকাউন্টটি প্রমাণীকরণ করা উচিত সে সম্পর্কে প্রসঙ্গ থাকতে দেয়। অ্যাসোসিয়েশন আইডি পাস করা হলে, মূল অ্যাসোসিয়েশনের সময় যে অ্যাকাউন্টটি চিহ্নিত করা হয়েছিল সেই একই অ্যাকাউন্টটি অবশ্যই আগে থেকে পূরণ করতে হবে এবং তার বিরুদ্ধে প্রমাণীকরণ করতে হবে।
পেমেন্ট ইন্টিগ্রেটর সমস্ত অ্যাসোসিয়েশন আইডি সংরক্ষণ করবে এবং ইন্টিগ্রেটর এবং Google-এর মধ্যে চুক্তির আজীবনের জন্য একটি নির্দিষ্ট ইন্টিগ্রেটর অ্যাকাউন্টের সাথে সংযুক্ত করবে বলে আশা করা হচ্ছে।
প্রমাণীকরণ অনুরোধ আইডি
refreshToken , associateAccount এবং (ঐচ্ছিকভাবে) ক্যাপচার পদ্ধতিগুলি একটি প্রমাণীকরণের একটি রেফারেন্স নেয়। এই রেফারেন্সটি Google যে নির্দিষ্ট প্রমাণীকরণের উল্লেখ করছে তার requestId আইডি আকারে। এই ক্ষেত্রটি পেমেন্ট ইন্টিগ্রেটর দ্বারা যাচাই করার জন্য ব্যবহার করা হবে যে প্রকৃতপক্ষে পদ্ধতিটি একটি সফল প্রমাণীকরণের মাধ্যমে এগিয়ে গেছে।
ক্যাপচার পদ্ধতিতে একটি প্রমাণীকরণ requestId জনবহুল থাকতে পারে। এটি দুটি ক্ষেত্রে ঘটে। যদি Google একটি ক্যাপচারের ঠিক আগে ব্যবহারকারীকে প্রমাণীকরণ করে, Google প্রমাণীকরণের requestId ক্ষেত্রটি পূরণ করে। এছাড়াও, যখন একটি স্বয়ংক্রিয় অর্থপ্রদানের সময়সূচী সেট আপ করা হয় তখন Google প্রায়ই সেট আপ সময়ে ব্যবহারকারীকে প্রমাণীকরণ করে। Google সেই সময়সূচীতে প্রমাণীকরণের requestId লিখে দেয় এবং সেই নির্দিষ্ট সময়সূচীর সাথে সম্পর্কিত প্রতিটি ক্যাপচারের সাথে requestId পাঠায়।
পেমেন্ট ইন্টিগ্রেটররা 30 দিনের জন্য সমস্ত প্রমাণীকরণ requestIds সংরক্ষণ করবে বলে আশা করা হচ্ছে। যদি কোন পেমেন্ট ইন্টিগ্রেটর অথেনটিকেশন রিকোয়েস্ট requestIds অডিট করতে চায় যা একটি ক্যাপচার রিকোয়েস্টে উপস্থিত থাকতে পারে, যার মধ্যে পেমেন্টের সময়সূচী অন্তর্ভুক্ত রয়েছে, তাহলে ইন্টিগ্রেটরকে অবশ্যই ইন্টিগ্রেটর এবং Google-এর মধ্যে চুক্তির আজীবনের জন্য সমস্ত প্রমাণীকরণের requestId সংরক্ষণ করতে হবে।
প্রতিষ্ঠান
একটি কোম্পানি হল Google এর কনফিগারেশন এবং চুক্তির মধ্যে সংজ্ঞায়িত একটি ধারণা। একটি কোম্পানি ইন্টিগ্রেটর এবং গুগলের মধ্যে সম্পর্ককে সংজ্ঞায়িত করে। PGP কী এবং (ঐচ্ছিকভাবে) SSL রুট CA কোম্পানির সাথে যুক্ত। সবচেয়ে গুরুত্বপূর্ণভাবে একটি কোম্পানি এক বা একাধিক পেমেন্ট ইন্টিগ্রেটর অ্যাকাউন্ট আইডির সাথে যুক্ত। একটি কোম্পানির মধ্যে তৈরি করা GPTগুলি বেশিরভাগ কোম্পানির মধ্যে সমস্ত পেমেন্ট ইন্টিগ্রেটর অ্যাকাউন্ট আইডিগুলির জন্য কাজ করে। কিছু ব্যতিক্রম প্রযোজ্য। উদাহরণস্বরূপ, যদি জিপিটি একটি মুদ্রায় (এবং এফএক্স ফি সমর্থন করে না) একটি অ্যাকাউন্টের সাথে যুক্ত থাকে এবং একটি ভিন্ন মুদ্রায় একটি পেমেন্ট ইন্টিগ্রেটর অ্যাকাউন্ট আইডিতে কেনাকাটা করার চেষ্টা করছে।
অর্থপ্রদানের ফর্ম (FOP)
সমস্ত লেনদেনের মধ্যে এক বা একাধিক অর্থপ্রদানের ধরন (FOP), যেমন একটি ক্রেডিট কার্ড বা ইলেক্ট্রনিক ফান্ড ট্রান্সফার অন্তর্ভুক্ত, যা ব্যবহারকারীদের দ্বারা পণ্য বা পরিষেবার জন্য Google-কে অর্থ প্রদানের জন্য অথবা AdSense ব্যবহারকারীদের ক্ষেত্রে এবং Google-এর ক্ষেত্রে ব্যবহারকারীদের অর্থ প্রদানের জন্য Google ব্যবহার করে। বিকাশকারী খেলুন। অর্থপ্রদানের ফর্মগুলিকে প্রায়শই অর্থপ্রদানের উপকরণ, উপকরণ এবং অর্থপ্রদানের পদ্ধতি বলা হয়।
গুগল পেমেন্ট টোকেন (GPT)
GPT হল একটি এলোমেলো, ওয়েব-নিরাপদ বেস64-এনকোডেড মান যা অ্যাসোসিয়েশন সময়ে Google সার্ভার দ্বারা তৈরি হয় এবং ইন্টিগ্রেটর সার্ভারে পাঠানো হয়। GPT হল একটি ব্যক্তিগত শনাক্তকারী যা ইন্টিগ্রেটর এবং Google যন্ত্রের সাথে ব্যবহারকারীর অ্যাকাউন্টের মধ্যে সংযোগের প্রতিনিধিত্ব করে৷ একটি GPT হল একটি টোকেন যা ব্যবহারকারীর শংসাপত্র বা একটি অ্যাকাউন্ট আইডি প্রতিস্থাপন করে। এই টোকেন ক্রেডিট বা ডেবিট অ্যাকাউন্ট সনাক্ত করতে ক্রয়-প্রবাহের সময় ব্যবহার করা হয় এবং উভয় পক্ষের কাছে গোপন থাকে। GPT কখনই স্পষ্ট পাঠ্যে পাঠানো উচিত নয় এবং গোপনীয়তা নিশ্চিত করতে এনক্রিপ্ট করা আবশ্যক।
GPT associationId থেকে আলাদা কারণ associationId সুরক্ষিত নয় এবং অবাধে পাবলিক উপায়ে (URL, অনিরাপদ সংযোগ) মাধ্যমে পাস করা হয়। GPT শুধুমাত্র Google এবং ইন্টিগ্রেটরের কাছে পরিচিত।
পেমেন্ট ইন্টিগ্রেটর সমস্ত GPTS সঞ্চয় করবে এবং ইন্টিগ্রেটর এবং Google-এর মধ্যে চুক্তির আজীবনের জন্য একটি নির্দিষ্ট ইন্টিগ্রেটর অ্যাকাউন্টের সাথে সংযুক্ত করবে বলে আশা করা হচ্ছে।
অদম্যতা
একটি অক্ষমতার অপারেশন ফলাফল পরিবর্তন না করে বা অপারেশনের প্রাথমিক প্রয়োগের বাইরে নতুন পার্শ্ব প্রতিক্রিয়া না করে একাধিকবার প্রয়োগ করা যেতে পারে। সাধারণত idempotency একই অনুরোধ সনাক্ত করতে একটি "কী" ব্যবহার করে। দুটি সার্ভারের মধ্যে সংজ্ঞায়িত সমস্ত অনুরোধ অনুরোধ শিরোনামে সংজ্ঞায়িত একটি idempotency কী ব্যবহার করে। রিকোয়েস্ট হেডারে একটি রিকোয়েস্ট আইডি আছে যা আইডেমপোটেন্সি কী হিসেবে ব্যবহার করা হয়। অনুরোধ আইডি বিশ্বব্যাপী অনন্য। অদম্য অনুরোধগুলি অবশ্যই একটি ব্যতিক্রম সহ ঠিক একই JSON বডি হতে হবে৷ requestTimestamp প্রতিটি অনুরোধের জন্য আলাদা হবে। এটি একটি গুরুত্বপূর্ণ পার্থক্য। requestTimestamp হল সার্ভারের অনুরোধ পাঠানোর সময়। এবং চেষ্টা প্রতি অনন্য. এটি রিপ্লে আক্রমণের ক্ষমতা কমাতে সাহায্য করে। একইভাবে, একটি অদম্য প্রতিক্রিয়া অবশ্যই একই JSON বডি হতে হবে ব্যতীত প্রতিটি প্রতিক্রিয়ার জন্য responseTimestamp আলাদা হবে৷
ইকো পদ্ধতি ব্যতীত সমস্ত সার্ভার-টু-সার্ভার পদ্ধতি অবশ্যই অদম্য হতে হবে। ইন্টিগ্রেটরের UI (এটি অ্যান্ড্রয়েড বা ওয়েব হোক) প্রমাণীকরণের অনুরোধগুলি অদম্য নয়৷
অদম্য আচরণের উদাহরণের জন্য, রেফারেন্স ডক দেখুন।
শনাক্তকারী (আইডি)
শনাক্তকারীরা পেমেন্ট ইন্টিগ্রেটর এবং Google এর মধ্যে একটি লেনদেন বা যোগাযোগের প্রতিনিধিত্ব করে।
যন্ত্র
যন্ত্রটি একটি একক Google গ্রাহকের সাথে যুক্ত অর্থপ্রদানের একটি সঞ্চিত পদ্ধতির প্রতিনিধিত্ব করে। যন্ত্রের উদাহরণগুলির মধ্যে রয়েছে:
- ফাইলে একটি ক্রেডিট কার্ড নম্বর
- একটি ব্যাঙ্ক অ্যাকাউন্ট এবং রাউটিং নম্বর
ব্যবহারকারীদের তাদের Google পরিচয়ের সাথে যুক্ত একাধিক যন্ত্র থাকতে পারে।
মাইক্রোস
এই API-তে আর্থিক মানগুলি "মাইক্রোস" নামে একটি বিন্যাস ব্যবহার করে উপস্থাপন করা হয়, যা Google-এর একটি মানক৷ মাইক্রো হল একটি পূর্ণসংখ্যা ভিত্তিক, নির্দিষ্ট নির্ভুল বিন্যাস। মাইক্রোতে একটি আর্থিক মান উপস্থাপন করতে, আদর্শ মুদ্রার মানকে 1,000,000 দ্বারা গুণ করুন।
উদাহরণ স্বরূপ:
- USD$1.23 = 1230000 মাইক্রো USD
- USD$0.01 = 10000 মাইক্রো USD
পেমেন্ট ইন্টিগ্রেটর
বাহ্যিক ইন্টিগ্রেটর যা ব্যবহারকারীর লেনদেনের জন্য অর্থপ্রদান প্রক্রিয়া করে।
পেমেন্ট ইন্টিগ্রেটর অ্যাকাউন্ট আইডি
এই শনাক্তকারী Google এবং ইন্টিগ্রেটরের মধ্যে চুক্তির চারপাশে সীমাবদ্ধতার প্রতিনিধিত্ব করে৷ ইন্টিগ্রেটর অ্যাকাউন্ট আইডি Google দ্বারা তৈরি করা হয় এবং সেটআপের সময় ইন্টিগ্রেটরকে বরাদ্দ করা হয়। সাধারণত এটি একটি "MID" হিসাবে উল্লেখ করা হয়। সমস্ত অনুরোধ এবং প্রতিক্রিয়া এই আইডি অন্তর্ভুক্ত করা আবশ্যক. এই শনাক্তকারী অস্বচ্ছ এবং কখনই পার্স করা উচিত নয়। এই শনাক্তকারীর বিন্যাস সমস্ত জারি করা আইডি জুড়ে সামঞ্জস্যপূর্ণ নাও হতে পারে৷
এই শনাক্তকারী লেনদেনের জীবনকালের জন্য কখনই পরিবর্তন হয় না। ক্যাপচার এবং রিফান্ডের ক্ষেত্রে, একই শনাক্তকারী ব্যবহার করা হয়।
ইন্টিগ্রেটর অ্যাকাউন্ট আইডির সীমাবদ্ধতা চুক্তির দ্বারাই সংজ্ঞায়িত করা হয়। সাধারণত, সীমাবদ্ধতাগুলি চালানের চারপাশে থাকে। উদাহরণস্বরূপ, একজন ইন্টিগ্রেটর CAD এবং MXN কে USD হিসাবে চালান করা সমর্থন করে, কিন্তু EUR লেনদেন EUR-এ চালান করতে হবে। এই ক্ষেত্রে দুটি ভিন্ন পেমেন্ট ইন্টিগ্রেটর অ্যাকাউন্ট আইডি ব্যবহার করা হবে, একটি USD চালানের জন্য এবং অন্যটি EUR চালানের জন্য।
নতুন শনাক্তকারীর পক্ষে শনাক্তকারীকে পর্যায়ক্রমে বের করা যেতে পারে। যে ক্ষেত্রে একটি শনাক্তকারীকে অবমূল্যায়ন করা হচ্ছে, Google সেই শনাক্তকারীর কাছে ক্যাপচার শুরু করা বন্ধ করবে। তবে ইন্টিগ্রেটরকে অবশ্যই শেষ ক্যাপচার ইনিশিয়েশন থেকে এক বছরের জন্য সেই শনাক্তকারীর বিরুদ্ধে করা লেনদেনের জন্য অর্থ ফেরত দিতে হবে (ক্যাপচার ইনিশিয়েশন রিকোয়েস্ট requestHeader পাওয়া requestTimestamp হিসাবে সংজ্ঞায়িত করা হয়েছে)।
পিআইআই
ব্যক্তিগতভাবে শনাক্তকরণযোগ্য তথ্য (PII) হল এমন তথ্য যা ব্যক্তিগতভাবে একজন ব্যক্তিকে সনাক্ত করে এবং Google দ্বারা যুক্তিসঙ্গতভাবে এই ধরনের তথ্যের সাথে লিঙ্ক করা যেতে পারে, যেমন একজন ব্যবহারকারীর নাম, ইমেল ঠিকানা, মেইলিং ঠিকানা, বা টেলিফোন নম্বর, একা বা একত্রে
অনুরোধ আইডি
requestId Google এবং পেমেন্ট ইন্টিগ্রেটরের মধ্যে সমস্ত যোগাযোগ শনাক্ত করে৷
SPII
সংবেদনশীল ব্যক্তিগতভাবে শনাক্তকরণযোগ্য তথ্য (SPII) হল ব্যক্তিগতভাবে শনাক্তযোগ্য তথ্যের (PII) একটি উপসেট যা ব্যবহারকারীর কাছে একটি উচ্চ ঝুঁকি উপস্থাপন করে যদি এটি আপস করা হয় বা অপব্যবহার করা হয়। SPII-এর প্রায়ই আইনি, নিয়ন্ত্রক, বা সম্মতিকারী সংস্থাগুলির দ্বারা আরোপিত সীমাবদ্ধ পরিচালনা এবং স্টোরেজ প্রয়োজনীয়তা রয়েছে।
টোকেন
Google এবং ইন্টিগ্রেটরের মধ্যে যখন PII বা SPII-এর মতো সংবেদনশীল প্রমাণপত্রাদি বিনিময় করা হয় তখন টোকেনগুলি নিরাপত্তার একটি অতিরিক্ত স্তর যোগ করে৷
ব্যবহারকারীর ঠিকানা
ইন্সট্রুমেন্ট তৈরির সময় Google চেক করে যে ব্যবহারকারী একজন Google Payments গ্রাহক কিনা। এটি একটি Google গ্রাহক হওয়ার থেকে স্বাধীন। Google Payments গ্রাহক হওয়ার জন্য, আমাদের ব্যবহারকারীর বিলিং ঠিকানা প্রয়োজন৷ কিছু নিয়ন্ত্রক সংস্থা আমাদের ব্যবহারকারীর সম্পূর্ণ ঠিকানা জানতে চায়, অন্যদের সেই ঠিকানার একটি উপসেট প্রয়োজন।
যদি পেমেন্ট ইন্টিগ্রেটরের কাছে এই ব্যবহারকারীর জন্য ফাইলে একটি ঠিকানা থাকে, তাহলে Google ব্যবহারকারীর ঠিকানা ফর্মটি আগে থেকে পূরণ করার জন্য অ্যাসোসিয়েশন ফ্লো চলাকালীন সেই ঠিকানাটি পেতে চায়৷ ব্যবহারকারীর কাছে পূর্বে ভর্তি ঠিকানা পরিবর্তন করার বিকল্প রয়েছে। ব্যবহারকারীর ঠিকানা পূর্বে পূরণ করা একটি যন্ত্র যোগ করার ক্ষেত্রে ঘর্ষণকে হ্রাস করে এবং এই যন্ত্রগুলি যুক্ত করার ব্যবহারকারীদের রূপান্তর হার বৃদ্ধি করে।
যদি ঠিকানাটি ভাগ করা হয়, Google তাদের ঝুঁকির মডেল হিসাবে এটি ব্যবহার করে। এটি Google-এর ঝুঁকি ইঞ্জিনকে ব্যবহারকারী যে ঠিকানায় বলেছে তা বুঝতে অনুমতি দেয় এবং ব্যবহারকারী বর্তমানে যে আইপি অবস্থানে রয়েছে তার সাথে তুলনা করার সময় তাদের বিল করা হয়েছে৷
ঠিকানা ভাগ করা সম্পূর্ণরূপে একটি অপ্টিমাইজেশান. এটা ঠিক এবং প্রত্যাশিত যে কিছু ইন্টিগ্রেটরের কাছে ব্যবহারকারীর জন্য একটি বিলিং ঠিকানা থাকবে না বা এই ঠিকানাটি ভাগ করতে পারবে না।
ওয়েব-সেফ বেস64-এনকোডিং
RFC 4648 সেকশন 5, বেস 64 ইউআরএল এবং ফাইলের নাম নিরাপদ বর্ণমালা সহ এনকোডিং-এ নির্দিষ্ট করা এনকোডিং স্ট্যান্ডার্ড, কখনও কখনও "ওয়েব-সেফ বেস64" বা "বেস64url" এনকোডিং হিসাবেও উল্লেখ করা হয়। (এটি RFC 3548 বিভাগ 4 থেকে URL এবং ফাইলের নাম নিরাপদ বর্ণমালা সহ base64 এনকোডিংয়ের মতোই।) সমস্ত এনক্রিপ্ট করা এবং স্বাক্ষরিত মান এই মান ব্যবহার করে এনকোড করা আবশ্যক।