האם קבלת כרטיסים מכניסה אותי להיקף PCI?

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

מהו 3-D Secure 2.0 והאם זה יפגע בהמרה?

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

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

soft decline מנוסה שוב במסלול חלופי באותו session, לפני שהלקוח רואה כשל. hard decline מדווח בשפה שאיש תפעול יכול לפעול לפיה — כרטיס שפג תוקפו, יתרה לא מספקת, סיכון אצל המנפיק — ולא כקוד גולמי של המנפיק.

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

Authorization תופס את הכספים ברגע הרכישה; הסליקה מעבירה אותם. הזמנות היום נסגרות ל-batch ומשולמות ב-EUR בשעת התשלום היומית שהוגדרה בהגדרות שלכם — שורה אחת בבנק שאפשר לפתוח להזמנות שמימנו אותה.

אמצעי · כרטיסים

תשלומי כרטיס, כמו שצריך.

כרטיסים הם האמצעי שאי אפשר לדלג עליו, ולכן החלקים המשעממים הם החשובים ביותר: ולידציה בזמן ההקלדה, 3-D Secure 2.0 לפי מדיניות שאתם קובעים ולא חיכוך כברירת מחדל, מדיניות ניתוב שאפשר לקרוא, וניסיון חוזר במסלול חלופי לפני ש-soft decline הופך למכירה שאבדה.

ראו את Protocore Gateway כל אמצעי התשלום

Visa·MC

וגם סכמות co-badged

3-DS 2.0

SCA בתוך התהליך

EUR

מסולק לחשבון שלכם

מספרי כרטיס בשרתים שלכם

איך זה רץ

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

01
ENTER
הלקוח מקליד את הכרטיס בדף המתארח שלנו — ולידציה בזמן ההקלדה, בלי שנתוני כרטיס מגיעים אליכם.
02
AUTHENTICATE
3-D Secure פועל לפי מדיניות: רוב התשלומים עוברים על סמך אותות, ואתגר מופיע רק כשנדרש.
03
AUTHORIZE
הכספים מאומתים ונתפסים, ו-soft decline מנוסה שוב במסלול חלופי.
04
SETTLE
הזמנות היום מקובצות ל-batch ומשולמות ב-EUR מול אותו מזהה הזמנה.

מה הלקוח רואה

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

01טופס כרטיס לצד ארנקים, USDC והעברה — לא שלב נפרד
02ולידציה וזיהוי סכמה תוך כדי הזנת המספר
03אתגר 3-D Secure בתוך הדף, כשהמדיניות דורשת

מה אתם מקבלים

יורו, מקובצים לתשלום של אותו יום, מול מזהה ההזמנה שיצרתם. Authorization ו-capture מטופלים בשבילכם; הקבלה מתעדת את הסכמה, ארבע הספרות האחרונות ותוצאת האימות. התיעוד הזה הוא גם ראיית ההגנה שלכם בסכסוך — חיפוש אחד עונה על chargeback, במקום חיפוש בין מערכות.

01שורת תשלום אחת ב-EUR לכל batch סליקה
02סכמה, ארבע ספרות אחרונות ותוצאת 3-DS ברשומה
03החזרים על ההזמנה, מלאים או חלקיים, לאותו כרטיס

מה נדרש כדי להפעיל

כרטיסים מופעלים כברירת מחדל. מה שאתם מגדירים הוא המדיניות סביבם: מתי 3-D Secure מתחזק, איך הניתוב מעדיף מסלול אחד על פני אחר, ומה קורה ל-soft decline. התחילו בכרטיס ה-sandbox שלכם — התהליכים זהים, ולכן מה שעובר בבדיקה הוא מה שעולה לאוויר.

FAQ

תשלומי כרטיס — שאלות שסוחרים שואלים.

לא באופן משמעותי. הדף שאוסף את הכרטיס הוא שלנו וכפוף ל-PCI מצדנו; השרתים שלכם מקבלים token ומזהה הזמנה. זה נכון בין אם הדף רץ בדומיין שלנו, בדומיין שלכם, באפליקציה שלכם, או כשדות תשלום משובצים בעיצוב שלכם.
זה שלב האימות שעונה על דרישת אימות לקוח חזק לפי PSD2. רוב התשלומים עוברים על אותות מכשיר והתנהגות, בלי שמוצג אתגר. step-up מופיע כשהמדיניות — שאתם קובעים — דורשת זאת, כך שהחיכוך הוא החלטה ולא ברירת מחדל.
soft decline מנוסה שוב במסלול חלופי באותו session, לפני שהלקוח רואה כשל. hard decline מדווח בשפה שאיש תפעול יכול לפעול לפיה — כרטיס שפג תוקפו, יתרה לא מספקת, סיכון אצל המנפיק — ולא כקוד גולמי של המנפיק.
Authorization תופס את הכספים ברגע הרכישה; הסליקה מעבירה אותם. הזמנות היום נסגרות ל-batch ומשולמות ב-EUR בשעת התשלום היומית שהוגדרה בהגדרות שלכם — שורה אחת בבנק שאפשר לפתוח להזמנות שמימנו אותה.