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

מטרה

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

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

‫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
    • סדר נכון של רכיבי הכתובת
  • 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®‎. ↩