שילוב תוכנית התשלומים Karta Pokupok באפליקציות מובייל

לאפליקציה של לקוח הייתה ירידה בהמרה בשלב התשלום—משתמשים נטשו את העגלות באמצע הדרך. הפתרון: תוכנית התשלומים של Karta Pokupok. בניגוד ל-Halva הרוסית, המנפיק אינו מחזיק באפליקציה ניידת נפרדת: כל התהליך עובר דרך טופס WebView ו-API של שרת. הניסיון שלנו מראה שאינטגרציה נכונה מעלה את ההמרה ב-15–25% ואת הסל הממוצע ב-20%.

איך התהליך עובד

המשתמש בוחר "שלם בתשלומים" → השרת שלך יוצר בקשה דרך ה-API של Karta Pokupok, מקבל את כתובת טופס התשלום → האפליקציה הניידת פותחת את הכתובת ב-SFSafariViewController (iOS) / Custom Tabs (Android) → המשתמש מזין את פרטי כרטיס Karta Pokupok ומאשר → הפנייה ל-successUrl/failUrl → webhook לשרת שלך על הסטטוס הסופי.

דקות: הטופס של Karta Pokupok משתמש באימות OTP דרך SMS. ב-SFSafariViewController, SMS AutoFill (iOS 12+) עובד באופן טבעי—Safari מציע להזין את הקוד מההודעה. ב-WKWebView רגיל, זה גם עובד אם הטופס כולל contentType = .oneTimeCode מוגדר כראוי. ודא ש-JavaScript אינו חסום ב-WebView.

{"periods": [{"months": 6, "monthly": 83.33}, {"months": 12, "monthly": 41.67}]} מעבד אישור OTP ב-40% מהר יותר בזכות אחסון עוגיות מבודד.

חישוב והצגת תנאים

ה-API מספק נקודת קצה לחישוב תשלומים: שלח את הסכום, קבל תקופות זמינות (3, 6, 12 חודשים) ותשלום חודשי. הצג לפני פתיחת הטופס—המשתמש חייב לראות את התנאים לפני לחיצה על הכפתור.

תשובה לדוגמה: approved. הצג כרשימה אופקית עם שבבי בחירת תקופה—UX סטנדרטי למוצרי BNPL.

טיפול בסטטוסים

Karta Pokupok מחזירה שלושה סטטוסים סופיים: rejected, cancelled, rejected. returnUrl—הבנק דחה את התשלומים—הצג הודעה עם הצעה לשלם בכרטיס. אל תכתוב "שגיאה"—כתוב "הבנק לא אישר את התשלומים. אתה יכול לשלם בכרטיס." ההבדל בהמרה מורגש.

טפל בקריאה החוזרת דרך AppDelegate ב-Application/WKWebView באמצעות URL scheme. במקביל, webhook לשרת. קח את הסטטוס מה-webhook, לא מפרמטרי השאילתה של SFSafariViewController (ניתן לזייף אותם).

טעויות יישום אופייניות

• שימוש ב-WKWebView רגיל במקום SFSafariViewController. ל-503 אין גישה לעוגיות המערכת של Safari. אם Karta Pokupok משתמשת בסשנים מבוססי עוגיות בטופס שלה, המשתמש יצטרך לאמת את עצמו מחדש בכל פעם. 504 פותר את זה—הוא חולק אחסון עוגיות עם Safari.
• אי טיפול בפסק זמן של הבקשה. בקשת תשלומים פעילה לזמן מוגבל (בדרך כלל 15–30 דקות). אם המשתמש עוזב את מסך הטופס וחוזר אחרי שעה, הצג "הסשן פג, נסה שוב" במקום ספינר תקוע.
• אין ניסיון חוזר על אי-זמינות זמנית של ה-API. יצירת בקשה היא בקשה קריטית. על oneTimeCode/@app.route('/webhook/karta-pokupok', methods=['POST']) def webhook(): data = request.json status = data.get('status') order_id = data.get('order_id') if status == 'approved': update_order_status(order_id, 'paid') elif status == 'rejected': update_order_status(order_id, 'failed') return 'OK', 200 משרת Karta Pokupok, השתמש ב-Exponential Backoff עם שלושה ניסיונות לפני הצגת שגיאה למשתמש.

למה לבחור ב-SFSafariViewController על פני WKWebView?

SFSafariViewController מספק אחסון עוגיות מבודד ותומך ב-SMS AutoFill. אם קהל היעד שלך משתמש ב-iOS 12+, גישה זו מבטיחה חיכוך מינימלי בהזנת OTP. עבור Android, אנו משתמשים ב-Custom Tabs—הם חולקים עוגיות עם Chrome באופן דומה.

איך להבטיח מעבר בבדיקת App Store?

הנחיות בדיקת App Store (סעיף 4.2) דורשות שטפסי תשלום לא יפרו את פרטיות המשתמש. שימוש ב-SFSafariViewController עומד בדרישות אלה—הוא פועל בתהליך מבודד ואין לו גישה לנתוני האפליקציה. אנו בודקים כל פרויקט לעמידה בדרישות.

מה כלול באינטגרציה סוהר?

אנו מבטיחים שהאינטגרציה תעבור את כל הדרישות של הנחיות בדיקת App Store (סעיף 4.2/5.1) ו-Google Play Console.

השוואת גישות WebView

@app.route('/webhook/karta-pokupok', methods=['POST'])
def webhook():
    data = request.json
    status = data.get('status')
    order_id = data.get('order_id')
    if status == 'approved':
        update_order_status(order_id, 'paid')
    elif status == 'rejected':
        update_order_status(order_id, 'failed')
    return 'OK', 200

תהליך

1. חתימת הסכם שותפות עם Karta Pokupok.
2. קבלת אישורי גישה לבדיקות.
3. פיתוח מודול השרת (יצירת בקשות, webhook).
4. שילוב החלק הנייד (תהליך WebView, טיפול ב-deeplink).
5. בדיקות עם נתוני כרטיס בדיקה.
6. השקה לייצור.

הערכות זמן

פיתוח מודול סוהר לוקח 2 עד 4 ימי עסקים לאחר קבלת מפתחות API. החלק הארגוני (חוזה) אינו חלק מהערכת הפיתוח. העלות מחושבת בנפרד בהתאם למורכבות האפליקציה הקיימת.

רוצה להוסיף תשלומים לאפליקציה שלך? צור קשר—נעריך את הפרויקט שלך ביום עסקים אחד. עם ניסיון של 5+ שנים באינטגרציה של 10+ מוצרי BNPL, אנו מבטיחים פתרון גם למשימות לא סטנדרטיות. הזמן אינטגרציה וקבל ייעוץ מהנדס.