تراکنش‌های آغازشده توسط فروشنده (MIT)

نمای کلی پشتیبانی MIT

«تراکنش‌های آغازشده ازسوی فروشنده» (MIT) تراکنش‌هایی هستند که بدون حضور فعال کاربر در جلسه پردازش می‌شوند. این به‌روزرسانی «میانای برنامه‌سازی کاربردی آنلاین Google Pay» نمایان بودن این نوع تراکنش‌ها را بهبود می‌بخشد، تجربه کاربری را ازطریق تجربه کاربری اختصاصی جزئیات صورت‌حساب بهبود می‌دهد، و تداوم پرداخت را بهتر می‌کند.

موارد استفاده کلیدی

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

پیاده‌سازی MIT API

«میانای برنامه‌سازی کاربردی MIT» توسعه‌ای از LoadPaymentData میانای برنامه‌سازی کاربردی موجود است. ادغام‌کنندگان باید دقیقاً یک *TransactionInfo شیء را برای مشخص کردن هدف صورت‌حساب اضافه کنند. ‫Google بسته به نوع «تراکنش آغازشده توسط فروشنده» ۳ گزینه ارائه می‌دهد:

• RecurringTransactionInfo
• DeferredTransactionInfo
• AutomaticReloadTransactionInfo

توجه: این موارد فقط برای «تراکنش‌های آغازشده توسط فروشنده» است. همه تراکنش‌های دیگر همچنان از شیء TransactionInfo موجود استفاده می‌کنند.

نوع تراکنش	نام شی	شرح
تکرارشونده	RecurringTransactionInfo	برای هزینه‌های با تناوب ثابت استفاده می‌شود. از دوره‌های آزمایشی، صورت‌حساب پیش‌پرداخت، و صورت‌حساب پس‌پرداخت پشتیبانی می‌کند.
به‌تعویق‌افتاده	DeferredTransactionInfo	برای کسر هزینه یک‌باره در زمان آینده‌ای ازپیش تعیین‌شده استفاده می‌شود.
بار کردن مجدد خودکار	AutomaticReloadTransactionInfo	برای بار کردن مجدد حساب دارای مقدار ذخیره‌شده وقتی موجودی از حداقل آستانه کمتر می‌شود استفاده می‌شود.

مراحل یکپارچه‌سازی

1. مستندات: سه تعریف جدید شیء در بخش «مرجع شیء» مستندات قرار دارند و در فهرست قبلی مستقیماً پیوند داده شده‌اند.
2. پیاده‌سازی: از شیء(های) *TransactionInfo مربوطه برای سیستم خود در درخواست API استفاده کنید.
   • توجه داشته باشید که در هر درخواست به API فقط یک شیء می‌تواند ارسال شود. تعیین اینکه از کدام شیء استفاده شود و پر کردن فیلدها برعهده بازرگان است.
3. آزمایش: از محیط «آزمایش» برای اعتبارسنجی جزئیات صورت‌حساب استفاده کنید تا مطمئن شوید در برگه پرداخت به‌درستی ارائه می‌شود.
4. راه‌اندازی: پس‌از درستی‌سنجی پارامترها، پخش زنده را شروع کنید.

توجه: درحال‌حاضر، قیمت‌گذاری پویا برای «تراکنش‌های آغازشده توسط فروشنده» پشتیبانی نمی‌شود. این یک محدودیت شناخته‌شده است.

مدیریت چرخه حیات داده‌واحد (TLM)

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

مهم: برای اینکه «مدیریت چرخه حیات رمز» برای تراکنشی معین اعمال شود، tokenUpdateUrl باید در *TransactionInfo شیء مربوطه گنجانده شود.

رویدادهای کلیدی رمز

• غیرفعال‌سازی/حذف: وقتی یک کد دیگر قابل‌استفاده نباشد، اعلان می‌کند.
• به‌روزرسانی‌های پسوند FPAN: زمانی رخ می‌دهد که «شماره حساب اصلی تأمین وجه» زیرین به‌روز شود.

الزامات راه‌اندازی سرور

«فروشندگان مستقیم» و «ارائه‌دهندگان خدمات پرداخت» (PSPs) باید سیستمی برای دریافت، رمزگشایی، و پردازش این پیام‌ها ایجاد کنند.

الزام	شرح
نقطه پایانی	نقطه پایان HTTPS امن برای دریافت تماس‌های POST.
اصالت‌سنجی	باید اعتبارسنجی امضا و رمزگشایی پیام را انجام دهد.
پاسخ	برای ادامه اعلان‌ها، «موفقیت» را برگردانید، یا برای توقف آن‌ها، «نشان یافت نشد»/ «نشان درحال استفاده نیست» را برگردانید.
اعلان فروشنده	«ارائه‌دهندگان خدمات پرداخت» باید وضعیت رمز را به فروشندگان خود اطلاع دهند.

یادداشت‌های پیاده‌سازی

نقطه پایانی tokenUpdateUrl باید همراه با تراکنش ارسال شود تا به‌روزرسانی‌های رمز دریافت شود. برای «ارائه‌دهندگان خدمات پرداخت»، تعیین اینکه فروشندگان چگونه این نشانی وب را در شیء *TransactionInfo مربوطه دریافت و تکمیل کنند، برعهده «ارائه‌دهنده خدمات پرداخت» است.

همچنین توجه داشته باشید که پایه‌بار رمزگذاری‌شده فیلد اختیاری دیگری به‌نام merchantTokenId برای MIT برمی‌گرداند. برای جزئیات بیشتر، به رمزنگاری داده‌های پرداخت مستندات (برای «فروشندگان») یا ساختار داده‌بر مستندات (برای «ارائه‌دهندگان خدمات پرداخت») مراجعه کنید.