การเรียกเก็บเงินตามการใช้งานไม่ใช่เรื่องใหม่ แต่ผลิตภัณฑ์ปัญญาประดิษฐ์ (AI) ได้ผลักดันให้การเรียกเก็บเงินตามการใช้งานไปถึงจุดที่กระบวนการมาตรฐานเดิมไม่เพียงพออีกต่อไป ความแปรปรวนของโทเค็น, การทำงานแบบวนลูปของเอเจนต์ที่กระจายไปเป็นการเรียกใช้งานปลายทางจำนวนหลายร้อยครั้ง, และเวิร์กโหลดที่สามารถพุ่งสูงขึ้นภายในไม่กี่นาทีล้วนสร้างปัญหาทางวิศวกรรมสำหรับการระบุแหล่งที่มาของเหตุการณ์, ความถูกต้องของการวัดปริมาณ, และการควบคุมต้นทุนที่การเรียกเก็บเงินแบบอินเทอร์เฟซการเขียนโปรแกรมแอปพลิเคชัน (API) แบบดั้งเดิมไม่เคยต้องแก้ไขมาก่อน ในความเป็นจริงแล้ว 46% ของผู้นำด้านไอทีระบุว่าการค่าบริการที่ไม่สามารถคาดการณ์ได้เป็นอุปสรรคหลักต่อการนำ AI ช่วยสร้างไปใช้ในองค์กรของตน

ด้านล่างนี้ เราจะอธิบายวิธีการนำระบบการเรียกเก็บเงินตามการใช้งานไปปรับใช้สำหรับบริการ AI วิธีเปลี่ยนเหตุการณ์ดิบให้กลายเป็นยอดที่เรียกเก็บเงินได้อย่างชัดเจน และวิธีเพิ่มมาตรการควบคุมเพื่อป้องกันค่าใช้จ่ายที่พุ่งสูงเกินควบคุมก่อนที่จะกลายเป็นการโต้แย้งเกี่ยวกับใบแจ้งหนี้

ไฮไลต์

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

• การกำจัดข้อมูลซ้ำ, นโยบายสำหรับเหตุการณ์ที่มาถึงล่าช้า, การแก้ไขและการจัดการเวอร์ชันของกฎคือสิ่งที่แยกระหว่างระบบที่สามารถสร้างใบแจ้งหนี้ที่เชื่อถือได้ออกจากระบบที่ในที่สุดจะนับซ้ำบางอย่าง ความแน่นอนและ Idempotency ไม่ใช่สิ่งที่ละเลยได้

• การควบคุมต้นทุนต้องฝังอยู่ในเลเยอร์การทำงานตั้งแต่ต้น การสำรองเครดิต กลไกตัดวงจรสำหรับลูปของเอเจนต์ และการตรวจจับความผิดปกติต้องเปิดใช้งานก่อนที่การใช้งานจะถูกสร้างขึ้น

การเรียกเก็บเงินตามการใช้งานสำหรับบริษัท AI คืออะไร

การเรียกเก็บเงินตามการใช้งานจะเรียกเก็บเงินจากลูกค้าตามสัดส่วนของสิ่งที่ใช้ไป (เช่น โทเค็นที่ประมวลผลแล้ว วินาทีการประมวลผล การเรียกใช้ API การดำเนินการของเอเจนต์) แทนที่จะเป็นค่าธรรมเนียมคงที่

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

การเรียกเก็บเงินตามการใช้งานมีหลักการทำงานอย่างไรสำหรับบริษัท AI

ในระดับสูง ระบบจะย้ายจากการดำเนินการที่เรียกเก็บเงินได้ในผลิตภัณฑ์ของคุณไปยังบรรทัดรายการในใบแจ้งหนี้ของลูกค้า แต่ละขั้นตอนมีโหมดความล้มเหลวของตนเอง ซึ่งจะซับซ้อนขึ้นหากไม่ได้รับการออกแบบมาอย่างดี

ต่อไปนี้คือขั้นตอนต่างๆ และวิธีการทำงาน

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

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

• การวัดปริมาณ: เหตุการณ์ดิบจะรวมเป็นปริมาณที่สามารถเรียกเก็บเงินได้ภายในรอบการเรียกเก็บเงิน โดยเลเยอร์นี้จะทำการบังคับใช้คำจำกัดความของหน่วย ตรรกะค่าบริการ และกฎการรวมอย่างสม่ำเสมอ

• ใบแจ้งหนี้: ผลรวมที่วัดได้จะส่งผ่านไปยังระบบการเรียกเก็บเงินของคุณ ซึ่งจะสร้างบรรทัดรายการในใบแจ้งหนี้ ใช้เครดิตหรือส่วนลด และเรียกเก็บเงินลูกค้า

แต่ละเลเยอร์ควรมีความถูกต้องในตัวเองอย่างเป็นอิสระ คุณคงไม่อยากไปพบปัญหาในขั้นตอนการนำเข้าเมื่อเห็นความคลาดเคลื่อนของรายรับในอีกหลายสัปดาห์ถัดมา

พฤติกรรมเฉพาะของ AI ใดที่ทำให้การเรียกเก็บเงินตามการใช้งานนำมาปฏิบัติจริงได้ยากขึ้น

API แบบเดิมจะใช้การแมปที่เรียบง่าย คือ 1 คำขอสร้าง 1 การตอบสนอง และ 1 เหตุการณ์ที่เรียกเก็บเงินได้ แต่ปริมาณงานของ AI ไม่ได้เป็นเช่นนั้น

ต่อไปนี้คือสิ่งที่ทำให้พฤติกรรมเฉพาะของ AI นำมาปฏิบัติจริงได้ยากขึ้นสำหรับการเรียกเก็บเงินตามการใช้งาน:

ลูปเอเจนต์และการกระจายการเรียกใช้เครื่องมือ

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

ความแปรปรวนของโทเค็น

โทเค็นข้อมูลเข้าและออกมีต้นทุนต่างกันและไม่สามารถคาดเดาได้ล่วงหน้า คำขอที่มีข้อความแจ้งเตือนความยาว 200 โทเค็นอาจส่งคืน 50 โทเค็นหรือหลายพันโทเค็น โดยจะขึ้นอยู่กับงาน การตั้งค่าโมเดล และพฤติกรรมการสร้าง คุณจะไม่สามารถเรียกเก็บเงินล่วงหน้าตามขนาดคำขอได้ คุณต้องส่งเหตุการณ์ออกไปหลังจากดำเนินการเสร็จสิ้นพร้อมจำนวนที่แน่นอน

ปริมาณงานที่ไม่สม่ำเสมอ

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

ต้นทุนที่ไม่สามารถคาดเดาได้

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

ต้นทุนที่ไม่สามารถคาดเดาได้

ข้อความแจ้งเดียวกันอาจให้จำนวนโทเค็นที่แตกต่างกันในการเรียกใช้แต่ละครั้ง โดยเฉพาะอย่างยิ่งกับการสตรีมมิง การเรียกใช้ฟังก์ชัน หรือเครือข่ายเอเจนต์

สัญญาของเหตุการณ์การใช้งานที่เชื่อถือได้สำหรับบริษัท AI มีหน้าตาอย่างไร

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

สัญญาของเหตุการณ์การใช้งานที่เชื่อถือได้มีองค์ประกอบดังนี้

• ตัวระบุลูกค้าและโปรเจกต์: ID ที่เสถียรและเปลี่ยนแปลงไม่ได้ ซึ่งจะไม่เปลี่ยนแปลงเมื่อลูกค้าเปลี่ยนชื่อองค์กรหรือปรับโครงสร้างลำดับชั้นบัญชี

• การประทับเวลาของการดำเนินการ: เวลาที่การดำเนินการเกิดขึ้นจริง ไม่ใช่เวลาที่ส่งเหตุการณ์ออกไป ไปป์ไลน์แบบอะซิงโครนัสอาจทำให้เกิดความล่าช้าซึ่งมีผลต่อการกำหนดช่วงเวลา

• หน่วยและปริมาณ: สิ่งที่คุณวัด (เช่น โทเค็นขาเข้า โทเค็นขาออก และวินาทีในการคำนวณ) และปริมาณที่ใช้ ให้คงหน่วยให้เป็นหน่วยย่อยแยกกัน เว้นแต่ค่าบริการของคุณจะปฏิบัติต่อหน่วยเหล่านั้นเหมือนกัน

• ID ความสัมพันธ์: ตัวระบุที่ไม่ซ้ำกันซึ่งเชื่อมโยงเหตุการณ์การใช้งานกลับไปยังคำขอ เซสชัน หรือการทำงานของเอเจนต์ต้นทาง การดำเนินการนี้ทำให้คุณสามารถติดตามบรรทัดรายการในใบแจ้งหนี้ย้อนกลับไปยังบันทึกการทำงานของแอปพลิเคชันได้

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

• เวอร์ชันสคีมา: เมื่อโมเดลค่าบริการเปลี่ยนแปลง เหตุการณ์เก่าและใหม่ต้องอยู่ร่วมกันได้ การกำหนดเวอร์ชันจะทำให้เป็นไปได้

บริษัท AI ควรออกแบบการนำเข้าและจัดเก็บข้อมูลสำหรับการเรียกเก็บเงินตามการใช้งานอย่างไร

ข้อกำหนด 2 ประการที่มีความสำคัญเหนือเลเยอร์นี้ ได้แก่ ความน่าเชื่อถือและความไม่เปลี่ยนแปลง ส่วนสิ่งอื่นๆ (ปริมาณงาน ความหน่วง การตรวจสอบสคีมา) จะทำหน้าที่สนับสนุนเป้าหมายเหล่านั้น

วิธีที่บริษัท AI ควรออกแบบการนำเข้าและจัดเก็บข้อมูลมีดังนี้

ความน่าเชื่อถือ

เขียนไปยังระบบคิวแบบทนทานที่มีลักษณะการส่งแบบ “การจัดส่งอย่างน้อยหนึ่งครั้ง” ระบบคิวจะช่วยป้องกันคุณจากความล้มเหลวชั่วคราว ส่วนลูกค้าปลายทางจะจัดการการกำจัดข้อมูลซ้ำเอง อย่าเขียนเหตุการณ์การใช้งานจากแอปพลิเคชันของคุณลงฐานข้อมูลโดยตรง

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

ออกแบบระบบให้รองรับการใช้งานที่พุ่งสูงเป็นช่วงๆ อย่างชัดเจน การจัดสรรทรัพยากรสำหรับการนำเข้าข้อมูลที่ไม่เพียงพอมักจะล้มเหลวโดยทำให้เหตุการณ์สูญหาย

ความไม่เปลี่ยนแปลง

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

บริษัท AI เปลี่ยนเหตุการณ์การใช้งานดิบเป็นข้อมูลสรุปสำหรับเรียกเก็บเงินที่ถูกต้องได้อย่างไร

การวัดปริมาณคือจุดที่ความแม่นยำเป็นกุญแจสำคัญ เมื่อมีเหตุการณ์อินพุตและกฎชุดเดียวกัน ผลลัพธ์ที่ได้จะต้องเหมือนเดิมทุกครั้ง

คุณสมบัติ 4 ประการที่ทำให้เป็นไปได้มีดังนี้

• การกำจัดข้อมูลซ้ำและ Idempotency: “การส่งแบบอย่างน้อยหนึ่งครั้ง” จะทำให้เกิดข้อมูลซ้ำอย่างแน่นอน Idempotency นี้ (ซึ่งผลลัพธ์ของการดำเนินการจะให้ผลลัพธ์เดียวกัน) หมายความว่าทุกเหตุการณ์ต้องมีรหัสเฉพาะ และกระบวนการรวมข้อมูลต้องกำจัดข้อมูลซ้ำก่อนนำไปนับ หากไม่มีคุณสมบัตินี้ ความเสี่ยงของการเรียกเก็บเงินซ้ำจะสูงขึ้นอย่างมาก

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

• เหตุการณ์การแก้ไข: เมื่อเกิดข้อผิดพลาด ให้ส่งเหตุการณ์แก้ไขที่ปรับยอดรวม อ้างอิงถึงเหตุการณ์ต้นฉบับ และอธิบายเหตุผลที่มีการเปลี่ยนแปลง ห้ามเขียนทับข้อมูลสรุปในอดีต

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

เครื่องมืออย่าง Stripe Billing ช่วยจัดการการรวมข้อมูลในฝั่งใบแจ้งหนี้ แต่เลเยอร์การวัดปริมาณภายในของคุณควรสร้างข้อมูลสรุปของตัวเองอย่างเป็นอิสระ ข้อมูลเหล่านี้จะกลายเป็นแหล่งข้อมูลหลักสำหรับการกระทบยอด

บริษัท AI ใช้มาตรการควบคุมในการควบคุมต้นทุนอย่างไร

ภาระงานของ AI สามารถก่อให้เกิดค่าใช้จ่าย (ทั้งของคุณและของลูกค้า) ได้รวดเร็วกว่าที่มนุษย์คนใดจะเข้าไปแทรกแซงได้ มาตรการควบคุมจึงต้องทำงานแบบเรียลไทม์

นี่คือวิธีที่บริษัท AI ใช้มาตรการควบคุมเพื่อป้องกันค่าใช้จ่ายที่พุ่งสูงเกินควบคุม:

บัญชีเครดิตและการสำรองเครดิต

ก่อนดำเนินการดำเนินการที่ก่อให้เกิดการใช้งาน ให้กันวงเงินต้นทุนที่คาดการณ์ไว้จากยอดคงเหลือของลูกค้า หากการกันวงเงินล้มเหลว ก็ไม่ควรดำเนินการนั้น หลังจากดำเนินการแล้ว ให้ชำระเงินตามการใช้งานจริง วิธีนี้คล้ายกับการอนุมัติล่วงหน้าของบัตรเครดิต และเป็นโมเดลความคิดที่เหมาะสมสำหรับการเรียกเก็บเงินของ AI

ขีดจำกัดแบบยืดหยุ่นและขีดจำกัดแบบตายตัว

ขีดจำกัดแบบตายตัวจะหยุดการใช้งานทันที ขีดจำกัดแบบยืดหยุ่นจะส่งการแจ้งเตือนเมื่อเข้าใกล้เกณฑ์ที่กำหนด ทั้ง 2 แบบควรสามารถตั้งค่าได้แยกตามลูกค้าและตามโปรเจกต์ ภาระงานในระบบใช้งานจริงและบัญชีทดลองจะมีระดับความยืดหยุ่นที่แตกต่างกัน

กลไกตัดวงจรสำหรับภาระงานของเอเจนต์

เอเจนต์ต้องการการจัดการเป็นพิเศษ กำหนดจำนวนขั้นตอนสูงสุด ค่าใช้จ่ายสูงสุดต่อเซสชัน และกลไกหยุดอัตโนมัติ ให้บังคับใช้วิธีเหล่านี้ในขณะดำเนินการ ไม่ใช่หลังจากการเรียกเก็บเงิน เพราะเมื่อระบบเรียกเก็บเงินเห็นเหตุการณ์แล้ว ค่าใช้จ่ายก็เกิดขึ้นไปแล้ว

การตรวจจับความผิดปกติ

ติดตามอัตราการใช้งานของลูกค้าแต่ละราย และตั้งค่าสถานะเตือนเมื่อมีการเบี่ยงเบนเกินกว่าค่าที่กำหนด (เช่น 0.1 ดอลลาร์สหรัฐต่อหน่วย) การหยุดการทำงานอัตโนมัติที่มีคิวการตรวจสอบโดยมนุษย์มักเป็นแนวทางที่เหมาะสม เป้าหมายคือการตรวจจับขั้นตอนที่หลุดการควบคุมก่อนที่จะกลายเป็นการโต้แย้ง หรือก่อให้เกิดต้นทุนขาย (COGS) ที่ไม่คาดคิด

Stripe Billing ช่วยอะไรได้บ้าง

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

Stripe Billing ช่วยคุณทำสิ่งต่อไปนี้ได้

• เสนอการตั้งราคาที่ยืดหยุ่น: ตอบสนองต่อความต้องการของผู้ใช้ได้เร็วขึ้นด้วยโมเดลการตั้งราคาที่ยืดหยุ่น ซึ่งมีทั้งแบบตามการใช้งาน แบ่งระดับ ค่าธรรมเนียมคงที่บวกค่าธรรมเนียมส่วนเกิน และอีกมากมาย ทั้งยังรองรับคูปอง การทดลองใช้งานฟรี การแบ่งชำระตามสัดส่วน และส่วนเสริมอีกด้วย

• ขยายไปทั่วโลก: เพิ่มอัตราการเปลี่ยนเป็นผู้ใช้แบบชำระเงินด้วยการเสนอวิธีการชำระเงินที่ลูกค้าต้องการ นอกจากนี้ Stripe ยังรองรับวิธีการชำระเงินในแต่ละประเทศมากกว่า 100 วิธีและกว่า 130 สกุลเงิน

• เพิ่มรายรับและลดอัตราการเลิกใช้บริการ: ให้คุณเก็บรายรับได้มากขึ้นและลดการเลิกใช้บริการโดยไม่สมัครใจด้วย Smart Retries และระบบอัตโนมัติสำหรับกระบวนการกู้คืน เครื่องมือการกู้คืนของ Stripe ช่วยให้ผู้ใช้สามารถกู้คืนรายรับกว่า 6.5 พันล้านดอลลาร์ได้ในปี 2024\

• เพิ่มประสิทธิภาพ: ใช้เครื่องมือภาษีแบบโมดูลาร์ รายงานรายรับ และเครื่องมือข้อมูลของ Stripe เพื่อรวมระบบรายรับหลายระบบให้เป็นหนึ่งเดียว พร้อมผสานการทำงานกับซอฟต์แวร์ของบริษัทอื่นได้อย่างง่ายดาย

ดูข้อมูลเพิ่มเติมเกี่ยวกับ Stripe Billing หรือเริ่มใช้งานเลยวันนี้