חלופות / Checkout
מחפשים חלופה ל-hosted checkout
רוב מי שמחפש ספק checkout חדש לא מחפש פיצ'רים — הוא עוזב כי אמצעי תשלום שהוא צריך חסר, כי ההתאמות (reconciliation) כואבות, או כי אף אחד לא עונה כשסליקה נראית לא נכונה. הדף הזה הוא הרשימה שכדאי להפעיל על כל ספק שתבחנו בהמשך, כולל אותנו.
הערכה
שש שאלות שמבדילות בין ספק לספק.
אילו אמצעי תשלום, בדף אחד?
לא המספר שבברושור — אלא אלה שהלקוחות שלכם באמת משתמשים בהם, באותו דף. אמצעי תשלום מאחורי הפניה או אינטגרציה שנייה הוא אמצעי שתנצלו פחות מדי.
באיזה מטבע תקבלו בסוף?
אם התשובה משתנה לפי אמצעי תשלום, קניתם בעיית התאמות. שאלו במפורש מה תשלום בקריפטו או תשלום חוצה גבולות יוצר בחשבון שלכם, ובאיזה מטבע.
כמה מהיקף PCI נופל עליכם?
דף hosted אמיתי משאיר נתוני כרטיס הרחק מהשרתים שלכם, גם כשהוא משובץ בעיצוב שלכם. שאלו מה המערכות שלכם שומרות, ואיך נראית הערכת התאימות כתוצאה מכך.
האם יש אסמכתא אחת מקצה לקצה?
Checkout, קבלה, webhook, payout והחזר צריכים כולם לשאת את האסמכתא שסיפקתם. שני מזהים שצריך למפות בין מערכות — שם סגירת החודש מתקלקלת.
מה מיגרציה כוללת בפועל?
כרטיסים שמורים צריכים לעבור כ-tokens כדי שהמנויים שלכם לא יזינו פרטים מחדש, ושני הספקים צריכים להיות מסוגלים לרוץ במקביל בזמן שהישן מסיים לסלוק.
מי עונה כשזה נשבר?
תור תמיכה והצוות שכתב את קוד הסליקה הם שני מוצרים שונים. ברגע שה-payout נראה לא נכון, ההבדל הזה הוא הדבר היחיד שחשוב.
למה עוזבים ספק checkout
לעיתים נדירות בשביל מחיר זול יותר. בפועל זה אחד מארבעה דברים: אמצעי תשלום שהלקוחות מבקשים והספק לא מוסיף, מודל התאמות שגורם לצוות הכספים לחשוש מסגירת החודש, מערך תמיכה שנכשל בדיוק ברגע הלא נכון, או מפת דרכים שעצרה בזמן שעולם התשלומים המשיך. להבין מהו הגורם שלכם — זו כל ההערכה. ספק מצוין בשלושת האחרים עדיין יהיה מעבר לא נכון.
- 01אמצעי תשלום שהלקוחות רוצים ולא מגיע
- 02התאמות שעולות למישהו כמה ימים בחודש
- 03אף אחד לא אחראי כשסליקה נראית לא נכונה
- 04מוצר שהפסיק לעמוד בקצב אמצעי התשלום
כמה מעבר עולה בפועל
פחות ממה שצוותים מצפים באינטגרציה, ויותר ממה שהם מצפים בקצוות. קריאת ההזמנה ומטפל ה-webhook הם בדרך כלל שבוע; מה שדורש תכנון הוא הזנב — כרטיסים שמורים ומנויים שאסור שייפגעו, החזרים שעדיין צריכים לחזור דרך המסילות של הספק הישן, ותקופה שבה שתי המערכות פעילות. כל ספק ששווה לעבור אליו צריך להיות מסוגל לתאר את הזנב הזה לפני החתימה, לא אחריה.
- 01אינטגרציה: endpoint להזמנה, הפניה, webhook חתום אחד
- 02הזנב: כרטיסים שמורים, מנויים, החזרים בדרך, הרצה במקביל
- 03החזרים תמיד חוזרים דרך המסילה שקיבלה את התשלום
איפה Protocore Gateway משתלב
אנחנו עונים על ששת השאלות כך: כרטיסים, ארנקים, העברה בנקאית, אמצעי תשלום מקומיים, BNPL ו-USDC בדף אחד; הכול נסלק ביורו; משטח הטיפול בכרטיסים נשאר אצלנו גם כששדות הקלט משובצים בעיצוב שלכם; אסמכתא אחת עוברת מה-checkout ועד שורת הבנק; כרטיסים שמורים עוברים כ-tokens כששני הספקים רצים במקביל; ומי שעונה הם מי שכתבו את המערכת. אם זה שווה מעבר תלוי באיזו מארבע הסיבות שלמעלה היא שלכם — אם זה מחיר זול יותר, כנראה שאנחנו לא התשובה.
- 01כל אמצעי התשלום בדף אחד, נסלקים לסכום אחד ביורו
- 02אסמכתא אחת להזמנה — מה-checkout ועד ה-payout וההחזר
- 03מעבר מתוכנן עם הרצה במקביל, כולל tokens
- 04מאחוריו סטודיו מוצר, לא שכבת תמיכה
FAQ
שאלות ששווה לשאול כל ספק.
כן, ובזמן מיגרציה כדאי מאוד. הזמנות חדשות מופנות לספק החדש בזמן שהישן מסיים לסלוק ולהחזיר את התשלומים שלו — החזרים תמיד חוזרים דרך המסילה שקיבלה את התשלום, ולכן האינטגרציה הישנה נשארת פעילה עד שחלון ההחזר האחרון שלה נסגר.
לא אמורים. כרטיסים שמורים עוברים בין ספקים כ-tokens, וזו השאלה החשובה ביותר אם יש לכם מנויים — מיגרציה שמאפסת כל כרטיס שמור היא אירוע נטישה, לא מיגרציה.
האינטגרציה היא בדרך כלל שבוע. התוכנית סביבה — הרצה במקביל, מיגרציית tokens, חלון ההחזר האחרון אצל הספק הישן — היא שקובעת את לוח הזמנים, ובדרך כלל הוא נמדד בשבועות ולא בחודשים.
אז בקשו מהספק הנוכחי תאריך לפני שאתם בוחנים משהו אחר. החלפת ספק בשביל אמצעי תשלום אחד היא הרבה עבודה בשביל רווח צר, אלא אם אותה שיחה חושפת את שלוש הבעיות האחרות שלמעלה.
הפעילו עלינו את הרשימה.
בצעו תשלום אמיתי ב-checkout הדמו שלנו, ואז ספרו לנו באילו מששת השאלות הספק הנוכחי שלכם נכשל. נגיד לכם בכנות אם המעבר שווה את הרבעון שלכם.