FOP نقدی، FOP نقدی

بررسی اجمالی

Google Standard Payments از FOPهای مبتنی بر پول نقد (اشکال پرداخت) مانند خرید فروشگاه های رفاهی (مانند 7-Eleven) پشتیبانی می کند. در سطح بالایی، کاربری که می‌خواهد برای کالاها پرداخت کند، یک شماره مرجع از طریق یکپارچه‌ساز پرداخت تولید می‌کند. سپس کاربر این شماره مرجع را به فروشگاه، کیوسک یا بانک می برد و شماره مرجع را پرداخت می کند.

توجه: به FOP نقدی FOP شماره مرجع نیز گفته می شود.

1) کاربر یک روش پرداخت اضافه می کند

2) سپس آنها انتخاب می کنند که کجا پرداخت کنند

3) در نهایت دستورالعمل پرداخت به آنها داده می شود

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

{% 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، از روش پرداخت یک کاربر خاص. از آنجایی که حاوی تمام اطلاعات مورد نیاز برای خرید است، توکن نیز یک ابزار است. این ممکن است شامل اطلاعاتی مانند شماره حساب کاربر با یکپارچه ساز خود باشد.

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

Google از دو جریان کلیدی برای ایجاد و پرداخت این شماره های مرجع استفاده می کند:

1. جریان شماره مرجع را ایجاد کنید.
2. جریان شماره مرجع پرداخت.

بعداً، تسویه حساب و تسویه حاصل از خریدها توسط جریان حواله انجام می شود.

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

نمای کلی FOP نقدی

دو جریان اول با جزئیات بیشتر در بخش های بعدی توضیح داده شده است. اگر می خواهید در مورد آن جریان بیشتر بدانید، صفحه جریان حواله را ببینید.

شماره مرجع تولید کنید

هدف از تولید جریان شماره مرجع ایجاد و مبادله یک شناسه (شماره مرجع) است که هم گوگل و هم ادغام کننده می توانند برای شناسایی خرید از آن استفاده کنند. سپس کاربر می تواند از این شماره مرجع در فروشگاه، کیوسک یا بانک برای تکمیل خرید استفاده کند. این شناسه به درخواست گوگل با فراخوانی متد generateReferenceNumber توسط یکپارچه ساز تولید می شود. درخواست تولید شماره مرجع شامل مبلغ و شرح تراکنش است.

نمودار زیر نشان می دهد که چگونه یک شماره مرجع تولید و به همراه دستورالعمل برای مشتری ارسال می شود.

جریان شماره مرجع را ایجاد کنید

در اینجا لیستی از اشیاء و آنچه که آنها نشان می دهند آمده است:

• کاربر : این شخصی است که می خواهد برای چیزی با استفاده از این روش پرداخت هزینه کند.
• Google UI : این رابطی است که کاربر خرید خود را در آن انجام می دهد. این می تواند از طریق وب یا از طریق یک برنامه باشد.
• Google Server : سرور پشتیبان در Google که درخواست تولید شماره مرجع را می دهد و دستورالعمل های پرداخت را برای کاربر ایجاد می کند.
• سرور یکپارچه‌ساز پرداخت : سرور باطنی Payment Integrator که جزئیات پرداخت را پیگیری می‌کند و شماره مرجع را تولید می‌کند.

این جریان با کاربری شروع می شود که می خواهد از این روش پرداخت نقدی استفاده کند.

1. کاربر به رابط کاربری Google دسترسی پیدا می کند که درخواستی برای شماره مرجع ارسال می کند.
2. رابط کاربری Google پیامی به سرور Google ارسال می کند که به شماره مرجع نیاز دارد ( getReferenceNumber ).
3. سرور Google از سرور یکپارچه‌ساز پرداخت می‌خواهد تا یک شماره مرجع ایجاد کند ( generateReferenceNumber ).
4. سرور Payment Integrator شماره مرجع را تولید و به سرور Google ارسال می کند.
5. سرور Google دستورالعمل های پرداخت را به همراه شماره مرجع ایجاد می کند. سپس این اطلاعات را به رابط کاربری گوگل ارسال می کند.
6. رابط کاربری Google این دستورالعمل ها و شماره مرجع را برای کاربر ارسال می کند.

نکات مربوط به شماره های مرجع

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

علاوه بر نمایش شماره مرجع، رابط های کاربری گوگل می توانند به صورت اختیاری شماره مرجع را در قالب کد 128 (فرمت بارکد) نشان دهند. سایر فرمت های بارکد را می توان با درخواست پشتیبانی کرد.

شماره مرجع پرداخت

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

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

هنگامی که کاربر پرداخت کرد، یکپارچه‌ساز باید فوراً به Google اطلاع دهد که این شماره مرجع از طریق روش referenceNumberPaidNotification پرداخت شده است. با فراخوانی این روش در عرض چند ثانیه پس از پرداخت فیزیکی کاربر، یکپارچه ساز به کاربر اجازه می دهد تا کالاهای خود را به سرعت دریافت کند. (اگر شبکه قطع باشد این تماس را می توان به صف اضافه کرد.)

پس از پرداخت، شماره مرجع و مبلغ در صورت حواله ارسالی در روز T+2 درج می شود.

توجه: اگر Google خطایی را در referenceNumberPaidNotification برگرداند، سرور شما باید درخواست را به‌طور نامحدود با عقب‌نشینی تصاعدی دوباره امتحان کند و باید با نقطه تماس Google خود تماس بگیرید تا مشکل را به آن‌ها اطلاع دهید.

در اینجا یک نمودار توالی است که پرداخت یک شماره مرجع را نشان می دهد.

جریان شماره مرجع پرداخت

اشیاء در نمودار موارد زیر را نشان می دهند:

• کاربر : این شخصی است که می خواهد برای چیزی با استفاده از این روش پرداخت هزینه کند.
• فروشگاه رفاه : مکانی که کاربر با استفاده از شماره مرجع و دستورالعمل های داده شده، مانند فروشگاه رفاه، پرداخت خود را انجام می دهد.
• سرور یکپارچه‌ساز پرداخت : سرور باطنی Payment Integrator که جزئیات پرداخت را پیگیری می‌کند.
• Google Server : سرور پشتیبان در Google که درخواست تولید شماره مرجع را می دهد و دستورالعمل های پرداخت را برای کاربر ایجاد می کند.

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

1. کاربر برای پرداخت به یک فروشگاه رفاه مراجعه می کند.
2. پس از تکمیل تراکنش، فروشگاه رفاه به ادغام کننده پرداخت از پرداخت اطلاع می دهد.
3. سرور ادغام کننده پرداخت پیام موفقیت آمیزی را به فروشگاه رفاه ارسال می کند.
4. فروشگاه رفاه به اطلاع کاربر می رساند که این تراکنش موفقیت آمیز بوده و کالا به زودی به کاربر تحویل داده خواهد شد.
5. سرور Payment Integrator پیامی به سرور Google ارسال می کند که شماره مرجع پرداخت شده است ( referenceNumberPaidNotification ). این مرحله نباید مرحله 4 را مسدود کند.
6. سرور Google با پیام موفقیت به سرور Payment Integrator پاسخ می دهد.

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

لغو شماره مرجع

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

اگر فرآیند پرداخت قبلاً شروع شده باشد، به عنوان مثال اگر کاربر شماره مرجع خود را در کیوسک وارد کرده باشد اما هنوز پرداخت نکرده است، ادغام‌کننده باید کد پاسخ HTTP 423 با ErrorResponse حاوی USER_ACTION_IN_PROGRESS برگرداند.

توجه: این روش پرداخت از بازپرداخت پشتیبانی نمی کند.

بعدی: جریان حواله