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

מטרה

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

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

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

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

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

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

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

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

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

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

  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 ממליצה לבצע קריאה ל-Address Validation API בכל עסקה.

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

תמונה

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

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

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

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

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

פירוט – תרחישים של אישור כתובות

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

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

המושג הזה מוסבר בקטע יצירת לוגיקה לאימות במסמכי התיעוד של 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 בהזמנה, כי הם עשויים לכלול תיקונים ותוספות קלות, כמו:

  • שימוש באותיות רישיות
  • תיקוני עיצוב, לדוגמה:
    • רחוב ל-St
    • סדר נכון של רכיבי הכתובת
  • מיקוד 4 ספרות בארה"ב.

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

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

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

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

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

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

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

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

סיכום

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

השלבים הבאים

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

מקורות מידע נוספים:

תורמים

Henrik Valve | מהנדס פתרונות
Thomas Anglaret | מהנדס פתרונות
Sarthak Ganguly | מהנדס פתרונות

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