Google Standard Payments:

FOP توکن شده

بررسی اجمالی

یک FOP توکن شده (شکل پرداخت) یکی از انواع ادغام پرداخت در بستر پرداخت است. برای اینکه کاربر بتواند با این FOP پرداختی انجام دهد، Google و ادغام کننده Payment باید یک بار اعتبار هویت حساب را مبادله کنند. این به نوبه خود از طریق جریان ایجاد یک توکن، نشان دهنده آن شکل پرداخت برای آن کاربر خاص است. سپس می توان از این توکن برای پرداخت بارها و بارها استفاده کرد. در حال حاضر 2 نسخه از این API ها وجود دارد. نسخه 2 از اپراتورهای تلفن همراه و ارائه دهندگان شماره مرجع پشتیبانی می کند. سایر ارائه دهندگان FOP توکن شده باید نسخه 1 را پیاده سازی کنند. بقیه این سند بر روی نسخه 1 متمرکز است.

گوگل از دو جریان برای ایجاد هویت و ایجاد این توکن استفاده می کند:

1. جریان احراز هویت : کاربر را شناسایی و تأیید می کند (احراز هویت).
2. جریان ارتباط : یک نشانه برای یک کاربر (جدید یا قبلاً شناسایی و احراز هویت شده) ایجاد می کند. این توکن نشان دهنده شکل خاصی از پرداخت توسط یک کاربر خاص است. سپس ممکن است این توکن در خریدهای بعدی مورد استفاده قرار گیرد.

پس از ایجاد توکن، Google از آن در طول جریان خرید استفاده می‌کند تا تجربه پرداخت سریع و یکپارچه برای کاربر داشته باشد. Google از این نشانه برای نشان دادن نمونه ای از روش پرداخت توسط مشتری استفاده می کند. به این ساز هم می گویند. یک مشتری Google ممکن است بیش از یک ابزار برای پرداخت برای کالاها و خدمات داشته باشد.

در نهایت، تمام جابجایی پول بین بانک ادغام‌کننده و بانک Google در جریان حواله انجام می‌شود.

1) کاربر محصولی را برای خرید انتخاب می کند

2) سپس یک روش پرداخت را انتخاب می کنند

3) اکنون، آنها یک روش پرداخت جدید اضافه می کنند

4) برای احراز هویت هدایت می شوند

5) در نهایت آنها احراز هویت می شوند و می توانند خرید کنند

این نمودار یک نمای کلی از جریان ها را نشان می دهد:

نمای کلی FOP توکن شده

در سطح بالایی، افزودن سرویس خود به عنوان نوعی پرداخت به محصولات Google شامل این جریان‌ها می‌شود:

1. جریان احراز هویت
2. جریان انجمن
3. جریان خرید
4. جریان بازپرداخت
5. جریان حواله

این جریان ها با جزئیات بیشتر در بخش های زیر و با جزئیات بیشتر در بخش راهنماها توضیح داده شده اند.

مفاهیم و اصطلاحات

{% if "standard-payments" در dynamic_data.request.path %} {% setvar documentation_base_path %}/standard-payments{% endsetvar %} {% elif "pay/banking-fop-v2" در dynamic_data.request.path %} {% setvar documentation_base_path %}/pay/banking-fop-v2{% endsetvar %} {% setvar spec_name %}banking-fop-v2{% endsetvar %} {% elif "pay/card-fop-v1" در dynamic_data.request.path %} {% setvar documentation_base_path %}/pay/card-fop-v1{% endsetvar %} {% setvar spec_name %}card-fop-v1{% endsetvar %} {% elif "pay/card-management-v1" در dynamic_data.request.path %} {% setvar documentation_base_path %}/pay/card-management-v1{% endsetvar %} {% setvar spec_name %}card-management-v1{% endsetvar %} {% elif "pay/carriers-v1" در dynamic_data.request.path %} {% setvar documentation_base_path %}/pay/carriers-v1{% endsetvar %} {% setvar spec_name %}carriers-v1{% endsetvar %} {% elif "pay/carrier-wallets-v1" در dynamic_data.request.path %} {% setvar documentation_base_path %}/pay/carrier-wallets-v1{% endsetvar %} {% setvar spec_name %}carrier-wallets-v1{% endsetvar %} {% elif "pay/e-wallets-v1" در dynamic_data.request.path %} {% setvar documentation_base_path %}/pay/e-wallets-v1{% endsetvar %} {% setvar spec_name %}e-wallets-v1{% endsetvar %} {% elif "pay/chargeback-alert-v1" در dynamic_data.request.path %} {% setvar documentation_base_path %}/pay/chargeback-alert-v1{% endsetvar %} {% setvar spec_name %}chargeback-alert-v1{% endsetvar %} {% elif "pay/golden-fop-v1" در dynamic_data.request.path %} {% setvar documentation_base_path %}/pay/golden-fop-v1{% endsetvar %} {% setvar spec_name %}golden-fop-v1{% endsetvar %} {% elif "pay/facilitated-transaction-event-v2" در dynamic_data.request.path %} {% setvar documentation_base_path %}/pay/facilitated-transaction-event-v2{% endsetvar %} {% setvar spec_name %}facilitated-transaction-event-v2{% endsetvar %} {% elif "pay/india-cards-v1" در dynamic_data.request.path %} {% setvar documentation_base_path %}/pay/india-cards-v1{% endsetvar %} {% setvar spec_name %}india-cards-v1{% endsetvar %} {% elif "pay/issuers/apis/push-provisioning/server" در dynamic_data.request.path %} {% setvar documentation_base_path %}/pay/issuers/apis/push-provisioning/server{% endsetvar %} {% setvar spec_name %}push-provisioning-v1{% endsetvar %} {% elif "pay/one-time-payment-code-v1" در dynamic_data.request.path %} {% setvar documentation_base_path %}/pay/one-time-payment-code-v1{% endsetvar %} {% setvar spec_name %}one-time-payment-code-v1{% endsetvar %} {% elif "pay/redirect-fop-v1" در dynamic_data.request.path %} {% setvar documentation_base_path %}/pay/redirect-fop-v1{% endsetvar %} {% setvar spec_name %}redirect-fop-v1{% endsetvar %} {% elif "pay/redirect-payment-token-v1" در dynamic_data.request.path %} {% setvar documentation_base_path %}/pay/redirect-payment-token-v1{% endsetvar %} {% setvar spec_name %}redirect-payment-token-v1{% endsetvar %} {% elif "pay/refundable-one-time-payment-code-v1" in dynamic_data.request.path %} {% setvar documentation_base_path %}/pay/refundable-one-time-payment-code-v1{% endsetvar %} {% setvar spec_name %}refundable-one-time-payment-code-v1{% endsetvar %} {% elif "pay/refundable-one-time-payment-code-v2" in dynamic_data.request.path %} {% setvar documentation_base_path %}/pay/refundable-one-time-payment-code-v2{% endsetvar %} {% setvar spec_name %}refundable-one-time-payment-code-v2{% endsetvar %} {% elif "pay/value-on-device-fop-v1" در dynamic_data.request.path %} {% setvar documentation_base_path %}/pay/value-on-device-fop-v1{% endsetvar %} {% setvar spec_name %}value-on-device-fop-v1{% endsetvar %} {% elif "pay/virtual-cards-v1" در dynamic_data.request.path %} {% setvar documentation_base_path %}/pay/virtual-cards-v1{% endsetvar %} {% setvar spec_name %}virtual-cards-v1{% endsetvar %} {% endif %}

نمادها و قراردادها

کلمات کلیدی "باید"، "نباید"، "الزامی"، "باید"، "نباید"، "باید"، "نباید"، "توصیه شده"، "ممکن است" و "اختیاری" در این اسناد هستند. همانطور که در RFC 2119 شرح داده شده است تفسیر شود.

مهر زمانی

همه مهرهای زمانی به عنوان میلی ثانیه از زمان یونیکس (1 ژانویه 1970) در UTC نشان داده می شوند.

مثلا:

• 23 آوریل 2019 8:23:25 بعد از ظهر به وقت گرینویچ = 1556051005000 میلی ثانیه
• 16 آگوست 2018 12:28:35 بعد از ظهر به وقت گرینویچ = 1534422515000 میلی ثانیه

مبالغ

مقادیر پولی در این API در قالبی به نام "micro" هستند که یک استاندارد در Google است. میکرو یک قالب دقیق و ثابت مبتنی بر عدد صحیح است. برای نمایش یک ارزش پولی در میکرو، ارزش ارز استاندارد را در 1,000,000 ضرب کنید.

مثلا:

• USD $1.23 = 1230000 میکرو USD
• USD $0.01 = 10000 میکرو USD

ناتوانی

همه فراخوانی‌های متد در این API باید رفتار ناتوانی داشته باشند. Google به‌طور پراکنده درخواست‌ها را مجدداً امتحان می‌کند تا مطمئن شود که تراکنش‌ها در هر دو طرف در یک وضعیت هستند. ادغام کننده ها نباید سعی کنند هر درخواستی را که قبلاً با موفقیت پردازش شده است، دوباره پردازش کنند. پاسخ برای پردازش موفقیت آمیز باید به جای آن گزارش شود. همه متدها یک RequestHeader مشترک دارند که حاوی یک requestId است. این requestId کلید ناتوانی برای همه تماس‌ها است.

هر پاسخ غیر پایانه ای (یک غیر HTTP 200-موفق)، نباید به صورت بی اختیار پردازش شود. بنابراین درخواستی که قبلاً یک 400 دریافت کرده است (درخواست بد/پیش شرط ناموفق)، وقتی برای بار دوم فراخوانی می‌شود، نباید 400 را به طور غیرقابل قبولی برگرداند، باید مجدداً ارزیابی شود. در ارزیابی مجدد، می تواند 400 را برگرداند یا با موفقیت پردازش شود.

برای اطلاعات بیشتر در مورد ناتوانی جنسی، این راهنمای دقیق را ببینید.

یکپارچه ساز

شرکتی که از پلتفرم پرداخت گوگل برای کسب و کار خود استفاده می کند. این می تواند داخلی (1P) باشد، مانند یوتیوب یا AdWords، همچنین می تواند یک تجارت خارجی (3P) باشد که می خواهد سرویس خود را برای کار با اکوسیستم Google یکپارچه کند.

FOP

فرم پرداخت. این کلی تر از یک ساز است. ویزا، مسترکارت و پی پال همگی FOP هستند.

ابزار

یک نمونه خاص از یک نوع پرداخت توسط یک مشتری خاص. به عنوان مثال، کارت اعتباری یک کاربر، یا حساب PayPal آنها. یک FOP توکن شده برای یک مشتری خاص نیز یک ابزار است، زیرا نمونه ای از نوعی پرداخت برای آن مشتری است که به طور ایمن در سیستم ما ذخیره می شود.

رمز

نمایشی، در سیستم Google، از روش پرداخت یک کاربر خاص. از آنجایی که حاوی تمام اطلاعات مورد نیاز برای خرید است، توکن نیز یک ابزار است. این ممکن است شامل اطلاعاتی مانند شماره حساب کاربر با یکپارچه ساز خود باشد.

جریان های کلیدی

جریان احراز هویت

احراز هویت اولین جریانی است که باید انجام شود. هدف از جریان احراز هویت شناسایی و احراز هویت کاربر به یکپارچه ساز است. احراز هویت می تواند به روش های مختلفی انجام شود. FOP های توکن شده از دو روش برای شناسایی و احراز هویت کاربر پشتیبانی می کنند:

1. احراز هویت SMS-MT OTP (پیامک تلفن همراه خاتمه یافته، رمز عبور یک بار مصرف)
2. Redirect Authentication

هنگام ورود، یکپارچه‌سازها با Google کار می‌کنند تا مکانیسم‌های احراز هویت را انتخاب کنند که بهترین تناسب را با محصولشان دارد.

جریان های احراز هویت را می توان در دو زمینه استفاده کرد: اول، برای شناسایی یک مشتری جدید به منظور ایجاد ارتباط، و دوم، برای به چالش کشیدن یک کاربر برای اعتبار یک ابزار موجود. نتیجه جریان احراز هویت می‌تواند به‌عنوان ورودی برای جریان‌های متعدد، مانند جریان ارتباط ، جریان نشانه‌های تازه ، جریان خرید چالش‌شده و غیره استفاده شود. علاوه بر این، جریان احراز هویت را می توان در حالت مستقل استفاده کرد، بدون اینکه به جریان بعدی گره بخورد.

SMS-MT OTP Authentication

در این مکانیسم احراز هویت، کاربر یک شماره تلفن را در رابط کاربری گوگل وارد می کند. گوگل این شماره تلفن را برای یکپارچه ساز ارسال می کند (از طریق روش sendOtp ). یکپارچه کننده یک رمز عبور یک بار مصرف را برای کاربر ارسال می کند. کاربر رمز عبور را در رابط کاربری گوگل وارد می کند و آن را به همراه یکپارچه ساز ارسال می کند. این باعث پاسخ موفقیت آمیز Payment Integrator می شود.

هنگامی که احراز هویت SMS-MT OTP در حالت مستقل استفاده می شود، مقدار OTP با استفاده از روش verifyOtp به یکپارچه کننده ارسال می شود. این روش تأیید می کند که OTP ارائه شده همانی است که ارسال شده است.

Redirect Authentication

احراز هویت ریدایرکت با هدایت مجدد کاربر توسط Google به یک برنامه متعلق به یکپارچه ساز انجام می شود. این برنامه می تواند یک وب یا یک برنامه اندروید باشد.

تغییر مسیرهای اندروید و وب به طور مشابه عمل می کنند. گوگل کاربر را به برنامه ادغام کننده هدایت می کند. یکپارچه‌ساز کاربر را به هر شکلی که برای آن ادغام‌کننده طبیعی‌تر است، شناسایی و احراز هویت می‌کند. پس از احراز هویت، یکپارچه‌کننده کاربر را به رابط کاربری Google هدایت می‌کند تا ارتباط را به پایان برساند. پس از تغییر مسیر، Google یک requestId برای شناسایی این جلسه احراز هویت ارائه می کند. سپس از آن شناسه به عنوان مدرک احراز هویت در طول انجمن استفاده می شود.

یکپارچه‌کننده‌هایی که این جریان را انتخاب می‌کنند باید یک URL احراز هویت وب ارائه کنند زیرا این مخرج رایج‌ترین مخرج در همه سطوح (دسک‌تاپ یا موبایل) است. با این حال، احراز هویت اندروید به شدت توصیه می شود که بهترین تجربه کاربری را در تلفن همراه ارائه می دهد.

بسته به زمینه دستگاه و برنامه‌های نصب‌شده، رابط‌های کاربری Google وب یا تغییر مسیر برنامه Android را انتخاب می‌کنند.

این مکانیسم احراز هویت بیشترین آزادی را در اختیار ادغام کننده قرار می دهد. راه های زیادی برای احراز هویت و شناسایی کاربر وجود دارد. نام کاربری + رمز عبور، یا اطلاعات بیومتریک و سوالات امنیتی، هر دو راه حل قابل اجرا هستند. گوگل قصد ندارد نحوه تایید یک کاربر را توسط یکپارچه ساز تعیین کند. ادغام کننده از احراز هویت کاربر مراقبت می کند. به این ترتیب، گوگل قصد دارد از رابط های کاربری مختلف ادغام کننده برای احراز هویت کاربر استفاده کند و به سادگی اثبات احراز هویت را به گوگل ارائه دهد.

توجه: اگر ادغام‌کننده قرار است در طول تغییر مسیر از SMS-MT OTP استفاده کند، Google قویاً پیشنهاد می‌کند که از SMS-MT OTP Authentication فوق‌الذکر استفاده کنید. این تجربه یکپارچه‌تر را در ویژگی‌های Google به کاربر ارائه می‌دهد.

برای اطلاعات بیشتر در مورد احراز هویت این راهنمای دقیق را ببینید.

جریان انجمن

پس از جریان احراز هویت از طریق یکی از مکانیسم های ذکر شده در بالا، کاربر از طریق جریان ارتباط حرکت می کند. هدف از جریان ارتباط ایجاد یک رمز پرداخت Google ( GPT ) به منظور ایجاد یک ابزار است. این جریان کارهای زیر را انجام می دهد:

1. برای نشان دادن این کاربر، هویتی به نام توکن مذاکره می کند.
2. اطلاعات حساب را برای اطلاع از موتور خطر Google ارائه می دهد.
3. اطلاعات لازم را برای اولین بار برای ایجاد و ایجاد GPT جمع آوری می کند.

نتیجه این است که GPT ایجاد شده توسط Google و یکپارچه ساز توافق شده است.

این امکان برای دو کاربر گوگل وجود دارد که حساب کاربری یکسانی را با یکپارچه ساز به اشتراک بگذارند. در این حالت، هر کاربر ابزار متفاوتی خواهد داشت. برای هر ابزار یک جریان ارتباط مستقل و بنابراین یک GPT منحصر به فرد وجود دارد.

این تصویر شما را از طریق یک FOP توکن شده جعلی به نام InvisiCash راهنمایی می کند. این نشان دهنده مراحلی است که کاربر برای جریان احراز هویت و جریان ارتباط طی خواهد کرد.

بررسی اجمالی جریان انجمن

1. یک کاربر Google با آدرس ایمیل [e-mail] می خواهد حساب InvisiCash خود را به فروشگاه Google Play اضافه کند تا بتواند از آن برای خرید استفاده کند.
2. فروشگاه Google Play برنامه InvisiCash را برای احراز هویت باز می کند.

3. کاربر با آدرس ایمیل [e-mail] وارد حساب InvisiCash خود می شود. ممکن است او از آدرس ایمیل جیمیل خود برای هر دو استفاده کند، اگر این آدرس ورود به حساب InvisiCash او باشد.

   توجه: راه های دیگری برای احراز هویت وجود دارد. این تنها یک نمونه است. حتی ممکن است این کار در وب انجام شود نه از طریق یک برنامه.

4. برنامه InvisiCash شناسه احراز هویت را به فروشگاه Google Play می فرستد.

5. فروشگاه Google Play شناسه احراز هویت را به سرورهای Google ارسال می کند.

6. سرور گوگل پیامی به سرور InvisiCash ارسال می کند تا حساب را مرتبط کند. این ارتباط شامل شناسه احراز هویت، GPT (توکن پرداخت Google) و شناسه ارتباط است.

7. سرورهای InvisiCash توکن Google Payment ( GPT ) و شناسه ارتباط را ذخیره می‌کنند. هر دو اکنون با حساب InvisiCash سالی مرتبط هستند.

8. InvisiCash این ارتباط را تایید می کند. سپس سرورهای Google ابزاری را ایجاد می کنند که ممکن است برای خریدهای بعدی مورد استفاده قرار گیرد.