אימות כתובת בתהליך התשלום

מטרה

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

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

‫Google ממליצה להכיר את הנושאים הבאים:

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

מהו Address Validation?

‫Address Validation API הוא שירות שמקבל כתובת. הוא מזהה את רכיבי הכתובת ומאמת אותם. בנוסף, הוא מתקנן את הכתובת למשלוח דואר ומוצא את הקואורדינטות הכי מדויקות של קו הרוחב וקו האורך שלה. בכתובות בארצות הברית ובפוארטו ריקו, אפשר להפעיל את Coding Accuracy Support System (CASS™)‎.

למה צריך Address Validation בקופה?

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

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

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

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

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

בהמשך נתעמק בכל שלב בנפרד.

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

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

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

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

הנה דוגמה לתהליך כזה, עם שדה אחד להזנת קלט:

תמונה

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

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

‫Google ממליצה לבצע קריאה ל-Address Validation API לכל עסקה.

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

תמונה

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

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

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

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

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

מידע מעמיק – תרחישים של קבלת כתובות

אפשר לסווג את התגובות של Address Validation API לשלושה תרחישים עיקריים:

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

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

תיקון

תמונה

בקטע הזה מוסבר איך לפתור את הבעיה של כתובת שהוזנה. במסמך Build your validation logic, בקטע Fix an address, מוסבר על אותות ספציפיים ש-Address Validation API מחזיר כדי לציין כתובת באיכות נמוכה.

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

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

אישור

תמונה

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

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

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

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

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

אישור

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

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

מומלץ להשתמש בנתוני הכתובת שמוחזרים מ-Address Validation API (ה-API לאימות כתובות) כדי לבדוק את ההזמנה, כי יכול להיות שהם יכללו תיקונים ותוספות קלים, כמו:

  • שימוש באותיות רישיות
  • תיקוני עיצוב, למשל
    • Street to St
    • סדר נכון של רכיבי הכתובת
  • מיקוד בן 9 ספרות בארה"ב.

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

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

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

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

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

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

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

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

סיכום

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

השלבים הבאים

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

תורמים

Henrik Valve | Solutions Engineer
Thomas Anglaret | Solutions Engineer
Sarthak Ganguly | Solutions Engineer

  1. בעל רישיון לא בלעדי של שירות הדואר של ארצות הברית. הסימנים המסחריים הבאים הם בבעלות United States Postal Service®‎ ונעשה בהם שימוש באישור: CASS™‎, ‏ USPS®‎, ‏ DPV®‎. ↩