היי — ראיתי את ההודעה שלך הבוקר, צילום המסך של מישהו ששואל "איך אני משלם לך על זה" בתיבת התמיכה של האפליקציה שלך. מזל טוב, באמת. זה הרגע שבו פרויקט צדדי מפסיק להיות דמו. זה גם הרגע שבו מאה החלטות קטנות שיכולת לדחות עד כה, כולן צצות באותו יום שלישי. ביקשת ממני פשוט להגיד לך מה לעשות. אני אעשה את זה, אבל אני רוצה קודם לעבור איתך על ה'למה', כי ה'למה' הוא מה שמונע ממך לשאול אותי שוב בעוד שלושה חודשים כשמדובר ב-Lemon Squeezy במקום Stripe, או במנויים במקום רכישה חד-פעמית.
ההחלטה שאתה באמת מקבל
ניסחת את זה כ"באיזה ספק תשלומים להשתמש", אבל בעצם מדובר בשתי החלטות שמונחות זו על גבי זו. ראשית: האם אתה רוצה להיות ה-merchant of record, או שמישהו אחר יהיה? שנית: מה צורת החיוב שלך — רכישה חד-פעמית, מנוי, או תשלום לפי שימוש? אם תטעה בהחלטה הראשונה, תמצא את עצמך מבזבז סוף שבוע בעוד חצי שנה נרשם למע"מ במדינה שמעולם לא ביקרת בה. אם תטעה בשנייה, זו הגירה מעצבנת, לא בעיה משפטית, כך שהיא הפחות מפחידה מבין השתיים.
להיות ה-merchant of record משמעו שאתה זה שמוכר את המוצר, מבחינה משפטית. אתה גובה את הכסף, אתה אחראי לחשב מס מכירות ומע"מ בכל תחום שיפוט שבו חיים הלקוחות שלך, ואתה מגיש דוחות עבור זה. Stripe ישמח לחשב עבורך את המס הזה (Stripe Tax), אך חישוב אינו זהה להעברה — עדיין עליך להירשם ולהגיש דוחות בכל מקום שבו אתה חוצה סף מסוים. שירות merchant of record כמו Lemon Squeezy או Paddle מסיר ממך את כל הבעיה הזו: הם המוכר מבחינה משפטית, הם גובים ומעבירים מס בכל מקום, והם משלמים לך את הנטו. אתה מוותר על פרוסה מהמרווח בתמורה.
| אפשרות | מי המוכר | שיעור עמלה טיפוסי | טיפול במס | הכי מתאים ל |
|---|---|---|---|---|
| Stripe (ישיר) | אתה | ~2.9% + $0.30 לעסקה, +0.5% עבור Stripe Tax | אתה נרשם ומגיש דוחות, Stripe רק מחשב | אתה מצפה לגדול מעבר לכמה אלפים בחודש ורוצה עמלות נמוכות יותר בטווח הארוך |
| Lemon Squeezy | Lemon Squeezy | ~5% + $0.50/עסקה | טיפול מלא, הם המוכר הרשמי | בונה עצמאי, מוצר ראשון, לא רוצה לחשוב בכלל על מיסים |
| Paddle | Paddle | ~5% + עמלות משתנות לפי אזור | טיפול מלא, מתאים יותר לארגונים גדולים | SaaS עם מנויים וכמה צרכי חשבוניות |
| PayPal | אתה | ~3.5-4.5%, מחלוקות ידידותיות לקונה | אתם מטפלים בזה | לקוחות שסומכים ספציפית על PayPal, לא בחירת ברירת מחדל |
עבור המצב שבו אתם נמצאים כרגע — לקוח אחד, מוצר פשוט, אין עדיין מושג אם זה יהפוך לעסק — הייתי מפנה אתכם ל-Lemon Squeezy או Paddle במקום Stripe ישירות. שתי נקודות האחוז הנוספות בעמלה הן ביטוח זול מפני הפיכה בטעות למגישי דוחות מס במדינה שמעולם לא ביקרתם בה. תמיד אפשר לעבור ל-Stripe ישירות מאוחר יותר, ברגע שהנפח מצדיק את המעבר ויש לכם חוסן נפשי לניירת. אף אחד לא עובר בין ספקי תשלום בשביל הכיף, אבל זו בעיה שפותרים ביום שלישי אחד, לא בעיה שלוקחת שנה.
עשיתי בעצמי את הטעות הזו בפרויקט קודם — קפצתי ישר ל-Stripe כי "כולם משתמשים ב-Stripe", גביתי כמה מאות דולרים בחודש מקומץ לקוחות אירופאים, וקיבלתי מייל מנומס אך מבלבל מאוד בנוגע לרישום VAT MOSS שמונה עשר חודשים אחר כך. זה עלה לי בצהריים אחד עם רואה חשבון ו-40 דקות של פאניקה טהורה בגיגול "האם אני חייב כסף להולנד". לא קטסטרופלי. גם לגמרי ניתן למניעה.
לפני שאתם נוגעים במפתחות החיים
מה שלא תבחרו, אל תחברו את זה קודם במצב ייצור. לכל אחד מהספקים האלה יש מצב בדיקה/סנדבוקס עם מספרי כרטיס פיקטיביים שמפעילים תוצאות ספציפיות — חיוב מוצלח, כרטיס נדחה, נדרש 3D Secure, אין מספיק כיסוי. עברו על כולם לפני שאתם נוגעים במפתח אמיתי. נתיבי הכשל הם אלה שתיתקלו בהם בפועל בשבוע הראשון, והרבה פחות כיף לנפות אותם בזמן אמת עם כרטיס של אדם אמיתי מחובר.
בצ'אט הבנייה שלכם, ציינו במפורש שאתם רוצים שזה יתבצע בשלבים: בקשו שהאינטגרציה תחובר קודם למצב בדיקה, עם באנר או דגל ברור לעין כדי שאף אחד — כולל אתם בעתיד — לא יחייב בטעות כרטיס אמיתי בזמן הבדיקה. לאחר מכן בצעו שלב שני ומכוון שבו מחליפים למפתחות חיים. שני פרומפטים, לא אחד, גם אם היה מהיר יותר פשוט לומר "הוסף תשלומים" ולתת למערכת לנחש איזה מצב. החיכוך הוא הנקודה.
אתם גם צריכים להחליט מה קורה כשוובהוק מופעל והשרת שלכם למטה, או איטי, או שהאירוע מגיע פעמיים. זה לא היפותטי — זה קורה בשבוע הראשון, בעקביות. האירועים שאתם באמת צריכים לטפל בהם, לכל הפחות:
checkout.session.completed(או המקבילה) — הענקת גישה, זה הרגע שבו הלקוח הופך ללקוחinvoice.payment_failed— במנויים, החליטו כעת האם זו נעילה מיידית או תקופת חסד, כי "נעילה מיידית" היא רושם ראשוני גרוע באמת בעבור כרטיס שהייתה לו תקלה זמניתcustomer.subscription.deleted— מישהו ביטל, בטלו את הגישה בסוף התקופה, לא מיידית, אלא אם התנאים שלכם קובעים אחרת- אירוע החזר — החליטו פעם אחת, בכתב לעצמכם, מה מדיניות ההחזרים שלכם באמת, לפני שהבקשה הראשונה להחזר תאלץ אתכם להחליט בזמן אמת
אידמפוטנטיות חשובה כאן יותר מכמעט בכל מקום אחר באפליקציה שלכם. אם וובהוק מגיע פעמיים — וזה יקרה, ספקים מנסים שוב על כל תגובה שאינה 200 — אסור לכם להעניק גישה פעמיים או, גרוע מכך, לחייב פעמיים את המצב הפנימי. שמרו את מזהה האירוע ובדקו שלא עיבדתם אותו קודם לפני שאתם פועלים לפיו.
שאלת התמחור שאתם נמנעים ממנה
ציינתם בהודעה שלכם שלא הייתם בטוחים אם לגבות 9$ לחודש או תשלום חד-פעמי של 49$. אני לא חושב ששתי האפשרויות שגויות, אבל שימו לב ממה אתם באמת נמנעים: השיחה עם הלקוח על מה הערך המתמשך בפועל. מחיר חד-פעמי קל יותר להסכים לו וקל יותר לכם לבנות (בלי ניהול תשלומים כושלים, בלי טיפול בחידוש שנכשל, בלי תהליך ביטול). מנוי הוא הימור שתמשיכו לשפר את המוצר מספיק כדי שאנשים לא יעזבו — וזו מחויבות אמיתית, לא רק תיבת סימון בעמוד תמחור. אם אתם לא בטוחים שתמשיכו לעבוד על זה באופן פעיל בעוד שישה חודשים, מחיר חד-פעמי הוא ההצעה היותר כנה. תמיד אפשר להוסיף מסלול מנוי מאוחר יותר ברגע שיש משהו מתמשך להירשם אליו.
עוד דבר אחד, ואז אתן לכם לחזור לעבודה: שימו מדיניות החזרים וביטול אמיתית בעמוד לפני שאתם גובים את הדולר הראשון, גם אם זה רק שלושה משפטים. לא בגלל שמישהו יתבע אתכם על חיוב של 9$, אלא כי כתיבה מאלצת אתכם באמת להחליט את זה, ו"אני אבין את זה כשמישהו ישאל" זו הדרך שבה תמצאו את עצמכם מקבלים החלטת מדיניות באמצע מייל כועס במקום אחר צהריים רגוע.
לכו לחבר את הסנדבוקס קודם. שלחו לי הודעה כשעברתם עם כרטיס מדומה שנדחה — זו הגרסה של "זה עובד" שבאמת חשובה.
