จดหมายถึงใครสักคนที่กำลังจะเรียกเก็บเงินจากลูกค้ารายแรก

เฮ้ — ผมเห็นข้อความของคุณเมื่อเช้านี้แล้ว ภาพหน้าจอที่มีคนถามว่า "จะจ่ายเงินให้คุณสำหรับสิ่งนี้ยังไง" ในกล่องข้อความสนับสนุนของแอปคุณ ขอแสดงความยินดีจริงๆ นั่นคือช่วงเวลาที่โปรเจกต์ข้างเคียงเลิกเป็นเพียงเดโม และยังเป็นช่วงเวลาที่การตัดสินใจเล็กๆ นับร้อยที่คุณเคยเลื่อนออกไปได้ ต่างก็โผล่มาพร้อมกันในวันอังคารเดียวกัน คุณขอให้ผมบอกตรงๆ ว่าต้องทำอะไร ผมจะบอกให้ แต่ผมอยากพาคุณไล่ดูเหตุผลก่อน เพราะ "เหตุผล" นี่แหละที่จะทำให้คุณไม่ต้องมาถามผมซ้ำอีกในอีกสามเดือนข้างหน้า ตอนที่เปลี่ยนเป็น Lemon Squeezy แทน Stripe หรือเปลี่ยนจากซื้อครั้งเดียวเป็นสมัครสมาชิก

การตัดสินใจที่คุณกำลังทำจริงๆ

คุณตั้งคำถามว่า "ควรใช้ผู้ให้บริการชำระเงินเจ้าไหน" แต่จริงๆ แล้วนี่คือการตัดสินใจสองเรื่องซ้อนกันอยู่ ข้อแรก: คุณอยากเป็น merchant of record เอง หรืออยากให้คนอื่นเป็นแทน ข้อสอง: รูปแบบการเรียกเก็บเงินของคุณเป็นแบบไหน — ซื้อครั้งเดียว สมัครสมาชิก หรือคิดตามการใช้งาน หากเลือกข้อแรกผิด คุณจะต้องเสียเวลาทั้งสุดสัปดาห์ในอีกหกเดือนข้างหน้าเพื่อจดทะเบียน VAT ในประเทศที่คุณไม่เคยไปเยือน หากเลือกข้อสองผิด มันแค่เป็นการย้ายระบบที่น่ารำคาญ ไม่ใช่ปัญหาทางกฎหมาย จึงน่ากลัวน้อยกว่าในสองข้อนี้

การเป็น merchant of record หมายความว่าคุณคือผู้ขายสินค้านั้นตามกฎหมาย คุณเป็นผู้เก็บเงิน รับผิดชอบในการคำนวณภาษีขายและ VAT ในทุกเขตอำนาจศาลที่ลูกค้าของคุณอาศัยอยู่ และต้องยื่นแบบภาษีเอง Stripe ยินดีคำนวณภาษีให้คุณ (Stripe Tax) แต่การคำนวณไม่ใช่การนำส่ง — คุณยังต้องจดทะเบียนและยื่นแบบในทุกที่ที่คุณข้ามเกณฑ์ที่กำหนด บริการ merchant of record อย่าง Lemon Squeezy หรือ Paddle จะรับปัญหาทั้งหมดนี้ไปจากคุณ พวกเขาคือผู้ขายตามกฎหมาย เก็บและนำส่งภาษีในทุกที่ แล้วจ่ายเงินสุทธิให้คุณ คุณต้องแลกด้วยส่วนแบ่งกำไรบางส่วน

สำหรับจุดที่คุณอยู่ตอนนี้ — ลูกค้าคนเดียว ผลิตภัณฑ์เรียบง่าย ยังไม่รู้ว่านี่จะกลายเป็นธุรกิจหรือไม่ — ผมแนะนำ Lemon Squeezy หรือ Paddle มากกว่า Stripe แบบตรงๆ ค่าธรรมเนียมที่เพิ่มขึ้นอีกสองจุดเป็นเหมือนประกันราคาถูกที่ช่วยไม่ให้คุณต้องกลายเป็นผู้ยื่นภาษีในรัฐที่คุณไม่เคยไปโดยไม่ตั้งใจ คุณค่อยย้ายไป Stripe โดยตรงทีหลังได้ เมื่อปริมาณธุรกรรมคุ้มค่ากับการเปลี่ยน และคุณพร้อมรับมือกับงานเอกสารแล้ว ไม่มีใครย้ายผู้ให้บริการชำระเงินเพื่อความสนุก แต่มันเป็นปัญหาที่แก้ได้ในหนึ่งวัน ไม่ใช่ปัญหาที่ต้องใช้เวลาทั้งปี

ผมเองก็เคยพลาดแบบนี้มาแล้วในโปรเจกต์ก่อนหน้า — ใช้ Stripe ตรงๆ เพราะ "ทุกคนก็ใช้ Stripe" เก็บเงินได้ไม่กี่ร้อยดอลลาร์ต่อเดือนจากลูกค้ายุโรปไม่กี่คน แล้วก็ได้รับอีเมลสุภาพแต่ชวนงงเกี่ยวกับการลงทะเบียน VAT MOSS สิบแปดเดือนถัดมา มันทำให้ต้องเสียเวลานักบัญชีไปครึ่งวันบวกกับสี่สิบนาทีแห่งความตื่นตระหนกล้วนๆ ในการเสิร์ช "ผมติดหนี้เนเธอร์แลนด์หรือเปล่า" ไม่ถึงกับหายนะ แต่ก็หลีกเลี่ยงได้ทั้งหมด

ก่อนที่คุณจะแตะคีย์จริง

ไม่ว่าคุณจะเลือกอะไร อย่าเพิ่งเชื่อมต่อในโหมด production ก่อน ผู้ให้บริการเหล่านี้ทุกรายมีโหมดทดสอบ/แซนด์บ็อกซ์พร้อมหมายเลขบัตรปลอมที่กระตุ้นผลลัพธ์เฉพาะเจาะจง — เรียกเก็บเงินสำเร็จ บัตรถูกปฏิเสธ ต้องยืนยัน 3D Secure เงินไม่พอ ลองทุกกรณีก่อนที่คุณจะแตะคีย์จริง เส้นทางความล้มเหลวคือสิ่งที่คุณจะเจอจริงในสัปดาห์แรก และมันแก้บั๊กยากกว่ามากถ้าเกิดขึ้นจริงกับบัตรของคนจริง

ในแชทสร้างของคุณ ให้บอกชัดเจนว่าคุณต้องการแบ่งเป็นขั้นตอน: ขอให้เชื่อมต่อระบบในโหมดทดสอบก่อน พร้อมแบนเนอร์หรือแฟล็กที่เห็นได้ชัด เพื่อไม่ให้ใคร — รวมถึงตัวคุณในอนาคต — เผลอเรียกเก็บเงินจากบัตรจริงระหว่างทดสอบ จากนั้นค่อยมีขั้นตอนที่สองที่ตั้งใจสลับไปใช้คีย์จริง สองคำสั่ง ไม่ใช่คำสั่งเดียว แม้ว่าการพูดแค่ "เพิ่มระบบชำระเงิน" แล้วปล่อยให้ทายเอาว่าจะใช้โหมดไหนจะเร็วกว่า แต่ความยุ่งยากตรงนี้คือประเด็นสำคัญ

คุณยังต้องตัดสินใจว่าจะเกิดอะไรขึ้นเมื่อ webhook ยิงเข้ามาแต่เซิร์ฟเวอร์ของคุณล่ม หรือช้า หรือเหตุการณ์นั้นมาซ้ำสองครั้ง นี่ไม่ใช่สมมติฐาน — มันเกิดขึ้นจริงในสัปดาห์แรกอย่างสม่ำเสมอ เหตุการณ์ที่คุณจำเป็นต้องจัดการอย่างน้อยที่สุดคือ:

• checkout.session.completed (หรือเทียบเท่า) — ให้สิทธิ์การเข้าถึง นี่คือช่วงเวลาที่ลูกค้ากลายเป็นลูกค้าจริงๆ
• invoice.payment_failed — สำหรับการสมัครสมาชิก ตัดสินใจตอนนี้ว่าจะปิดการเข้าถึงทันทีหรือให้ระยะเวลาผ่อนผัน เพราะ "ปิดทันที" เป็นความประทับใจแรกที่แย่จริงๆ สำหรับบัตรที่แค่มีปัญหาชั่วคราว
• customer.subscription.deleted — มีคนยกเลิก เพิกถอนการเข้าถึงเมื่อสิ้นสุดรอบบิล ไม่ใช่ทันที เว้นแต่ข้อกำหนดของคุณจะระบุไว้เป็นอย่างอื่น
• เหตุการณ์การคืนเงิน — ตัดสินใจไว้ล่วงหน้าเป็นลายลักษณ์อักษรกับตัวเองว่านโยบายคืนเงินของคุณเป็นอย่างไรจริงๆ ก่อนที่คำขอคืนเงินครั้งแรกจะบังคับให้คุณตัดสินใจแบบสดๆ

ความเป็น idempotent สำคัญที่นี่มากกว่าที่อื่นในแอปของคุณเกือบทั้งหมด ถ้า webhook มาถึงสองครั้ง — และมันจะเป็นแบบนั้น เพราะผู้ให้บริการจะลองส่งใหม่เมื่อได้รับการตอบกลับที่ไม่ใช่ 200 — คุณไม่สามารถให้สิทธิ์การเข้าถึงสองครั้ง หรือแย่กว่านั้นคือเรียกเก็บเงินซ้ำในสถานะภายใน จัดเก็บ event ID และตรวจสอบว่ายังไม่เคยประมวลผลมาก่อนก่อนที่จะดำเนินการ

คำถามเรื่องราคาที่คุณกำลังหลีกเลี่ยง

คุณพูดถึงในข้อความว่าไม่แน่ใจว่าจะคิดเงิน $9/เดือน หรือคิดครั้งเดียว $49 ผมไม่คิดว่าอันไหนผิด แต่สังเกตดูว่าคุณกำลังหลีกเลี่ยงอะไรอยู่จริงๆ: บทสนทนากับลูกค้าเรื่องคุณค่าที่เกิดขึ้นต่อเนื่อง ราคาแบบจ่ายครั้งเดียวตอบตกลงได้ง่ายกว่าและสร้างง่ายกว่าสำหรับคุณ (ไม่ต้องมีการทวงหนี้ ไม่ต้องจัดการการต่ออายุที่ล้มเหลว ไม่ต้องมีขั้นตอนการยกเลิก) ส่วนการสมัครสมาชิกคือการเดิมพันว่าคุณจะพัฒนาสิ่งนี้ต่อไปมากพอที่ผู้คนจะไม่เลิกใช้ — ซึ่งเป็นความมุ่งมั่นจริง ไม่ใช่แค่ช่องติ๊กบนหน้าราคา ถ้าคุณไม่แน่ใจว่าจะยังทำงานกับสิ่งนี้อย่างจริงจังในอีกหกเดือนข้างหน้า ราคาจ่ายครั้งเดียวคือข้อเสนอที่ซื่อตรงกว่า คุณสามารถเพิ่มระดับการสมัครสมาชิกทีหลังได้เมื่อมีอะไรที่ต่อเนื่องให้สมัครสมาชิกจริงๆ

อีกเรื่องหนึ่งแล้วผมจะปล่อยให้คุณกลับไปทำงาน: ใส่นโยบายการคืนเงินและยกเลิกที่แท้จริงลงในหน้าเว็บก่อนที่จะรับเงินดอลลาร์แรก แม้จะเป็นแค่สามประโยคก็ตาม ไม่ใช่เพราะจะมีใครฟ้องคุณเรื่องการเรียกเก็บเงิน $9 แต่เพราะการเขียนมันบังคับให้คุณตัดสินใจจริงๆ และ "เดี๋ยวค่อยคิดตอนมีคนถาม" คือวิธีที่ทำให้คุณลงเอยด้วยการตัดสินใจเชิงนโยบายท่ามกลางอีเมลโกรธเกรี้ยว แทนที่จะเป็นช่วงบ่ายที่สงบ

ไปเชื่อมต่อแซนด์บ็อกซ์ก่อนเลย ส่งข้อความหาผมเมื่อคุณลองใช้บัตรปลอมที่ถูกปฏิเสธผ่านระบบแล้ว — นั่นแหละคือความหมายของ "มันใช้งานได้" ที่สำคัญจริงๆ