שמירת כרטיס אשראי בחנות אינטרנטית: מה זה Token, כספת, J4 ו-J5?

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

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

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

כאן נכנסים לתמונה כמה מושגים חשובים בעולם הסליקה: Token, כספת אשראי, J4 ו-J5.

למרות שהם קשורים זה לזה, הם אינם אותו דבר.

מה זה Token?

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

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

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

לדוגמה:

לקוח מספר 1254

Token: ABC123XYZ

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

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

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

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

טוקן הוא לא מספר כרטיס אשראי מוצפן

חשוב להבדיל בין הצפנה לבין Tokenization.

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

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

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

מהי כספת אשראי?

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

אפשר להמחיש זאת בצורה פשוטה.

במערכת החנות נשמר:

לקוח 1254 ← Token ABC123XYZ

ובמערכת המאובטחת של ספק שירותי התשלום קיים הקשר בין:

Token ABC123XYZ ← אמצעי התשלום של הלקוח

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

לפתרון כזה יש חשיבות גדולה מבחינת אבטחת מידע ועמידה בדרישות PCI DSS.

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

למה בכלל לשמור Token?

יש כמה תרחישים נפוצים שבהם שמירת Token יכולה להיות שימושית מאוד בחנות אינטרנטית.

אחד מהם הוא מנוי חודשי.

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

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

תרחיש אחר הוא לקוח קבוע.

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

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

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

ומה זה J4?

J4 הוא מונח נפוץ במערכות הסליקה בישראל המתייחס לעסקת חיוב.

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

כלומר:

הזמנה → בקשת J4 → אישור → חיוב

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

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

לכן חשוב להבין:

J4 הוא סוג של פעולת סליקה. Token הוא אמצעי לזיהוי אמצעי התשלום.

אלה שני דברים שונים.

ומה זה J5?

J5 נועד לתרחיש שונה.

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

לאחר מכן ניתן להשלים את העסקה.

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

הדוגמה הקלאסית: המחיר נקבע לאחר הליקוט

ניקח לדוגמה סופרמרקט או חנות אינטרנטית למוצרי מזון.

הלקוח מזמין:

• 1 ק"ג עגבניות
• 1.5 ק"ג תפוחים
• 800 גרם בשר
• 2 ק"ג תפוחי אדמה

אבל המחיר הסופי תלוי במשקל שנלקט בפועל.

הלקוח אולי ביקש קילוגרם עגבניות, אבל בפועל נשקלו 1.08 ק"ג.

בזמן ביצוע ההזמנה המערכת מחשבת שהסכום המשוער הוא 520 ₪.

אבל לאחר הליקוט מתברר שהסכום האמיתי הוא 487 ₪.

אם החנות חייבה מראש 520 ₪, עכשיו צריך לטפל בהפרש.

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

לדוגמה:

הלקוח מבצע הזמנה בסכום משוער של 520 ₪.

מתבצעת בקשת J5.

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

המחסן מתחיל בליקוט.

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

מחיר ההזמנה מחושב מחדש.

הסכום הסופי הוא 487 ₪.

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

למה לא פשוט להשתמש תמיד ב-Token?

מכיוון ש-Token ו-J5 פותרים בעיות שונות.

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

J5 מאפשר לקבל אישור ולתפוס מסגרת לפני השלמת העסקה.

נניח שלקוח ביצע הזמנה בסך משוער של 1,000 ₪.

אפשר לשמור Token ולנסות לחייב אותו מאוחר יותר ב-1,000 ₪.

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

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

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

Token לחיובים חודשיים

שימוש נפוץ נוסף הוא מנויים והוראות קבע באשראי.

לדוגמה:

לקוח רוכש שירות בעלות של 250 ₪ לחודש.

במעמד ההצטרפות הוא מזין את פרטי הכרטיס פעם אחת.

המערכת מקבלת Token ושומרת אותו בכרטיס הלקוח.

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

כך ניתן לבנות שירותים כמו:

• מנויים חודשיים, דמי שימוש קבועים, שירותים בתשלום תקופתי, מועדוני לקוחות ושירותי SaaS.

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

מסירת כרטיס פעם אחת וחיוב לפי שימוש

יש תרחיש נוסף שבו Token שימושי במיוחד.

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

בחודש אחד הלקוח צריך לשלם 300 ₪, בחודש הבא 750 ₪ ובחודש שלאחר מכן 180 ₪.

אין כאן בהכרח "מנוי של 300 ₪ לחודש".

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

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

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

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

לא חייבים לבחור בין J5 לבין Token

אחת הטעויות הנפוצות היא לחשוב שצריך לבחור:

או J5 או Token.

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

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

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

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

צריך להגדיר בדיוק מה העסק רוצה לעשות.

השאלות שצריך לשאול באפיון

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

האם הסכום הסופי ידוע בזמן ההזמנה?

אם לא, מתי הוא נקבע?

האם צריך לתפוס מסגרת בזמן ביצוע ההזמנה?

כמה זמן עובר בין ההזמנה לבין החיוב?

האם מדובר בחיוב חד פעמי, חיוב מחזורי או חיובים משתנים?

האם הלקוח אמור להשתמש באותו כרטיס גם ברכישות הבאות?

האם הלקוח יכול להחליף או למחוק את אמצעי התשלום השמור?

מה קורה כאשר הכרטיס נדחה?

מה קורה כאשר הכרטיס פג תוקף?

מה קורה כאשר הליקוט מגדיל את מחיר ההזמנה ולא מקטין אותו?

מי רשאי להפעיל חיוב באמצעות Token?

האם החיוב מופעל אוטומטית על ידי המערכת או ידנית על ידי עובד?

ומה קורה במקרה של ביטול, זיכוי או חיוב חלקי?

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

חשוב להבדיל בין ארבעת המושגים

אפשר לסכם את ההבדלים בצורה פשוטה:

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

לסיכום

שמירת Token אינה רק פונקציה טכנית של מערכת הסליקה.

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

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

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

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

ובכל אחד מהתרחישים האלה חשוב להפריד בין השאלות:

האם אנחנו רוצים לחייב עכשיו?

האם אנחנו רוצים רק לקבל אישור ולתפוס מסגרת?

האם אנחנו רוצים לשמור אמצעי תשלום לשימוש עתידי?

התשובות לשאלות האלה הן שקובעות אם התהליך צריך לכלול J4, J5, Token, כספת או שילוב ביניהם.

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