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

יעד

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

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

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

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

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

ה-API לאימות כתובת הוא שירות שמקבל כתובות. היא מזהה את רכיבי הכתובת ומאמתת אותם. הוא גם יוצר סטנדרטיזציה של הכתובת למשלוח דואר ומוצא את הקואורדינטות של קו הרוחב/קו האורך הידועות ביותר. (אופציונלי) לכתובות בארצות הברית ופוארטו ריקו, אפשר להפעיל את Coding Technical Support System (CASSTM).

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

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

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

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

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

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

לאחר מכן נתעמק בכל שלב בנפרד.

שלב 1: תהליך הזנת הכתובת - באמצעות שירות ההשלמה האוטומטית של המקום

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

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

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

הדוגמה הבאה ממחישה איך התהליך הזה עשוי להופיע באמצעות שדה להזנת קלט אחד:

שלב 2: משתמשים ב-API לאימות כתובות כדי לאמת כתובות

אחרי שהמשתמש יזין את הכתובת, Google ממליצה להפעיל בקופה את Address Validation API כדי לוודא שהכתובת חוקית ומלאה. להפעיל קריאה ל-Address Validation API כשהמשתמש לוחץ על הלחצן Next או על Continue (המשך) בטופס הכתובת. הלחצן הזה מוביל בדרך כלל לדף התשלום.

Google ממליצה להפעיל את ה-API לאימות כתובת בכל עסקה.

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

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

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

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

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

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

ניתוח מעמיק – תרחישים של אישור בקשות

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

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

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

תיקון

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

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

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

---

אישור

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

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

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

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

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

---

אישור

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

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

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

• שימוש באותיות רישיות
• תיקונים בפורמט, לדוגמה
  • מרחוב לרחוב
  • סדר נכון של רכיבי הכתובת
• ZIP+4 בארה"ב.

---

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

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

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

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

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

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

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

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

סיכום

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

השלבים הבאים

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

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

• תיעוד בנושא השלמה אוטומטית במקום
• מסמכי תיעוד של ה-API לאימות כתובת
• דיווח בפלטפורמה של מפות Google

תורמים

Henrik Valve | מהנדס פתרונות
תומאס אנגלארט | מהנדס פתרונות
סרתאק גאנגולי | מהנדס פתרונות