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

מטרה

במאמר הזה מוסבר איך לשלב בין Place Autocomplete, ‏ Address Validation API1 ומפות בתהליך התשלום באתר מסחר אלקטרוני, כדי לאסוף כתובות באיכות גבוהה.

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

מומלץ להכיר את הנושאים הבאים:

  • מסמכי מפתחים בנושא JavaScript של השלמה אוטומטית למקומות
    • הסבר טכני על אופן הפעולה של ההשלמה האוטומטית של מקומות ואפשרויות ההטמעה שלה.
  • מדריך להטמעת השלמה אוטומטית של מקומות בדף התשלום
    • דוגמאות לשיטות מומלצות להטמעה של השלמה אוטומטית של מקומות בדף תשלום של אתר מסחר אלקטרוני.
  • ‫Address Validation API product documentation, עם דגש על Build your validation logic.
    • הסבר טכני על אופן הפעולה של Address Validation API, וסקירה של האותות שקובעים את איכות הכתובת.

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

‫Address Validation API הוא שירות שמקבל כתובת. הוא מזהה רכיבי כתובת ומאמת אותם. הוא גם מתקנן את הכתובת למשלוח דואר ומוצא את הקואורדינטות הכי מדויקות שלה. לחלופין, לכתובות בארצות הברית ובפוארטו ריקו, אפשר להפעיל את מערכת התמיכה בדיוק הקידוד (CASS™).

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

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

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

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

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

  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 לשלושה תרחישים עיקריים:

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

המושג הזה מוסבר בקטע Build your validation logic במסמכי התיעוד של Address Validation API. נדון בכל תרחיש בקטע הזה.

תיקון

תמונה

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

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

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

אישור

תמונה

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

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

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

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

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

אישור

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

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

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

  • שימוש באותיות רישיות
  • תיקוני עיצוב, לדוגמה:
    • Street to St
    • סדר נכון של רכיבי הכתובת
  • מיקוד ZIP+4 בארה"ב.

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

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

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

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

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

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

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

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

סיכום

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

השלבים הבאים

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

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

תורמים

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

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