شناسه حساب
شناسه حساب در طول جریان ارتباط از سرور یکپارچه کننده بازگردانده می شود. از آن برای کمک به گوگل برای شناسایی حساب اصلی به دو صورت استفاده می شود. اول، شناسایی ابزارهای متعددی که از یک حساب کاربری اساسی برای ارزیابی ریسک و تقلب استفاده می کنند. ثانیاً این توسط نمایندگان خدمات مشتری Google برای شناسایی این حساب استفاده می شود. این مقدار باید به طور منحصربه‌فرد حساب کاربری را در بین درخواست‌های مرتبط مشخص کند، و باید در حساب خاص غیرقابل تغییر باشد و توسط کاربر قابل شناسایی باشد.
به عنوان مثال، اگر یک ادغام کننده از یک آدرس ایمیل برای هویت استفاده می کند، این می تواند آدرس ایمیل باشد. با این حال، اگر یکپارچه‌ساز از یک آدرس ایمیل برای ورود استفاده می‌کند اما آن آدرس را می‌توان تغییر داد، آدرس ایمیل انتخاب نامناسبی برای شناسه حساب است. هر چه انتخاب شود، ارزش آن باید برای چندین تلاش مرتبط با هویت کاربر یکپارچه کننده پرداخت یکسان باشد.
بسته برنامه اندروید (APK)
فرمت فایل بسته مورد استفاده سیستم عامل اندروید برای توزیع و نصب اپلیکیشن های موبایل.
نسخه API
این مشخصات از نسخه سازی پشتیبانی می کند. نسخه های پشتیبانی شده در سرور Google پیکربندی شده اند. هنگام انتقال از نسخه N به M (که در آن M نسخه اصلی بزرگتر از N است)، ادغام کننده باید N و M را پشتیبانی کند تا زمانی که Google تأیید کند که تمام ترافیک به M منتقل شده است. نسخه ها بر اساس زمینه متفاوت شناسایی می شوند. API های Android و WebRedirect API نسخه API را به عنوان پارامتر به درخواست ارسال می کنند. تماس های سرور به سرور نسخه را به عنوان بخشی از مسیر URL منتقل می کنند.
نسخه ها با جریان ثابت نمی شوند. بنابراین در طول انتقال از N به M، یک ادغام‌کننده ممکن است یک کپچر با نسخه M و بازپرداخت با نسخه N برای همان تراکنش را ببیند. در طول ارتباط، یکپارچه‌ساز ممکن است یک درخواست احراز هویت نسخه M را با درخواست ارتباط نسخه N دریافت کند.
شناسه انجمن
associationID ارتباط بین حساب مشتری و ابزار Google را مشخص می کند. associationId بسیار شبیه GPT است. در واقع، طول عمر آن برابر با یک GPT است و دارای کاردینالیتی 1:1 به GPT است. associationId از نظر حساسیت با GPT متفاوت است. GPT یک توکن حساس است که برای پرداخت استفاده می شود. associationId یک شناسه عمومی است که همان رابطه را نشان می دهد، اما ماهیت آن حساس نیست.
associationId در طول associateAccount به یکپارچه‌ساز پرداخت منتقل می‌شود. همین مقدار در حین احراز هویت مجدد به انتگرال منتقل می شود. این به ادغام‌کننده اجازه می‌دهد تا در مورد اینکه چه حسابی باید احراز هویت شود، متنی داشته باشد. اگر شناسه انجمن ارسال شده باشد، همان حسابی که در طول انجمن اصلی شناسایی شده است باید از قبل پر شده و بر اساس آن احراز هویت شود.
انتظار می‌رود که یکپارچه‌کننده پرداخت، همه شناسه‌های مرتبط را ذخیره کند و آنها را با یک حساب یکپارچه‌ساز خاص در طول مدت قرارداد بین یکپارچه‌ساز و Google مرتبط کند.
شناسه درخواست احراز هویت
روش‌های refreshToken ، associateAccount و (اختیاری) capture به یک احراز هویت ارجاع می‌دهند. این مرجع به شکل requestId احراز هویت خاصی است که Google به آن اشاره می کند. این فیلد باید توسط یکپارچه‌ساز پرداخت استفاده شود تا تأیید کند که واقعاً روش با تأیید اعتبار موفقیت‌آمیز انجام شده است.
روش های ضبط می توانند دارای یک requestId احراز هویت باشند. این در دو مورد اتفاق می افتد. اگر Google درست قبل از عکس گرفتن، کاربر را احراز هویت کند، Google قسمت requestId شناسه احراز هویت را پر می کند. همچنین، Google اغلب در زمان راه‌اندازی زمانی که برنامه پرداخت خودکار تنظیم می‌شود، کاربر را احراز هویت می‌کند. Google requestId احراز هویت را در آن زمان‌بندی می‌نویسد و requestId به همراه هر تصویر مرتبط با آن زمان‌بندی خاص ارسال می‌کند.
انتظار می‌رود که یکپارچه‌سازهای پرداخت، تمام requestIds احراز هویت را به مدت 30 روز ذخیره کنند. اگر یکپارچه‌ساز پرداخت بخواهد requestIds احراز هویت را که می‌توانند در یک درخواست ضبط وجود داشته باشند، از جمله مواردی که در زمان‌بندی‌های پرداخت گنجانده شده‌اند، بازرسی کند، در این صورت یکپارچه‌کننده باید همه requestId احراز هویت را برای مدت زمان قرارداد بین یکپارچه‌ساز و Google ذخیره کند.
شرکت
شرکت مفهومی است که در پیکربندی و قرارداد گوگل تعریف شده است. یک شرکت رابطه بین ادغام کننده و گوگل را تعریف می کند. کلیدهای PGP و (اختیاری) SSL Root CA با شرکت مرتبط هستند. مهمتر از همه، یک شرکت با یک یا چند شناسه حساب یکپارچه پرداخت مرتبط است. GPTهای ایجاد شده در یک شرکت عمدتاً برای همه شناسه‌های حساب یکپارچه‌کننده پرداخت در شرکت کار می‌کنند. برخی استثناها اعمال می شود. به عنوان مثال، اگر GPT با حسابی با یک ارز مرتبط باشد (و کارمزدهای FX را پشتیبانی نمی کند) و در تلاش است تا با یک شناسه حساب یکپارچه کننده پرداخت به ارز دیگری خرید کند.
فرم پرداخت (FOP)
همه تراکنش‌ها شامل یک یا چند روش پرداخت (FOP)، مانند کارت اعتباری یا انتقال الکترونیکی وجوه است که یا توسط کاربران برای پرداخت به Google برای محصول یا خدمات یا توسط Google برای پرداخت به کاربران در مورد کاربران AdSense و Google استفاده می‌شود. توسعه دهندگان را بازی کنید. روش‌های پرداخت نیز اغلب ابزارهای پرداخت، ابزارها و روش‌های پرداخت نامیده می‌شوند.
توکن Google Payment (GPT)
GPT یک مقدار رمزگذاری شده تصادفی و ایمن مبتنی بر وب است که توسط سرور Google در زمان ارتباط ایجاد شده و به سرور یکپارچه منتقل می شود. GPT یک شناسه خصوصی است که نشان دهنده ارتباط بین حساب کاربر با یکپارچه ساز و ابزار Google است. GPT رمزی است که جایگزین اطلاعات کاربری یا شناسه حساب کاربری می شود. این توکن در جریان خرید برای شناسایی حساب به اعتبار یا بدهکار استفاده می شود و برای هر دو طرف مخفی است. GPT هرگز نباید به صورت متن واضح ارسال شود و برای اطمینان از حفظ حریم خصوصی باید رمزگذاری شود.
GPT با associationId متفاوت است زیرا associationId محافظت نمی شود و آزادانه از طریق وسایل عمومی (URL، اتصالات ناامن) منتقل می شود. GPT فقط برای گوگل و ادغام کننده شناخته شده است.
انتظار می‌رود که یکپارچه‌کننده پرداخت، تمام GPTS را ذخیره کند و آنها را با یک حساب یکپارچه‌ساز خاص برای طول عمر قرارداد بین ادغام‌کننده و Google مرتبط کند.
ناتوانی
یک عمل بی توان را می توان چندین بار بدون تغییر نتیجه یا داشتن عوارض جانبی جدید فراتر از اعمال اولیه عمل اعمال کرد. معمولاً ناتوانی از یک "کلید" برای شناسایی همان درخواست استفاده می کند. تمام درخواست های تعریف شده بین دو سرور از یک کلید idempotency تعریف شده در هدر درخواست استفاده می کنند. هدر درخواست دارای شناسه درخواست است که به عنوان کلید عدم توانایی استفاده می شود. شناسه درخواست در سطح جهانی منحصر به فرد است. درخواست‌های Idempotent باید دقیقاً همان بدنه JSON با یک استثنا باشند. requestTimestamp برای هر درخواست متفاوت خواهد بود. این یک تمایز مهم است. requestTimestamp زمانی است که سرور این درخواست را ارسال کرده است. و در هر تلاش منحصر به فرد است. این به کاهش توانایی حملات تکراری کمک می کند. به همین ترتیب، یک پاسخ idempotent باید دقیقاً همان بدنه JSON باشد به جز اینکه responseTimestamp برای هر پاسخ متفاوت است.
همه روش های سرور به سرور به جز روش اکو باید فاقد قدرت باشند. درخواست‌های احراز هویت به رابط کاربری ادغام‌کننده (چه آندروید باشد چه وب) بی‌قدرت نیستند.
برای نمونه‌هایی از رفتار ناتوان، به سند مرجع مراجعه کنید.
شناسه (شناسه)
شناسه ها نشان دهنده یک تراکنش یا ارتباط بین یکپارچه کننده پرداخت و Google هستند.
ابزار
این ابزار یک روش پرداخت ذخیره شده مرتبط با یک مشتری Google را نشان می دهد. نمونه هایی از سازها عبارتند از:
- شماره کارت اعتباری در پرونده
- یک حساب بانکی و شماره مسیریابی
کاربران می توانند چندین ابزار مرتبط با هویت Google خود داشته باشند.
میکرو
مقادیر پولی در این API با استفاده از قالبی به نام "micro" که یک استاندارد در Google است، نشان داده می شود. میکرو یک قالب دقیق و ثابت مبتنی بر عدد صحیح است. برای نمایش یک ارزش پولی در میکرو، ارزش ارز استاندارد را در 1,000,000 ضرب کنید.
مثلا:
- USD $1.23 = 1230000 میکرو USD
- USD $0.01 = 10000 میکرو USD
یکپارچه کننده پرداخت
یکپارچه ساز خارجی که پرداخت ها را برای تراکنش کاربر پردازش می کند.
شناسه حساب یکپارچه ساز پرداخت
این شناسه محدودیت‌های مربوط به قرارداد بین Google و ادغام‌کننده را نشان می‌دهد. شناسه حساب یکپارچه توسط Google ایجاد می‌شود و در طول زمان راه‌اندازی به ادغام‌کننده اختصاص می‌یابد. معمولاً به این "MID" گفته می شود. همه درخواست ها و پاسخ ها باید شامل این شناسه باشند. این شناسه مات است و هرگز نباید تجزیه شود. قالب این شناسه ممکن است در همه شناسه‌های صادر شده سازگار نباشد.
این شناسه هرگز در طول عمر تراکنش تغییر نمی کند. در مورد گرفتن و بازپرداخت، از همان شناسه استفاده می شود.
محدودیت های شناسه حساب یکپارچه ساز توسط خود قرارداد تعریف می شود. به طور کلی، محدودیت ها در مورد صورتحساب است. به عنوان مثال، یک ادغام‌کننده از CAD و MXN پشتیبانی می‌کند که به صورت USD صورتحساب می‌شود، اما نیاز دارد که تراکنش‌های EUR به یورو صورتحساب شوند. در این مورد از دو شناسه حساب یکپارچه کننده پرداخت متفاوت استفاده می شود، یکی برای صورتحساب USD و دیگری برای صورتحساب یورو.
شناسه را می توان به نفع شناسه های جدید حذف کرد. در مواردی که یک شناسه منسوخ شده باشد، Google شروع به گرفتن عکس از آن شناسه را متوقف خواهد کرد. با این حال، ادغام‌کننده requestHeader به بازپرداخت تراکنش‌های انجام‌شده در برابر آن شناسه به مدت یک سال از آخرین شروع ضبط requestTimestamp احترام بگذارد.
PII
اطلاعات شناسایی شخصی (PII) اطلاعاتی است که شخصاً یک فرد و هر داده دیگری را که می‌تواند به طور منطقی توسط Google به این اطلاعات مرتبط شود، مانند نام کاربر، آدرس ایمیل، آدرس پستی یا شماره تلفن، به تنهایی یا به صورت ترکیبی، شناسایی می‌کند.
شناسه درخواست
requestId تمام ارتباطات بین Google و یکپارچه‌ساز پرداخت را مشخص می‌کند.
SPII
اطلاعات قابل شناسایی شخصی حساس (SPII) زیرمجموعه ای از اطلاعات شناسایی شخصی (PII) است که در صورت به خطر افتادن یا سوء استفاده از آنها خطر بالایی برای کاربر ایجاد می کند. SPII اغلب دارای الزامات مدیریتی و ذخیره سازی محدودی است که توسط نهادهای قانونی، نظارتی یا انطباق اعمال می شود.
رمز
هنگامی که اعتبارنامه های حساسی مانند PII یا SPII بین Google و ادغام کننده رد و بدل می شود، توکن ها یک لایه امنیتی اضافی اضافه می کنند.
آدرس کاربر
در زمان ایجاد ابزار، Google بررسی می‌کند که آیا کاربر مشتری Google Payments است یا خیر. این مستقل از مشتری گوگل بودن است. برای اینکه مشتری Google Payments باشیم، به آدرس صورتحساب کاربر نیاز داریم. برخی از سازمان های نظارتی از ما می خواهند که آدرس کامل کاربر را بدانیم، در حالی که برخی دیگر به زیرمجموعه ای از آن آدرس نیاز دارند.
اگر ادغام‌کننده پرداخت، آدرسی برای این کاربر در پرونده داشته باشد، Google می‌خواهد آن آدرس را در جریان ارتباط دریافت کند تا فرم آدرس را از قبل برای کاربر پر کند. کاربر این گزینه را دارد که آدرس از پیش پر شده را تغییر دهد. از قبل پر کردن آدرس کاربر اصطکاک در اضافه کردن ابزار را کاهش می دهد و نرخ تبدیل کاربرانی که این ابزار را اضافه می کنند را افزایش می دهد.
اگر آدرس به اشتراک گذاشته شود، گوگل نیز از آن به عنوان یک محاسبه در مدل ریسک خود استفاده می کند. این به موتور ریسک گوگل اجازه می‌دهد تا آدرسی را که کاربر می‌گوید در آن صورتحساب دریافت می‌کند، درک کند، در حالی که آن را با مکان IP که کاربر در حال حاضر در آن قرار دارد مقایسه می‌کند.
اشتراک آدرس صرفاً یک بهینه سازی است. خوب است و انتظار می رود که برخی از ادغام کنندگان آدرس صورتحساب برای کاربر نداشته باشند یا نتوانند این آدرس را به اشتراک بگذارند.
Web-Safe Base64-Encoding
استاندارد رمزگذاری مشخص شده در RFC 4648 بخش 5، کدگذاری پایه 64 با URL و الفبای ایمن نام فایل، همچنین گاهی اوقات به عنوان رمزگذاری "Web-safe Base64" یا "base64url" نیز شناخته می شود. (این همان رمزگذاری base64 با URL و الفبای امن نام فایل از RFC 3548 بخش 4 است.) همه مقادیر رمزگذاری شده و امضا شده باید با استفاده از این استاندارد کدگذاری شوند.