منطق اعتبارسنجی خود را بسازید

این سند فرآیندی را برای ساختن یک سیستم بررسی آدرس برای رسیدگی به انواع پاسخ‌ها از Address Validation API توضیح می‌دهد. نحوه تفسیر پاسخ API به منظور تعیین زمان و چگونگی درخواست اطلاعات بیشتر از مشتریان را پوشش می دهد.

به طور کلی پاسخ API راه های زیر را تعیین می کند که سیستم شما باید یک آدرس را مدیریت کند:

• رفع - آدرس ممکن است حاوی مشکلات مهمی باشد.
  در نظر بگیرید که مشتری خود را برای اطلاعات بیشتر ترغیب کنید.
• افزودن زیرمجموعه ها — ممکن است آدرس یک زیرمجموعه از دست داده باشد.
  در نظر بگیرید که از مشتری خود بخواهید یک شماره واحد اضافه کند.
• تأیید - آدرس ممکن است حاوی مشکلات جزئی باشد.
  از مشتری خود بخواهید تا درستی آدرس را تأیید کند.
• Accept را — آدرس ممکن است حاوی مشکل نباشد.
  استفاده از آدرس را بدون درخواست بیشتر، با مسئولیت خود در نظر بگیرید.

هدف کلیدی

این سند به شما کمک می کند تا سیستم خود را تغییر دهید تا پاسخ API را به بهترین شکل تجزیه و تحلیل کنید و اقدامات بعدی را با آدرس های ارائه شده تعیین کنید. شبه کد زیر یک جریان احتمالی را نشان می دهد.

if (verdict.possibleNextAction == FIX)
    Prompt the user to fix the address.
else if (verdict.possibleNextAction == CONFIRM_ADD_SUBPREMISES)
    Prompt the user to add a unit number.
else if (verdict.possibleNextAction == CONFIRM)
    Confirm with the user that the address is correct.
else
    Continue with the address returned by the API.

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

گردش های کاری احتمالی

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

رفتار سیستم شما
آدرس رو درست کن	پاسخ از verdict نشان می دهد که ممکن است مشکلات مهمی در مورد آدرس وجود داشته باشد. برای مثال، verdict.possibleNextAction FIX است. در نظر بگیرید که مشتری خود را برای اطلاعات بیشتر ترغیب کنید. گردش کار در صورت لزوم اجزای آدرس را بررسی کنید. از مشتری بخواهید تا مشکلات را برطرف کند. درخواست تأیید اعتبار برای آدرس به روز شده. (اختیاری) درخواستی را به نقطه پایانی بازخورد برای API ارسال کنید. به آدرس های به روز شده رسیدگی کنید . با آدرس ادامه دهید
افزودن زیرمجموعه ها	پاسخ verdict نشان می‌دهد که آدرس ممکن است یک پیش فرض فرعی نداشته باشد. برای مثال، verdict.possibleNextAction CONFIRM_ADD_SUBPREMISES است. در نظر بگیرید که از مشتری خود بخواهید یک شماره واحد اضافه کند. گردش کار از مشتری بخواهید یک شماره واحد اضافه کند. درخواست تأیید اعتبار برای آدرس به روز شده. (اختیاری) درخواستی را به نقطه پایانی بازخورد برای API ارسال کنید. به آدرس های به روز شده رسیدگی کنید . با آدرس ادامه دهید
آدرس را تایید کنید	پاسخ از verdict نشان می دهد که ممکن است مشکلات جزئی با آدرس وجود داشته باشد. برای مثال، verdict.possibleNextAction CONFIRM است. در نظر بگیرید که از مشتری خود بخواهید آدرس را بررسی کند. گردش کار اصلاحات مورد نیاز: در صورت لزوم اجزای آدرس را بررسی کنید. درخواست تأیید اعتبار برای آدرس به روز شده. (اختیاری) درخواستی را به نقطه پایانی بازخورد برای API ارسال کنید. به آدرس های به روز شده رسیدگی کنید . با آدرس ادامه دهید بدون نیاز به اصلاح: (اختیاری) درخواستی را به نقطه پایانی بازخورد برای API ارسال کنید. به آدرس های به روز شده رسیدگی کنید . با آدرس ادامه دهید
Accept the address	پاسخ از verdict نشان می دهد که ممکن است مشکلی با آدرس وجود نداشته باشد. برای مثال، verdict.possibleNextAction ACCEPT است. همانطور که برای سطح ریسک خود انجام می دهید، آدرس را ادامه دهید. گردش کار با آدرس برگشتی ادامه دهید.

توجه: وقتی درخواست‌هایی را برای Address Validation API برای همان آدرس تکرار می‌کنید، می‌توانید با provideValidationFeedback تماس بگیرید تا نتیجه خود را نشان دهید. به آدرس های به روز شده رسیدگی کنید .

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

منطق اعتبارسنجی خود را سفارشی کنید

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

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

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

تحمل ریسک

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

	راهنمایی	جزئیات
سطح ریسک	هنگام ایجاد تعادل بین درخواست اصلاحات و پذیرش آدرس درج شده، سطح تحمل را برای موقعیت خود در نظر بگیرید.	Address Validation API سیگنال‌های مختلفی را برمی‌گرداند که می‌توانید با سطح ریسک خود برای بهینه‌سازی فرآیند اعتبارسنجی خود ترکیب کنید. به عنوان مثال، اگر آدرسی دارای شماره خیابان تایید نشده باشد، همچنان می توانید آن را بپذیرید. از سوی دیگر، اگر عملیات تجاری شما به دقت آدرس بیشتری نیاز دارد، ممکن است از کاربر خود درخواست کنید. برای مثالی که می‌تواند در هر یک از دسته‌ها قرار گیرد، شماره خیابان تأیید نشده غیرآمریکایی را در آدرس پذیرش - نمونه‌ها ببینید.
آدرس ها را بپذیرید	اگر مشتری به درخواست‌ها پاسخ ندهد، این روش خوبی است که به سیستم خود اجازه دهید ورودی اصلی را بپذیرد.	در این موارد، مشتری ممکن است آدرسی را وارد کرده باشد که در سیستم نیست، مثلاً برای ساخت و ساز جدید.

مثال جریان پرداخت ریسک گریز

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

if (verdict.possibleNextAction == FIX or verdict.validationGranularity
== OTHER or verdict.validationGranularity == ROUTE)
  Prompt customer to fix their address.
else if (verdict.possibleNextAction == CONFIRM_ADD_SUBPREMISES)
  Prompt customer to add a unit number.
else if (verdict.possibleNextAction == CONFIRM or verdict.validationGranularity
== PREMISE_PROXIMITY or verdict.hasSpellCorrectedComponents or
verdict.hasReplacedComponents or verdict.hasInferredComponents)
  Prompt customer to confirm their address.
else
  Proceed with the returned address.

مثال جریان پرداخت با اصطکاک کم

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

if (verdict.possibleNextAction == FIX)
  Prompt customer to fix their address.
else if (verdict.hasReplacedComponents)
  Prompt customer to confirm their address.
else
  Proceed with the returned address.

رفع سیگنال ها

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

فیلدهای زیر پاسخ Address Validation API را می‌توان علاوه بر verdict.possibleNextAction برای تعیین اینکه آیا یک آدرس دارای مشکلات عمده است یا خیر، استفاده کرد.

دانه بندی اعتبار سنجی	هنگامی که شماره جزئیات اعتبارسنجی برای یک آدرس OTHER باشد، احتمالاً آدرس نادرست است.
اجزای گم شده	وقتی address.missingComponentTypes missingComponentTypes خالی نیست، احتمالاً آدرس اطلاعات کلیدی را از دست داده است.
اجزای مشکوک	وقتی شماره سطح تأیید برای یک مؤلفه UNCONFIRMED_AND_SUSPICIOUS باشد، احتمالاً مؤلفه نادرست است.
اجزای حل نشده	UnresolvedToken بخشی از ورودی است که به عنوان بخشی معتبر از یک آدرس شناخته نمی شود.
تایید DPV USPS	وقتی uspsData.dpvConfirmation یا N است یا خالی است، ممکن است مشکلی در آدرس وجود داشته باشد. این فیلد فقط برای آدرس های ایالات متحده موجود است. برای جزئیات بیشتر در مورد uspsData.dpvConfirmation ، به آدرس های ایالات متحده رسیدگی کنید.

رفع نمونه آدرس

سیگنال های CONFIRM_ADD_SUBPREMISES (فقط آدرس های ایالات متحده)

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

فیلدهای زیر از پاسخ Address Validation API را می‌توان علاوه بر verdict.possibleNextAction برای تعیین اینکه آیا آدرسی احتمالاً یک زیرمجموعه را از دست داده است استفاده کرد.

Missing subpremise component	وقتی فیلد address.missingComponentTypes حاوی مقداری از subpremise باشد، این نشان می‌دهد که یک شماره واحد از آدرس گم شده است. توجه : اگر فیلد دارای انواعی غیر از subpremise باشد، عمل در دسته FIX قرار می گیرد. لیست کامل انواع مؤلفه ها را در مستندات Geocoding مشاهده کنید.
تایید DPV USPS	وقتی uspsData.dpvConfirmation S باشد، به این معنی است که شماره اولیه آدرس با آدرسی در پایگاه داده USPS مطابقت داده شده است. با این حال، انتظار می رفت که آدرس حاوی یک شماره ثانویه نیز باشد. این فیلد فقط برای آدرس های ایالات متحده موجود است. برای جزئیات بیشتر در مورد uspsData.dpvConfirmation ، به آدرس های ایالات متحده رسیدگی کنید.

نمونه های آدرس فرعی را اضافه کنید

سیگنال ها را تأیید کنید

زمانی که حکم نشان می‌دهد که Address Validation API استنباط کرده یا تغییراتی در اجزای آدرس به منظور تولید یک آدرس معتبر ایجاد کرده است، یک آدرس را تأیید می‌کنید. در این موارد، شما یک آدرس قابل تحویل دارید، اما ترجیح می‌دهید اطمینان بیشتری داشته باشید که نشانی به‌دست‌آمده همان آدرسی است که مشتری در نظر گرفته است.

فیلدهای زیر از پاسخ Address Validation API را می‌توان علاوه بر verdict.possibleNextAction برای تعیین اینکه آیا یک آدرس دارای مشکلات جزئی است یا خیر، استفاده کرد.

دانه بندی اعتبار سنجی	وقتی validationGranularity برای یک آدرس ROUTE یا PREMISE_PROXIMITY باشد، ممکن است آدرس نادرست باشد.
داده های استنباط شده	وقتی فیلد hasInferredComponents true باشد، می‌دانید که API اطلاعاتی را که از سایر اجزای آدرس جمع‌آوری کرده بود، پر کرده است.
داده ها جایگزین شد	وقتی فیلد hasReplacedComponents true باشد، API داده‌های وارد شده را با داده‌هایی که به نظر می‌رسد آدرس را معتبر می‌کند جایگزین می‌کند.
اصلاحات املایی	وقتی فیلد hasSpellCorrectedComponents true باشد، API املای برخی مؤلفه‌های غلط املایی را تصحیح کرد.

نمونه های آدرس را تأیید کنید

سیگنال ها را قبول کنید

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

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

فیلدهای زیر از پاسخ Address Validation API را می توان علاوه بر verdict.possibleNextAction برای تعیین اینکه آیا یک آدرس از کیفیت قابل قبولی برخوردار است استفاده کرد.

دانه بندی اعتبار سنجی	validationGranularity PREMISE اغلب قابل قبول است، اگرچه مقدار ROUTE ممکن است هنوز نشانی قابل تحویل را نشان دهد.
داده های استنباط شده ای وجود ندارد	وقتی فیلد hasInferredComponents false است، می دانید که هیچ مؤلفه ای در خروجی استنباط نشده است.
داده ای جایگزین نشده است	وقتی فیلد hasReplacedComponents false است، می دانید که هیچ داده ورودی جایگزین نشده است.
بدون اصلاح املایی	هنگامی که فیلد hasSpellCorrectedComponents false است، می دانید که هیچ تصحیح املایی انجام نشده است.
تایید DPV USPS	وقتی uspsData.dpvConfirmation Y است، به این معنی است که آدرس با آدرسی در پایگاه داده USPS مطابقت داده شده است. این فیلد فقط برای آدرس های ایالات متحده موجود است. برای جزئیات بیشتر در مورد uspsData.dpvConfirmation ، به آدرس های ایالات متحده رسیدگی کنید.

نمونه های آدرس را بپذیرید