אימיילים רב-לשוניים מ-Stripe Webhooks
הרחבת SaaS גלובלית כוללת מלכודות נסתרות. מצאנו אחת ב-Stripe webhooks שלנו.
המערכת שלנו שלחה אישורי רכישה, חידושים והודעות על כשל ביפנית למשתמשים דוברי אנגלית. הבאג הזה התקיים במשך חודשים כי הוא נשאר שקט.
פתרנו זאת על ידי הסקת השפה מתוך המטבע.
בחנו שלוש אפשרויות עיצוב:
- אפשרות A: שמירת השפה במסד הנתונים. זה דורש מיגרציות ו-backfills עבור משתמשים קיימים.
- אפשרות B: משיכה מ-Stripe API. זה מוסיף קריאות API נוספות ולקוחות רבים אינם מגדירים locale מועדף.
- אפשרות C: שימוש במטבע בתוך ה-webhook payload. זה בחינם, אינו דורש שינויים במסד הנתונים, ועובד עבור משתמשים קיימים באופן מיידי.
בחרנו באפשרות C. מטבע הוא סימן קבוע ברגע הרכישה. אם משתמש משלם ב-USD, הוא מקבל אנגלית. אם הוא משלם ב-JPY, הוא מקבל יפנית.
הלוגיקה פשוטה:
function lang_from_currency(string $currency): string {
$en_currencies = ['usd'];
return in_array(strtolower($currency), $en_currencies, true) ? 'en' : 'ja';
}
זה עובד עבור כל ארבעת אירועי ה-Stripe העיקריים:
- checkout.session.completed
- invoice.payment_succeeded
- invoice.payment_failed
- customer.subscription.updated
מצאנו גם מלכודת טכנית עם PHP.
שימוש ב-mb_language('Japanese') מקודד כותרות (subjects) בפורמט ISO-2022-JP. אם שולחים שורת נושא באנגלית עם ההגדרה הזו, Gmail ו-Outlook מזהים זאת כקידוד מוזר. זה מעלה את ציון הספאם שלכם.
הפתרון הוא להחליף את הקידוד בהתאם לשפה:
mb_language($lang === 'en' ? 'uni' : 'Japanese');
שימוש ב-'uni' משתמש ב-UTF-8 Base64. זה שומר על האימיילים שלכם מחוץ לתיקיית הספאם.
שלושה לקחים מהתיקון הזה:
- השתמשו ב-event payload. אם הנתונים כבר נמצאים ב-webhook, אל תיגעו במסד הנתונים שלכם. זה מפחית סיכונים ותחזוקה.
- שימו לב לקידוד. אם אתם תומכים במספר שפות, ודאו שקידוד שורת הנושא תואם לתוכן כדי להימנע ממסנני ספאם.
- בדקו ערכים קשיחים (hardcoded). כשאתם עוברים לשוק הבינלאומי, בדקו אם לפונקציות ההתראות שלכם יש הגדרות שפה קשיחות.
עיצוב stateless הופך את המערכת שלכם לקלה יותר לתחזוקה וקשה יותר לשבירה.