תשלומי כרטיסים
תשלומי כרטיסים: מהמסוף אל הסולק וחזרה לספר הראשי
מסופי EMV ושערי תשלום שמחוברים לסולקים דרך ISO 8583 או ממשקי API, עם קבצי התחשבנות שמותאמים ב-ERP.
Blueprint
גללו הצידה כדי לראות את כל השרטוט.
תשלומי כרטיסים: מאושרים בקופה, נסלקים מאוחר יותר, ומותאמים ב-ERP
המסוף או הקופה המקוונת פונה לשער, השער פונה לסולק, והסולק מנתב לרשת הכרטיסים ולמנפיק. קובצי סליקה מגיעים מאוחר יותר ומותאמים למכירות ולעמלות ב-ERP. פסק זמן מפעיל ביטול, כך שהלקוח אף פעם לא מחויב פעמיים.
- זרימה ראשית
- אסינכרונית
- מסלול חריגים
8 שלבים
הזרימה, שלב אחרי שלב
- ממסוף EMV או קופה מקוונת לשער תשלומים: בקשת אישור, דרך EMV · REST/JSON (זרימה ראשית).
- משער תשלומים לסולק: אישור, דרך ISO 8583 (זרימה ראשית).
- מסולק לרשת כרטיסים ומנפיק: נותב למנפיק, דרך ISO 8583 (זרימה ראשית).
- מסולק לשער תשלומים: אושר או נדחה, דרך ISO 8583 (אסינכרונית).
- מסולק לשכבת אינטגרציה: קובצי סליקה ועמלות, דרך SFTP (אסינכרונית).
- משכבת אינטגרציה לERP: מכירות שנסלקו, עמלות ותשלומים ללקוח, דרך REST/JSON (זרימה ראשית).
- משער תשלומים למסוף EMV או קופה מקוונת: אין תגובה בזמן: ביטול אוטומטי, דרך ISO 8583 0400 (מסלול חריגים).
- משכבת אינטגרציה לצוות תפעול התשלומים: אי־התאמת סליקה או חיוב חוזר (מסלול חריגים).
סקירה
זהו המסלול של תשלום בכרטיס, מהמסוף או מקופת האונליין אל הסולק, אל רשת הכרטיסים ואל המנפיק, ובחזרה. הלקוח ממתין לתשובה בקופה. הכסף, בניכוי עמלות, מגיע מאוחר יותר בקובץ התחשבנות שחייב להיות מותאם למכירות ב-ERP שלכם.
תכנון הייחוס שולח אישורים דרך שער תשלום שמבצע טוקניזציה לכרטיס ומנתב את הבקשה לסולק, דרך ISO 8583 או ה-API של הסולק. קבצי התחשבנות ועמלות נאספים על ידי שכבת האינטגרציה, מותאמים למכירות המקוריות ונרשמים ל-ERP כמכירות, עמלות ותשלומים.
התכנון מכסה גם את מה שמשתבש. בקשה שאינה מקבלת תשובה בזמן מוחזרת בהיפוך, כך שהלקוח אינו מחויב פעמיים. התחשבנות שאינה מתאימה, או חיוב חוזר, מגיעים לצוות תפעול התשלומים שלכם עם המכירה המקורית מצורפת.
איך הזרימה עובדת
התחלה במסוף או בקופה
מסוף EMV קורא את השבב או את הכרטיס ללא מגע, או שקופת האונליין אוספת את הכרטיס דרך דף מתארח, ושולח בקשת אישור לשער.
אישור דרך השער
השער מחליף את מספר הכרטיס בטוקן ושולח את האישור לסולק, דרך ISO 8583 או ה-API של הסולק.
ניתוב אל המנפיק
הסולק מנתב את הבקשה דרך רשת הכרטיסים אל המנפיק, שמאשר או דוחה אותה.
החזרת התשובה
האישור או הדחייה חוזרים באותו מסלול אל המסוף או הקופה, עם קוד התגובה שלהם.
קבלת התחשבנות
הסולק שולח מאוחר יותר קבצי התחשבנות ועמלות, ושכבת האינטגרציה אוספת ומאמתת אותם.
התאמה ורישום
השכבה מתאימה עסקאות שהותחשבו למכירות המקוריות ורושמת מכירות, עמלות ותשלומים ל-ERP.
כשמשהו נכשל
אין תשובה בזמן
אם השער אינו מקבל תגובה בתוך מגבלת הזמן של הסולק, הוא שולח הודעת היפוך, הודעת ISO 8583 0400 או המקבילה ב-API, כך שהלקוח לעולם אינו מחויב על מכירה שלא הושלמה.
תשלום נדחה
קוד התגובה מגיע לקופה או לקופה האונליין עם הודעה ברורה. שיעורי הדחייה מנוטרים, כך שזינוק שמעיד על תקלה טכנית מפעיל התראה.
התחשבנות אינה מתאימה
סכום שהותחשב ושונה מהמכירה, או מכירה בלי התחשבנות, עוברים לרשימת סקירה לצוות תפעול התשלומים שלכם, כששתי הרשומות זו לצד זו.
בעל הכרטיס מערער על תשלום
דוח המחלוקות של הסולק מיובא ומקושר למכירה ולהתחשבנות המקוריות, כך שהצוות שלכם יכול להשיב עם הראיות במקום אחד.
תקנים ומערכות
- תקני בנקאות וערוצים
- SFTP (H2H)
- תשלומים
- ISO 8583
- EMV
- EMV 3-D Secure
- PCI DSS
- אינטגרציה
- REST
- Webhooks
שאלות ותשובות
מה ההבדל בין שער לסולק?
הסולק הוא הבנק או המוסד המורשה שמעבד תשלומי כרטיסים עבורכם ומשלם את הכסף. השער הוא השירות הטכני שלפניו שמקבל בקשות ממסופים ומקופות, מבצע טוקניזציה לכרטיסים ומנתב אותם. חלק מהספקים הם שניהם. התכנון עובד כך או כך ושומר על שני התפקידים ברורים.
האם זה שומר את נתוני הכרטיס מחוץ למערכות שלנו?
זו מטרת התכנון. מספרי כרטיסים נלכדים במסוף המוסמך או בדף תשלום מתארח ומוחלפים בטוקנים בשער, כך שה-POS, ה-ERP ומאגרי הנתונים שלכם רואים רק טוקנים. זה מקטין את החלק במערך שלכם שכפוף ל-PCI DSS. המעריך שלכם מאשר את ההיקף הסופי.
האם ISO 8583 זהה אצל כל סולק?
לא. ISO 8583 מגדיר מבנה, וכל סולק או רשת מפרסמים מפרט משלהם לשדות, לסוגי הודעות ולקודים. לכן אנחנו בונים לפי המפרט של הסולק ומריצים את מבחני ההסמכה שלו. API של שער לפני הסולק מסתיר את ההבדלים האלה, וזה לעיתים קרובות פשוט יותר לקמעונאים.
למה ההתחשבנות מגיעה אחרי המכירה?
אישור רק משריין את הכספים. הסולק מתחשבן באצוות, לאחר ניכוי העמלות שלו וכל חיובי הרשת, ומשלם לפי לוח הזמנים שלו. לכן התכנון מתייחס לאישור ולהתחשבנות כאירועים נפרדים ומתאים ביניהם, כך שהפיננסים רואים מה נמכר, מה הותחשב ומה עוד אמור להגיע.
האם אתם תומכים ב-EMV 3-D Secure לתשלומים מקוונים?
כן. לתשלומי כרטיסים מקוונים אנחנו משלבים EMV 3-D Secure דרך השער, כך שהמנפיק יכול לאמת את בעל הכרטיס היכן שהרגולציה או הסיכון דורשים זאת. אנחנו מטפלים בתהליכי אתגר וללא חיכוך בקופה ובודקים את שניהם עם כרטיסי הבדיקה של הספק.
האם נוכל להשתמש ביותר מספק תשלומים אחד?
כן. שכבת האינטגרציה שומרת מודל פנימי אחד של תשלום וממפה אותו לכל ספק, כך שאפשר לנתב לפי ערוץ, מדינה או סוג כרטיס, או להעביר נפח בין ספקים. כל ספק עדיין צריך אינטגרציה והסמכה משלו, ואנחנו מתכננים ספק אחר ספק.
מתחילים בשיחה, לא בחוזה.
ספרו לנו מה אתם צריכים לבנות, לחבר או לאבטח. ארכיטקט עובר על זה איתכם, ואז ממליץ מאיפה להתחיל.
מה קורה עכשיו
תיאום מועד
הצוות שלנו שולח לכם דוא״ל לתיאום מועד למפגש.
מפגש ייעוץ מקדים
מפגש ייעוץ מקדים מקוון ללא עלות של 30 דקות: אנחנו עוברים איתכם על המטרות, המערכות והמגבלות שלכם.
סקירת מוכנות
במסגרת סקירת מוכנות ללא עלות בת 48 שעות, מהנדס ראשי בודק את הפרויקט שלכם מול הגדרת המוכנות בת שש הנקודות וממליץ על המסלול המתאים.
בחירת המסלול
פרויקטים עם היקף מוכן מקבלים הצעה מחייבת בתוך 3–5 ימי עסקים. פרויקטים בשלב הרעיון מתחילים ב-Blueprint Studio. מערכת חיה שנכשלת, אינה מתועדת או זקוקה לאינטגרציה מתחילה באבחון של 1–2 שבועות. ל-Blueprint Studio ולאבחון יש שכר טרחה קבוע, הנקוב בהצעה.