اعتبارسنجی نشانی برای تسویه‌حساب

هدف اصلی

این سند روش‌های ترکیب «تکمیل خودکار جا»، Address Validation API۱، و Maps را در تسویه‌حساب تجارت الکترونیک با هدف ثبت نشانی‌های با کیفیت بالا شرح می‌دهد.

پیش‌نیازها

Google توصیه می‌کند با موارد زیر آشنا باشید:

  • مستندات توسعه‌دهنده جاوا اسکریپت تکمیل خودکار جا.
    • از دیدگاه فنی، با نحوه عملکرد «تکمیل خودکار جا» و گزینه‌های پیاده‌سازی آن آشنا شوید.
  • راهنمای پیاده‌سازی تسویه‌حساب برای «تکمیل خودکار جا».
    • نمونه‌هایی از روال‌های مطلوب پیاده‌سازی «تکمیل خودکار جا» در تسویه‌حساب تجارت الکترونیک.
  • Address Validation API مستندات محصول، با تمرکز بر ساختن منطق درستی‌سنجی.
    • از دیدگاه فنی درک کنید که Address Validation API چگونه کار می‌کند و نشان‌هایی را که کیفیت نشانی را تعیین می‌کنند بررسی کنید.

اعتبارسنجی نشانی چیست؟

‫Address Validation API سرویسی است که نشانی را می‌پذیرد. این سرویس اجزای نشانی را شناسایی و آن‌ها را اعتبارسنجی می‌کند. این ویژگی همچنین نشانی را برای ارسال پستی استانداردسازی می‌کند و بهترین مختصات طول/عرض جغرافیایی شناخته‌شده را برای آن پیدا می‌کند. به‌طور اختیاری، برای نشانی‌های ایالات متحده و پورتوریکو، می‌توانید Coding Accuracy Support System (CASS™)‎ را فعال کنید.

چرا در مرحله تسویه‌حساب به اعتبارسنجی نشانی نیاز دارید؟

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

مشتریان را راهنمایی کنید تا نشانی را سریع و دقیق وارد کنند:
«تکمیل خودکار جا» سرعت وارد کردن نشانی را افزایش می‌دهد و خطاهای ورودی را کاهش می‌دهد، و به مشتریان اجازه می‌دهد به‌راحتی در فرایند تصفیه‌حساب پیش بروند. «اعتبارسنجی نشانی» درباره کیفیت کلی نشانی بازخورد ارائه می‌دهد، اصلاحاتی مثل استانداردسازی و غلط‌های املایی انجام می‌دهد، و فراداده‌ها را بهبود می‌دهد، مثلاً نشانگر مسکونی یا تجاری ارائه می‌دهد (در مناطق منتخب دردسترس است).

نمای کلی پیاده‌سازی

این بخش گردش کار توصیه شده برای وارد کردن نشانی در تسویه‌حساب‌های تجارت الکترونیک را شرح می‌دهد. این فرایند از سه مرحله تشکیل شده است:

  1. از «تکمیل خودکار جا» برای ضبط اولیه نشانی استفاده کنید.
  2. از Address Validation API برای تأیید نشانی واردشده استفاده کنید.
  3. مکان نشانی واردشده را روی نقشه نمایش دهید تا مشتریان از ارسال مطمئن شوند.

سپس، هر مرحله را به‌طور جداگانه بررسی خواهیم کرد.

مرحله ۱: جریان ورود نشانی - بااستفاده از سرویس «تکمیل خودکار مکان»

تکمیل خودکار جا را بااستفاده از JavaScript API در خط اول فرم ورودی نشانی پیاده‌سازی کنید.

«تکمیل خودکار جا» هنگام وارد کردن جزئیات نشانی، به مشتری پیشنهاد می‌دهد. وقتی بااستفاده از JavaScript API پیاده‌سازی می‌شود، وقتی کاربران شروع به تایپ می‌کنند، منو کرکره‌ای در زیر فیلد فرم ورودی نشانی ظاهر می‌شود و نتایج را از سرویس «تکمیل خودکار» نشان می‌دهد که با هر کلیدزنی به‌روز می‌شود. وقتی کاربر اطلاعات کافی برای پیدا کردن نشانی را وارد کرد، آن را از منو کرکره‌ای انتخاب می‌کند. این کنش به‌طور خودکار فیلدهای فرم را با داده‌های نشانی پر می‌کند.

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

در اینجا نمونه‌ای از نحوه نمایش این جریان بااستفاده از یک فیلد ورودی آورده شده است:

تصویر

مرحله ۲: استفاده از Address Validation API برای اعتبارسنجی نشانی‌ها

پس‌از اینکه کاربر نشانی را وارد کرد، Google توصیه می‌کند که Address Validation API را در تسویه‌حساب فراخوانی کنید تا تأیید شود که نشانی معتبر و کامل است. وقتی کاربر روی دکمه «بعدی» یا «ادامه» در فرم نشانی کلیک می‌کند، فراخوانی Address Validation API را راه‌اندازی کنید. این دکمه معمولاً به صفحه پرداخت منتهی می‌شود.

Google توصیه می‌کند برای هر تراکنش Address Validation API را فراخوانی کنید.

نمودار جریان زیر نمونه‌ای از ادغام سرتاسر Address Validation API را در فرایند تسویه‌حساب نشان می‌دهد:

تصویر

این سند بعداً سناریوهای پذیرش نشانی را مورد بحث قرار می‌دهد.

مرحله ۳: ارائه تأیید تصویری

پس‌از وارد کردن نشانی، با نمایش دادن مکان در نقشه، تأیید تصویری مکان تحویل را به کاربر ارائه دهید. این کار به مشتری اطمینان بیشتری می‌دهد که نشانی درست است و موارد عدم موفقیت در ارسال یا تحویل را کاهش می‌دهد.

نقشه می‌تواند درطول فرایند تسویه‌حساب نشان داده شود یا در ایمیل تأیید تراکنش ارسال شود. هر دو مورد استفاده را می‌توان با میاناهای برنامه‌سازی کاربردی زیر انجام داد.

Maps JavaScript API نقشه تعاملی‌ای برای نمایش مکان کاربر ارائه می‌دهد. Maps Static API امکان جاسازی تصویر در صفحه وب یا در مرحله بعدی در ایمیل را فراهم می‌کند.

ژرف‌کاوی - سناریوهای پذیرش نشانی

پاسخ‌های Address Validation API را می‌توان در سه سناریو اصلی دسته‌بندی کرد:

  • اصلاح کنید—نشانی کیفیت پایینی دارد. باید اطلاعات بیشتری درخواست کنید.
  • تأیید—نشانی کیفیت بالایی دارد، اما تغییراتی نسبت‌به نشانی ورودی دارد. ممکن است از شما خواسته شود تأیید کنید.
  • پذیرفتن—نشانی کیفیت بالایی دارد. می‌توانید نشانی ارائه‌شده را بپذیرید.

این مفهوم در بخش ساختن منطق اعتبارسنجی در اسناد Address Validation API پوشش داده شده است و ما هر سناریو را در این بخش مورد بحث قرار خواهیم داد.

رفع اشکال

تصویر

این بخش نحوه اصلاح ورودی نشانی را نشان می‌دهد. برای کسب اطلاعات درباره سیگنال‌های خاصی که Address Validation API برای نشان دادن کیفیت پایین نشانی برمی‌گرداند، به بخش اصلاح نشانی در سند «منطق درستی‌سنجی خود را بسازید» مراجعه کنید.

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

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

تأیید کردن

تصویر

این بخش نحوه تأیید نشانی را نشان می‌دهد. برای کسب اطلاعات درباره سیگنال‌های خاصی که Address Validation API برای نشان دادن اینکه نشانی باید تأیید شود برمی‌گرداند، به تأیید نشانی در سند «منطق درستی‌سنجی خود را بسازید» مراجعه کنید.

اغلب سیستم شما می‌خواهد از کاربر بخواهد نشانی را تأیید کند. برای مثال، مشتری نام شهر را اشتباه تایپ می‌کند، که در این صورت «میانای برنامه‌سازی کاربردی درستی‌سنجی نشانی» آن را اصلاح می‌کند. باید این اصلاح را با مشتری تأیید کنید. دلیل این امر این است که تغییرات ایجادشده توسط API ممکن است آنچه را که در ابتدا وارد شده است به‌طور اساسی تغییر دهد.

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

  1. نشانی را همان‌طور که توسط API برگردانده شده است تأیید کنید و فرایند تسویه‌حساب بااستفاده از نشانی اصلاح‌شده ادامه می‌یابد.
  2. نشانی را همان‌طور که در ابتدا وارد شده است انتخاب کنید و اصلاحیه Address Validation API را نادیده بگیرید. فرایند تسویه‌حساب می‌تواند طبق روال معمول ادامه یابد و سفارش می‌تواند برای بازبینی پایین‌دست قبل‌از ارسال پرچم‌گذاری شود، اگر فرایند شما اجازه دهد.
  3. مشتری از پنجره لغو می‌کند یا خارج می‌شود و به مرحله ورود نشانی در فرایند تسویه‌حساب برمی‌گردد، جایی که می‌تواند نشانی را از ابتدا دوباره وارد کند و فرایند را از نو شروع کند.

نمونه‌ای از این مورد را می‌توانید در نماگرفت سمت چپ ببینید.

پذیرفتن

این بخش نحوه پذیرفتن نشانی را نشان می‌دهد. برای کسب اطلاعات درباره سیگنال‌های خاصی که Address Validation API برای نشان دادن کیفیت خوب نشانی و پذیرفتن آن برمی‌گرداند، به پذیرفتن نشانی در سند «منطق درستی‌سنجی خود را بسازید» مراجعه کنید.

در این سناریو، فرایند تسویه‌حساب باید به مرحله بعدی، احتمالاً دریافت پرداخت، برود و هیچ پیام‌واره‌ای به مشتری درباره کیفیت نشانی نشان ندهد. ‫API تأیید کرده است که نشانی واردشده توسط مشتری کیفیت خوبی دارد و قابل‌تحویل است.

توصیه می‌کنیم از داده‌های نشانی برگردانده‌شده از Address Validation API برای سفارش استفاده کنید، زیرا ممکن است حاوی اصلاحات و اضافات جزئی باشد، مانند موارد زیر:

  • بزرگ‌نویسی
  • اصلاحات قالب‌بندی، برای مثال
    • Street به St
    • ترتیب صحیح اجزای نشانی
  • کد پستی+۴ در ایالات متحده.

ملاحظات پیاده‌سازی

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

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

دو روش پیشنهادی برای پذیرفتن تلاش دوم:

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

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

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

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

نتیجه‌گیری

این سند نمای کلی‌ای از روند تسویه‌حساب با پیاده‌سازی «تکمیل خودکار»، «اعتبارسنجی نشانی»، و تأیید دیداری در Google Map ارائه کرده است. از این سند به‌عنوان نقطه شروعی برای طراحی پیاده‌سازی‌تان استفاده کنید و جریان‌های ورودی نشانی توصیه‌شده را دنبال کنید.

مراحل بعدی

مطالعه بیشتر پیشنهادی:

همیاران

Henrik Valve | مهندس راه‌حل‌ها
Thomas Anglaret | مهندس راه‌حل‌ها
Sarthak Ganguly | مهندس راه‌حل‌ها

  1. دارنده پروانه غیرانحصاری «خدمات پستی ایالات متحده». علامت(های) تجاری زیر متعلق به United States Postal Service®‎ است و با اجازه استفاده می‌شود: CASS™‎،‏ USPS®‎،‏ DPV®‎. ↩