אימות כתובת לביצוע תשלום במסחר אלקטרוני

יעד

במסמך הזה מתוארות שיטות לשילוב של השלמה אוטומטית של מקומות, Address API1 ומפות Google בקופה של מסחר אלקטרוני, כדי לתעד כתובות באיכות גבוהה.

דרישות מוקדמות

Google ממליצה להכיר את הדברים הבאים:

  • Place השלמה אוטומטית של JavaScript תיעוד למפתחים.
    • להבין מנקודת מבט טכנית איך פועלת התכונה 'השלמה אוטומטית של מקומות' ומהן אפשרויות ההטמעה שלה.
  • המדריך להטמעה של דף התשלום להשלמה אוטומטית של מקומות.
    • דוגמאות לשיטות מומלצות להטמעה של השלמה אוטומטית של מקומות בקופה במסחר אלקטרוני.
  • מסמכי תיעוד של המוצרים ב-Address Validation API תוכלו להתמקד בבניית לוגיקת אימות.
    • עליך להבין מנקודת מבט טכנית כיצד פועל ה-Address Validation API, ולבדוק את האותות שקובעים את איכות הכתובת.

מהו אימות כתובת?

ה-Address Validation API הוא שירות שמקבל כתובת. הוא מזהה את רכיבי הכתובת ומאמת אותם. הוא גם מבצע סטנדרטיזציה של הכתובת למשלוח דואר ומוצא את הקואורדינטות המוכרות ביותר של קווי אורך ורוחב. אפשר גם להפעיל את מערכת התמיכה לדיוק קידוד (CASSTM) בכתובות בארצות הברית ובפוארטו ריקו.

למה צריך לאמת את הכתובת בקופה?

איסוף כתובות מדויקות בתהליך ההזמנה:
זהו שלב חשוב בקידום משלוחים מוצלחים, מגדיל את העמידה בזמן ההזמנות ומפחית את החיובים היקרים על תיקון כתובות.

הסבירו ללקוחות איך להזין את הכתובת במהירות ובאופן מדויק:
ההשלמה האוטומטית של Google מזרזת את תהליך הזנת הכתובת ומפחיתה את השגיאות בקלט, ומאפשרת ללקוחות לעבור בקלות בקופה. אימות הכתובת מספק משוב על האיכות הכוללת של הכתובת, מבצע תיקונים כמו תקן ושגיאות איות ומשפר את המטא-נתונים – למשל באמצעות סימון של אזור המגורים או הסימן המסחרי (זמין באזורים נבחרים.

סקירה כללית על ההטמעה

בקטע הזה מפורט תהליך העבודה המומלץ להזנת כתובות לקופה במסחר אלקטרוני. התהליך מורכב משלושה שלבים:

  1. משתמשים בהשלמה אוטומטית של מקום כדי לתעד את הכתובת בפעם הראשונה.
  2. משתמשים ב-Address Validation API כדי לאשר את הכתובת שהוזנה.
  3. הצגת המיקום של הכתובת שהוזנה במפה, כדי לספק ללקוחות תחושת ביטחון לגבי המשלוח.

לאחר מכן נתעמק בכל שלב בנפרד.

שלב 1: תהליך הזנת כתובת - שימוש בשירות השלמה אוטומטית של מקומות

מטמיעים את ההשלמה האוטומטית אוטומטית באמצעות JavaScript API בשורה הראשונה של טופס הזנת הכתובת.

כשמזינים את פרטי הכתובת, מופיעות הצעות להשלמה אוטומטית של מיקומים. כשמשתמשים ב-JavaScript API, כשמתחילים להקליד, מופיע תפריט נפתח מתחת לשדה של טופס הזנת הכתובת ומציג תוצאות משירות ההשלמה האוטומטית שמתעדכן בכל הקשה. אחרי שהמשתמש הזין מספיק מידע כדי למצוא את הכתובת, הוא בוחר אותה מהתפריט הנפתח. הפעולה הזו מאכלסת את נתוני הכתובת באופן אוטומטי בשדות הטופס.

ניתן לך לתת למשתמש שני סגנונות של הזנת טופס באמצעות השלמה אוטומטית של מקומות: תצוגה עם כל שדות הכתובת או תצוגה עם שדה קלט אחד. שדה הקלט היחיד הזה מציג למשתמש בקשה להתחיל לחפש תוך כדי הקלדה, במקום להזין את רכיבי הכתובת בנפרד. אחרי שההשלמה האוטומטית מאכלסת את הכתובת, תהליך העבודה מרחיב את שדות הטופס עם נתוני הכתובת, ומאפשר ללקוח לבדוק ולערוך, לדוגמה, הוספת מספר דירה או יחידה.

הנה דוגמה לאופן שבו תהליך זה עשוי להיראות, באמצעות שדה קלט יחיד:

תמונה

שלב 2: משתמשים ב-Address Validation API כדי לאמת כתובות

אחרי שהמשתמש יזין את הכתובת, Google ממליצה לקרוא ל-Address Validation API בקופה כדי לוודא שהכתובת תקינה ומלאה. להפעיל קריאה ל-Address Validation API כשהמשתמש לוחץ על הלחצן Next או Continue (המשך) בטופס הכתובת. הלחצן הזה מוביל לעיתים קרובות לדף התשלום.

Google ממליצה להפעיל API לאימות כתובות בכל עסקה.

תרשים התהליך הבא מדגים שילוב מקצה לקצה של ה-Address Validation API בשלב תשלום:

תמונה

במסמך הזה מתוארים תרחישים של קבלת כתובות בהמשך.

שלב 3: מספקים אישור חזותי

אחרי שמזינים כתובת, מציגים למשתמשים אישור חזותי של מקום המסירה על-ידי הצגת המיקום במפה. כך הלקוחות יכולים להיות בטוחים שהכתובת נכונה, ולצמצם מקרים של מסירה או איסוף.

המפה תוצג בתהליך התשלום בקופה או תישלח בתוך הודעת האישור באימייל על העסקה. אפשר להשתמש בשני התרחישים לדוגמה באמצעות ממשקי ה-API הבאים.

API ל-JavaScript של מפות Google מספק מפה אינטראקטיבית להצגת מיקום המשתמש. ה-API הסטטי של מפות Google מאפשר להטמיע תמונה בדף האינטרנט או בשלב מאוחר יותר באימייל.

Deep Dive - תרחישים של קבלת כתובת

ניתן לחלק את התגובות מה-API לאימות לשלושה תרחישים עיקריים:

  • תיקון – הכתובת באיכות נמוכה. צריך לשלוח בקשה כדי לקבל מידע נוסף.
  • אישור – הכתובת באיכות גבוהה, אבל יש בה שינויים מהכתובת להזנת הקלט. יכול להיות שתופיע בקשה לאישור.
  • אישור – הכתובת באיכות גבוהה. אפשר לאשר את הכתובת שצוינה.

בנושא הזה מוסבר בחלק יצירת לוגיקת אימות במסמכים של Address Validation API, ונדון בכל תרחיש בחלק זה.

תיקון

תמונה

בקטע הזה מוסבר איך לתקן קלט כתובת. במאמר תיקון כתובת במסמכי התיעוד בנושא לוגיקת אימות, תוכלו לקרוא מידע נוסף על אותות ספציפיים שה-Address Validation API מחזיר על מנת לציין כתובת באיכות נמוכה.

אם התשובה מ-Address Validation API מציינת כתובת לא חוקית, מפנים את הלקוח לטופס להזנת הכתובת כדי לבדוק את הנתונים שהוזנו. אחרי תיקון הכתובת, השירות צריך לשלוח שוב את הכתובת ל-Address verification API כדי לוודא שהתיקונים שבוצעו תקפים.

אפשר גם להדגיש שגיאות ספציפיות בשורת הכתובת באמצעות האותות שהוחזרו ברמת addressComponents. דוגמה לכך מופיעה בצילום המסך שמשמאל.

אישור

תמונה

בקטע הזה מוסבר איך לאמת כתובת. מידע נוסף על אותות ספציפיים שה-Address Validation API מחזיר כדי לציין שצריך לאשר את הכתובת מופיע במאמר אישור כתובת במאמרי העזרה הלוגית של בניית האימות.

לעיתים קרובות המערכת תבקש מהמשתמש לאשר כתובת. לדוגמה, לקוח אוית באופן שגוי את שם העיר, ובעקבות זאת ה-Address Validation API יתקן את שם העיר. צריך לוודא עם הלקוח את התיקון. הסיבה לכך היא שהשינויים שבוצעו על ידי ה-API עשויים לשנות מהיסוד את הנתונים שהוזנו במקור.

חלון מסוג מעברון מאפשר להציג את המידע ללקוח, ומאפשרים שלוש אפשרויות כדי להמשיך:

  1. מאשרים את הכתובת כפי שהוחזרה על ידי ה-API, ותהליך התשלום ימשיך באמצעות הכתובת המתוקנת.
  2. בוחרים את הכתובת כפי שהוזנה במקור, ומתעלמים מהתיקון מ-Address Validation API. תהליך התשלום יכול להמשיך כרגיל, ואפשר לסמן את ההזמנה לבדיקה בהמשך לפני המשלוח, אם התהליך מאפשר זאת.
  3. הלקוח מבטל את בקשת הקישור או חוזר ממנה, ומחזיר אותו לשלב הזנת הכתובת בתהליך התשלום, שבו הוא יכול להזין מחדש את הכתובת מההתחלה.

דוגמה לכך מופיעה בצילום המסך שמימין.

אישור

בקטע הזה מוסבר איך לאשר כתובת. במאמר אישור כתובת במסמכי התיעוד בנושא לוגיקה בנושא אימות, תוכלו לקרוא מידע נוסף על אותות ספציפיים שה-Address Validation API מחזיר כדי לציין שהכתובת היא באיכות טובה וצריך לאשר אותה.

בתרחיש הזה, תהליך התשלום בקופה צריך לעבור לשלב הבא – ככל הנראה קליטת התשלום, בלי להציג ללקוח הנחיות בנוגע לאיכות הטיפול. מממשק ה-API וידאנו שהכתובת שהוזנה על ידי הלקוח היא באיכות טובה, ושאפשר להעביר אותה.

אנחנו ממליצים להשתמש בנתוני הכתובת שהוחזרו מה-Address Validation API מול ההזמנה, כי הם עשויים לכלול תיקונים ותוספות קטנים, כמו:

  • שימוש באותיות רישיות
  • תיקונים בעיצוב, לדוגמה
    • רחוב אל רח'
    • סדר נכון של רכיבי הכתובת
  • ZIP+4 בארה"ב.

למה כדאי להטמיע מעקב אחר אירועים?

כשאתם יוצרים את הלוגיקה לקבלת כתובת, חשוב לוודא שההטמעה לא מונעת מלקוחות את האפשרות לשלם בגלל הזנת כתובת לא חוקית. כדאי ליצור לוגיקה באופן שמונעת את האפשרות ליצירת לולאה אינסופית, במקרה שה-API מציין שוב ושוב שהרשומה לא חוקית.

Google ממליצה לתת ללקוחות עד שתי הזדמנויות להזין את הכתובת, ובניסיון השני לאשר את הבקשה גם אם היא לא מאומתת. בניסיון השני, המטרה היא לאפשר להם להמשיך ללא קשר לאימות.

יש שתי שיטות מומלצות לאישור הניסיון השני:

  • ממשיכים: מציגים ללקוח חלון עם הסבר על הכתובת שלא מאמת, אבל מאפשרים את האפשרות להמשיך עם הכתובת שהוקלדה.
  • Silent Accept: אישור אוטומטי של הניסיון השני בלי שלב אישור, גם אם הכתובת לא אומתה במלואה.

אם אפשר, כדאי לתכנן את המערכת כך שתסמן כתובות שלא מאומתות, כדי שנציג שירות לקוחות יוכל לבדוק אותן לפני שההזמנה תישלח. האמצעי הנוסף הזה מבטיח שתזהו טעויות.

בניית בניינים חדשים מאפשרת להבין למה כדאי לבדוק את זה. יכול להיות שיהיה פער בין סיום הבנייה של הבניין החדש לבין המועד שבו הכתובת של הבניין מאוכלסת במאגרי הנתונים של כתובות הדואר. צריכה להיות ללקוחות אפשרות לאלץ את המעבר בדף התשלום עם הכתובת המוקלדת שלהם, גם אם הכתובת לא מאומתת.

לאחר השלמת סשן של תשלום, אפשר להשתמש ב-method provideValidationFeedback כדי לשלוח ל-Google משוב לגבי ניסיון אימות כתובת ספציפי.

סיכום

במסמך הזה יש סקירה כללית של תהליך התשלום שמטמיע השלמה אוטומטית, אימות כתובות ואישור חזותי במפת Google. השתמשו במסמך הזה כנקודת התחלה לתכנון ההטמעה, בהתאם לתהליכי הזנת הכתובת המומלצים.

השלבים הבאים

הורידו את שיפור תהליך התשלום, המסירה והתפעול באמצעות כתובות אמינות מסמך טכני וצפו בוובינר בנושא שיפור התשלום, המסירה והפעולות באמצעות אימות כתובות .

הצעות נוספות לקריאה:

תורמים

Henrik Valve | מהנדס פתרונות
תומאס אנגלרט | מהנדס פתרונות
סרתק גנגולי | מהנדס פתרונות

  1. בעל רישיון לא בלעדי של שירות הדואר בארצות הברית. הסימנים המסחריים הבאים הם בבעלות United Postal Service®(שירות הדואר בארה"ב) והשימוש בהם מותר: CASSTM, USPS®, DPV®. ↩