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

מטרה

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

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

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

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

‫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 כדי לציין שצריך לאשר כתובת מופיע במאמר אישור כתובת במסמכי התיעוד בנושא יצירת לוגיקת אימות.

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

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

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

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

אישור

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

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

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

  • שימוש באותיות רישיות
  • תיקונים של עיצוב, לדוגמה:
    • Street to St
    • סדר נכון של רכיבי הכתובת
  • מיקוד עם 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®‎. ↩