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

יעד

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

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

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

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

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

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

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

השירות 'השלמה אוטומטית של מקומות' ו-Address Validation API מאפשרים למשתמשים להזין את הנתונים הנכונים בתהליך התשלום במהירות ובקלות. הנה כמה תרחישים נפוצים שהופכים את ה-Address Validation API לחלק חיוני בתהליך התשלום:

שגיאות הקלדה

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

הזמנות בטלפון

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

קניית מתנות

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

הלקוח זקוק למטא-נתונים נוספים של הכתובת

לעיתים קרובות, חברת השליחויות או השליחויות צריכה מידע נוסף על מנת להשלים את המשלוח, כמו מבנה מגורים לעומת מבנה מסחרי, או ערך של USPS DPV (ארה"ב בלבד).

הבדלים בגלל חברות משלוחים שונות

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

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

הטמעה של ממשק API לאימות כתובות

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

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

תהליך מקצה לקצה באמצעות ה-Address Validation API במהלך התשלום עשוי להיראות כך:

תמונה

עכשיו נסביר בפירוט כל שלב.

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

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

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

על ידי שילוב ההשלמה האוטומטית בעגלת הקניות המקוונת שלך, תוכל:

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

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

תמונה

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

בשלב התשלום, מומלץ לקרוא ל-Address Validation API שהכתובת תקינה ומלאה.

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

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

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

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

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

Deep Dive - תרחישים של קבלת כתובת

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

תרחיש 1: כתובת תקינה

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

  • הסמן addressComplete הוא true,
  • רמת פירוט האימות ב-PREMISE או ב-SUB_PREMISE, ו-
  • אף אחד מרכיבי הכתובת לא מסומן כ:
    • inferred
    • spellCorrected
    • replaced
    • unexpected

מומלץ להשתמש בנתוני הכתובת המומלצים מה-Address Validation API, כי הם עשויים לכלול תיקונים ותוספות קטנים, כמו:

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

דוגמה לאופן שבו ניתן להשתמש במשוב הזה בתהליך האימות:

בקשה חדשה תגובה 
  "address": {
    "regionCode": "US",
    "locality": "Mountain View",
    "addressLines": ["1600 Amphitheatre Pkwy"]
  }
 
"verdict": {
      "inputGranularity": "PREMISE",
      "validationGranularity": "PREMISE",
      "geocodeGranularity": "PREMISE",
      "addressComplete": true,
      "hasInferredComponents": true
    } …
"addressComponents": [
        {
          "componentName": {
            "text": "1600",
            "languageCode": "en"
          },
          "componentType": "street_number",
          "confirmationLevel": "CONFIRMED"
        },
        {
          "componentName": {
            "text": "Amphitheatre Parkway",
            "languageCode": "en"
          },
          "componentType": "route",
          "confirmationLevel": "CONFIRMED"
        },
        {
          "componentName": {
            "text": "Mountain View",
            "languageCode": "en"
          },
          "componentType": "locality",
          "confirmationLevel": "CONFIRMED"
        }

תרחיש 2: כתובת בספק

ה-Address Validation API עשוי לציין שיש שינויים משמעותיים בכתובת, בדרך כלל על ידי הוספה של inferred, spellCorrected או replaced בשדות הנפרדים, צריך לוודא עם הלקוח את הכתובת שהוחזרה. כדי לעשות את זה אפשר להשתמש בחלון קופץ עם אפשרות לבחור את הכתובת שהוזנה או את ההמלצה שקיבלת מה-API.
  • כש-Address Validation API מוצא התאמה לכתובת (בדומה ל'התאמה של מועמד' לתשובה של השלמה אוטומטית של מקומות), הוא מגיב עם הכתובת המותאמת היחידה הסבירה ביותר ומסמן את הרכיבים שתוקנו (תגובה של Address Validation API: "spellCorrected": true). לדוגמה:
"1600 amphiteatre parkway" תואם ל-"1600 Amphitheatre Parkway, Mountain View, CA 94043-1351, USA"
דוגמה לאופן שבו ניתן להשתמש במשוב הזה בתהליך האימות:
בקשה חדשה תגובה 
  "address": {
    "regionCode": "US",
    "addressLines": ["1600 amphiteatre parkway"]
  }
 
      "verdict": {
      "inputGranularity": "PREMISE",
      "validationGranularity": "PREMISE",
      "geocodeGranularity": "PREMISE",
      "addressComplete": true,
      "hasInferredComponents": true
    } …
      "address": {
      "formattedAddress": "1600 Amphitheatre Parkway, Mountain View, CA 94043-1351, USA",
      …
      "addressComponents": [
        {
          "componentName": {
            "text": "1600",
            "languageCode": "en"
          },
          "componentType": "street_number",
          "confirmationLevel": "CONFIRMED"
        },
        {
          "componentName": {
            "text": "Amphitheatre Parkway",
            "languageCode": "en"
          },
          "componentType": "route",
          "confirmationLevel": "CONFIRMED",
          "spellCorrected": true
        }
...
{ "componentName": {
            "text": "Mountain View",
            "languageCode": "en"
          },
          "componentType": "locality",
          "confirmationLevel": "CONFIRMED",
          "inferred": true
        }
הערה: ללא "h", שם מיקום חסר (Mountain View)

תרחיש 3: כתובת לא חוקית

אם התשובה מה-Address Validation API מראה כתובת לא חוקית, צריך להפנות את הלקוח לטופס להזנת הכתובת כדי לבדוק את הנתונים שהוזנו. במקרים שבהם ה-Address Validation API לא מצליח למצוא מועמד להתאמה לכתובת מסוימת, הוא בודק את הרכיבים הנפרדים של הכתובת ומסמן נתונים חסרים או לא תקינים. כך אפשר לסמן שדות שצריך להוסיף או לתקן.
דוגמה לאופן שבו ניתן להשתמש במשוב הזה בתהליך האימות:
בקשה חדשה תגובה 
  "address": {
    "regionCode": "US",
    "addressLines": ["123 fake street new york"]
  }

"verdict": {
      "inputGranularity": "PREMISE",
      "validationGranularity": "ROUTE",
      "geocodeGranularity": "ROUTE",
      "hasUnconfirmedComponents": true,
      "hasInferredComponents": true
    } …
"addressComponents": [...
       {"componentName": {
            "text": "123",
            "languageCode": "en"
          },
          "componentType": "street_number",
          "confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE"
        },
        { "componentName": {
            "text": "fake street",
            "languageCode": "en"
          },
          "componentType": "route",
          "confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE"
        },
        {"componentName": {
            "text": "New York",
            "languageCode": "en"
          },
          "componentType": "locality",
          "confirmationLevel": "CONFIRMED"
        } …

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

תמונה

טיפים לשיפור חוויית התשלום

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

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

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

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

אפשר להציג את הכתובות בממשק המשתמש או לשמור אותן במטמון במסד הנתונים, אם הן תואמות ל-Address Validation API Service Specific Services. אם הכתובות נשמרות במטמון במסד נתונים, צריך לוודא את הדברים הבאים:

  • אפשר לשמור כתובות במטמון רק מול משתמש.
  • אפשר לשמור במטמון את הכתובת בפורמט ואת רוב המאפיינים האחרים רק אחרי קבלת הסכמה מהמשתמשים.

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

לדוגמה, אם אתם נמצאים בארה"ב, יש לכם אפשרות להפעיל את CASSTM משירות הדואר בארצות הברית1 בתגובה של Address Validation API, שמספקת רמת פירוט גבוהה על כל כתובת.

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

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

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

סיכום

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

השלבים הבאים

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

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

תורמים

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

  1. בעל רישיון לא בלעדי של שירות הדואר בארצות הברית. הסימנים המסחריים הבאים הם בבעלות United Postal Service®(שירות הדואר בארה"ב) והשימוש בהם מותר: CASSTM, USPS®, DPV®. ↩