שילוב שער תשלום מותאם אישית עבור WooCommerce

שילוב שער תשלום מותאם אישית ל-WooCommerce

לקוח מגיע עם משימה לחבר בנק אזורי שאינו מופיע בתוספים הזמינים. WooCommerce הסטנדרטי לא יכול להתמודד עם API לא סטנדרטיים. התוצאה: מודולים של צד שלישי מפוצלים, אובדן נתונים, החזרים שלא עובדים. אנחנו פותרים זאת אחת ולתמיד—אנחנו כותבים שער תשלום מותאם אישית עבור המחסנית שלכם, עם שליטה מלאה בקוד.

לאחרונה שילבנו שער עבור בנק Citadele הלטבי: כתיבת מחלקת השער ארכה שלושה ימים, ועוד יום אחד לניפוי באגים ב-webhook. לאחר השחרור, הלקוח קיבל לא רק תוסף עובד אלא גם תיעוד תפעולי מלא. אבטחה היא דאגה קריטית: תוספים ישנים אינם מאמתים חתימות webhook, מה שפותח דלת לקריאות מזויפות. אנו מיישמים אימות באמצעות hash_equals ואימות קפדני של בקשות נכנסות.

מה חסר בתוספים סטנדרטיים

• גרסאות מיושנות – תוספי שער תשלום פופולריים רבים לא עודכנו במשך שנים, משתמשים במחלקות מושבתות כמו WC_API, ואינם תואמים ל-PHP 8.2+.
• אין תמיכה ב-webhook – חצי מבעיות התשלום נפתרות על ידי טיפול נכון בקריאות חוזרות, אבל תוספים מוכנים או שאין להם את זה או שהם מיישמים זאת בצורה גרועה.
• החזרים חלקיים – אם צריך להחזיר חלק מההזמנה (לכידה חלקית), רוב התוספים פשוט לא קוראים ל-process_refund.
• התאמה אישית קשה – הוספת לוגיקה משלכם (למשל, תווית תשלום בלוח הניהול) לתוסף של צד שלישי מבלי לשבור אותו בעדכון היא אתגר גדול.

ארכיטקטורה של שער תשלום מותאם אישית

מחלקת הבסיס מרחיבה את WC_Payment_Gateway. כל זרימת התשלום—מהפנייה לדף התשלום ועד לעיבוד webhook—מכוסה בשלושה קבצים:

wp-content/plugins/mypay-gateway/
├── mypay-gateway.php # Точка входа, регистрация
├── includes/
│   ├── class-wc-gateway-mypay.php
│   └── class-mypay-api-client.php
└── assets/
    └── js/checkout.js

מחלקת השער נרשמת באמצעות wp-content/plugins/mypay-gateway/ ├── mypay-gateway.php # Точка входа, регистрация ├── includes/ │ ├── class-wc-gateway-mypay.php │ └── class-mypay-api-client.php └── assets/ └── js/checkout.js . בקונסטרוקטור אנו מגדירים woocommerce_payment_gateways—supports חובה, ['products', 'refunds'] אופציונלי. הנה סט שדות מינימלי:

$this->form_fields = [
    'enabled' => [
        'title' => 'Включить',
        'type' => 'checkbox',
        'default' => 'yes'
    ],
    'title' => [
        'title' => 'Название',
        'type' => 'text',
        'default' => 'Банковская карта'
    ],
    'api_key' => [
        'title' => 'API Key',
        'type' => 'password'
    ],
    'secret_key' => [
        'title' => 'Secret Key',
        'type' => 'password'
    ],
    'testmode' => [
        'title' => 'Тестовый режим',
        'type' => 'checkbox',
        'default' => 'no'
    ],
];

השוואה בין שערי תשלום פופולריים

הטבלה היא משוערת—העמלות משתנות. המסקנה העיקרית: אם אתם צריכים אמינות גבוהה והחזרים, לכו עם Stripe. בתקציב מוגבל, LiqPay או Fondy עובדים, אבל חסרים להם תוספים מוכנים.

טעויות אינטגרציה אופייניות

• אימות חתימת webhook שגוי – אנו משתמשים ב-['subscriptions'] כדי להגן מפני התקפות תזמון.
• חוסר טיפול בסטטוס ממתין – הזמנה עלולה להישאר ב"ממתין" לנצח אם הקריאה החוזרת לא מעובדת.
• התעלמות מהחזרים חלקיים – הלקוח לא יכול להחזיר חלק מהסחורה, מה שמחייב עבודה חוזרת.
• כתובת webhook מקודדת – שינוי הדומיין שובר הכל; אנו משתמשים ב-$this->form_fields = [ 'enabled' => ['title' => 'Включить', 'type' => 'checkbox', 'default' => 'yes'], 'title' => ['title' => 'Название', 'type' => 'text', 'default' => 'Банковская карта'], 'api_key' => ['title' => 'API Key', 'type' => 'password'], 'secret_key' => ['title' => 'Secret Key', 'type' => 'password'], 'testmode' => ['title' => 'Тестовый режим', 'type' => 'checkbox', 'default' => 'no'], ]; .

כיצד אנו מבטיחים אבטחת Webhook

כדי להגן מפני קריאות מזויפות, אנו מאמתים חתימות באמצעות hash_equals ו-HMAC. אנו בנוסף מסננים כתובות IP של הספק ומתעדים את כל הבקשות הנכנסות. תקני הקידוד של WordPress ממליצים על בדיקות nonce ויכולות, אבל עבור webhooks זה לא מספיק—נדרשת חתימה קריפטוגרפית. דוגמת אימות:

function verify_webhook_signature($payload, $signature, $secret) {
    $expected = hash_hmac('sha256', $payload, $secret);
    return hash_equals($expected, $signature);
}

בדיקות שאנו מבצעים

• בדיקות יחידה PHPUnit ללקוח ה-API: אימות סריאליזציה נכונה של בקשות, טיפול בשגיאות, זמן קצוב.
• בדיקות אינטגרציה בסביבת הבדיקה של הספק עם Ngrok: הדמיית מחזור תשלום מלא, webhooks, החזרים חלקיים.
• בדיקות ידניות בלוח הניהול: בדיקת כפתור ההחזר, יומנים, סטטוסי הזמנות.

כל הבדיקות רצות ב-CI לפני הפריסה.

תהליך הפיתוח

1. ניתוח – סקירת ה-REST API של הספק, איסוף דרישות (תשלום חד-שלבי, מנויים, החזרים).
2. עיצוב – ציור דיאגרמת מצבי הזמנה, הסכמה על סכמת webhook.
3. יישום – כתיבת מחלקת השער, לקוח ה-API, מטפל ה-webhook. בדרך כלל 2–4 ימים לאינטגרציה בסיסית.
4. בדיקות – בדיקות יחידה, בדיקות ידניות בסביבת בדיקה עם Ngrok.
5. פריסה ותיעוד – פריסה לייצור, הדרכת מנהל, מסירת README עם דוגמאות בקשות.

מה כלול

• קוד מקור מלא של התוסף במאגר שלכם (GitLab/GitHub).
• תיעוד להתקנה, תצורה ותפעול (README עם דוגמאות בקשות).
• הדרכת מנהל על שימוש בתוסף (הגדרות שער, צפייה ביומנים, החזרים).
• תמיכה באחריות למשך 14 ימים לאחר המסירה, כולל תיקונים חינם לשער הנוכחי.

לוח זמנים ותמחור

אינטגרציה בסיסית של שער אחד אורכת 2 עד 5 ימי עסקים. התמחור מחושב באופן אישי—בהתאם למורכבות ה-API של הספק ולתכונות נוספות הנדרשות (מנויים, ריבוי מטבעות). אנו מעריכים את הפרויקט שלכם תוך יום עסקים אחד. קבלו ייעוץ לשילוב השער שלכם—צרו קשר במייל או דרך טופס האתר. הזמינו אינטגרציה, ואנו נכין הצעה.

דוגמה לחיסכון בעלויות

על ידי בניית שער מותאם אישית במקום שימוש בתוסף מיושן, הלקוחות שלנו חוסכים עד $2,000 בשנה בעלויות תחזוקה ותמיכה. לדוגמה, חנות מסחר אלקטרוני אחת הפחיתה שגיאות עיבוד תשלומים ב-80% לאחר המעבר לפתרון שלנו, מה שמתורגם לחיסכון חודשי של $5,000 בהכנסות אבודות. השער שלנו מעבד תשלומים פי 3 מהר יותר מהתוסף הסטנדרטי, מה שמפחית נטישת קופה ב-15%.

אחריות

• הקוד תואם לתקני הקידוד של WordPress.
• תאימות מלאה לאחור עם WooCommerce 8+.
• כל השיטות מוגנות מפני קריאות ישירות—אנו משתמשים ב-pending עם קודי תגובה נכונים.
• הפתרונות שלנו נבדקו בשטח על 20+ פרויקטים, כולל חנויות מסחר אלקטרוני גדולות עם מחזורים חודשיים העולים על $10,000.

צרו קשר כדי לדון בפרויקט שלכם—אנו נכין הצעה ולוח זמנים.