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