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

מטרה

במסמך הזה מתוארות שיטות לשילוב של השלמה אוטומטית של מקומות, 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 מאפשר להטמיע תמונות בדף האינטרנט או בשלב מאוחר יותר באימייל.

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

התשובות של Address Validation API מחולקות לשלושה תרחישים עיקריים:

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

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

תיקון

תמונה

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

אם התשובה מה-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®. ↩