สรุปสิ่งที่ชอบจากที่ได้อ่านบทความ Stripe’s payments APIs: the first ten years ของ Stripe ซึ่งเป็นบริษัทที่ให้บริกการ Payment API ซึ่งได้เรียนรู้หลายๆเรื่องมากเกี่ยวกับการออกแบบ API และวิวัฒนาการของ Payment API
Stripe เป็นบริษัทที่ให้บริการ Payment API ในช่วงเปิดตัวแรกๆที่รองรับแค่ API สำหรับจ่ายผ่านบัตรเครดิตนั้นถือว่าเปิดตัวได้ดีมากในมุมมองของคนใช้งาน คือ API นั้นใช้ง่าย เรียกใช้โค้ดแค่ไม่กี่บรรทัดก็สามารถตัดบัตรจ่ายเงินได้แล้ว
แต่ความเรียบง่ายนั้นก็ซ่อนด้วยความซับซ้อนและเรื่องราวน่าเรียนรู้อีกมากมายในการเป็นธุรกิจให้บริการ API ของ Stripe ในช่วง 10 ปีที่ผ่านมา
ผมจะสรุปจุดน่าสนใจที่ผมชอบจากบทความนี้ไว้ดังนี้
เมื่อวิธีการจ่ายเงินไม่ได้มีแค่ credit card
เริ่มแรก API มีแค่สำหรับจ่ายเงินผ่านบัตรเครดิต ซึ่งการทำงานก็แค่กรอกข้อมูลบัตร ส่งข้อมูลไปตัดกับ card network รับ response ว่าตัดสำเร็จหรือไม่แล้วก็ตอบกลับหาคนเรียกใช้ API แล้วก็จบ ร้านค่าก็ไปจัดการของส่งของทำเรื่องต่างๆหลังจากรู้ว่าตัดเงินได้แล้วต่อได้
แต่เมื่อ Stripe เริ่มรับจ่ายอย่างอื่นได้ด้วย สิ่งที่ตัดสินใจทำคือพยายามให้วิธีตัดบัตรอื่นๆ ยังใช้งานง่ายๆด้วย API แบบเดิมของ credit card ที่ประกอบด้วยการสร้าง Token แล้วเอาไปสร้าง Charge
แม้ต่อมาจะพยายามแก้ปัญหาด้วยการรวบให้เหลือแค่คอนเซ็ปของ Source กับ Charge แล้วก็ตาม ก็ต้องพบกับว่า Source กับ Charge นั้นมี state ที่ยุบยับเต็มไปหมดเพราะต้องใช้กับ payment method หลายแบบที่ flow ไม่เหมือนกัน
ปิดห้อง 3 เดือนหาวิธีทำให้ API กลับมาเรียบง่าย พร้อมรองรับการเพิ่มจำนวนวิธีการจ่ายเงิน
Stripe ไม่อยากให้เป็นแบบนี้ต่อไป เลยต้องรวบรวมทีม คิดกันว่าจะให้ API เป็นยังไงถึงทำให้รองรับการเติมโตของวิธีการจ่าย และยังคงใช้งานได้ง่ายอยู่ ใช้เวลาถึง 3 เดือนเพื่อคิดและออกแบบ จนได้วิธีใหม่มาที่ประกอบด้วย PaymentMethods และ PaymentIntents ตลอด 3 เดือนวิธีการพูดคุยคือ
- ต้องปิดคอมตอนคุย
- ในแต่ละครั้งต้องเตรียมคำถามที่จะมาช่วยกันหาคำตอบล่วงหน้า
- ถ้ามีคำถามใหม่ให้จดไว้ก่อน ไปรวบรวมข้อมูลกันมาก่อนค่อยตอบครั้งหน้า อย่ายกมาคุยเลยทันที
- ใช้สีและรูปทรงแทนอะไรที่มันซับซ้อนไปก่อนจะได้ไม่ต้องไปลงรายละเอียดกันมากทันที
- ต้องโฟกัสที่การเชื่อมต่อของคนใช้งาน API ในสถานการณ์จริงๆตลอด สิ่งที่คิดกันต้องไม่ทำให้การเชื่อมต่อในสถานการณ์จริงเป็นไปได้ยาก
- พยายามตั้งคำถามกับ API เดิมว่าทำไมหรือมีหลักคิดยังไงทำไมถึงออกแบบไปแบบนั้น เพื่อให้เป็นหลักคิดในการออกแบบ API ใหม่
- ชวนคนที่เป็นผู้เชี่ยวชาญในด้านที่ไม่รู้แต่จำเป็นต้องรู้ข้อมูลเพื่อใช้ในการออกแบบมาเป็นที่ปรึกษา
- พยายามตัดสินใจให้เร็ว และรู้เอาไว้ว่าสิ่งที่ตัดสินใจไปแล้ว ถ้ามีข้อมูลใหม่ๆมา ต้องเปลี่ยนได้
A great API product stays out of the developer’s way for as long as possible.
API เป็นสิ่งที่เมื่อมีการเปลี่ยนแปลง จะกระทบกับคนในวงกว้าง เพราะถูกเอาไปเชื่อมต่อ เพื่อพัฒนาระบบอื่นๆแล้วจำนวนมาก API ที่ดีควรจะยังคงใช้งานได้และไม่หยุดให้บริการโดยทันที ในเคสนี้ Stripe ก็ใช้เวลาและความพยายามเพื่อค่อยๆเปลี่ยนโดยกระทบคนที่ใช้งานเดิมให้น้อยที่สุด
An API product is more than just the API
การสร้าง API เพื่อใช้งานนั้นไม่ยาก เพราะอาจจะมีแค่คนใช้งานไม่กี่คนคือทีม front-end แต่เมื่อเป็น API product นั้นมีเรื่องที่ต้องจัดการนอกเหนือจาก API อีกจำนวนมาก ไม่ว่าจะเป็น
- document ที่ต้องปรับปรุงเสมอให้อ่านเข้าใจง่าย ค้นหาง่าย
- เครื่องมือช่วยอื่นๆ เพื่อให้คนที่ทำระบบมาเชื่อมต่อทำได้ง่ายๆ
- community ต้องสร้าง community ของผู้ใช้งานให้ช่วยเหลือกัน แลกเปลี่ยนข้อมูลกัน
- และสุดท้าย Payment API นอกจาก API แล้วเรื่องหลังบ้านทางด้านการเงินยังมีอีกเยอะมาก ยิ่งเชื่อมต่อหลาย Payment method ก็ยิ่งต้องจัดการกับหลากหลาย partners เยอะมากๆ
Top comments (0)