ทางเลือก / White-label
มองหาทางเลือกแทน white-label payment gateway
White-label มีความหมายต่างกันมาก ขึ้นอยู่กับว่าใครขาย บางเจ้าคือช่องใส่โลโก้บน checkout บางเจ้าคือธุรกิจชำระเงินทั้งธุรกิจที่คุณดำเนินการเอง ช่องว่างระหว่างสองแบบนี้คือคุณค่าส่วนใหญ่ และแทบไม่เคยเห็นในเดโม นี่คือคำถามที่ทำให้เห็นความต่าง
ประเมิน
หกคำถามที่เผยความแตกต่าง
พื้นผิวที่เป็นของคุณจริงๆ มีมากแค่ไหน?
หน้าชำระเงิน back office ของร้านค้า คอนโซลของผู้ดูแล อีเมล ใบเสร็จ และโดเมนที่ทั้งหมดนี้อยู่ สิ่งใดที่ยังมีชื่อผู้ขายอยู่ คือจุดที่ร้านค้าของคุณจะรู้ว่าใครเป็นผู้ดำเนินการจริง
เป็นแบบ multi-merchant หรือบัญชีเดียวที่มีบัญชีย่อย?
แพลตฟอร์มที่สร้างเป็น multi-merchant ตั้งแต่แรกให้คุณทั้งการ onboarding การแบ่งระดับ สิทธิ์การใช้งาน และการแยกข้อมูล ส่วนแพลตฟอร์มที่ดัดแปลงมาจากผลิตภัณฑ์ร้านค้าเดียว ให้สิ่งเหล่านี้เป็นแค่โรดแมป
สร้างราคาของคุณเองได้ไหม?
แยกได้ทั้งรายร้านค้า รายช่องทางชำระเงิน รายสกุลเงิน รายช่วงปริมาณธุรกรรม และกำหนดวิธีจัดการรายการที่ไม่สำเร็จได้ต่างกัน ถ้าราคาเป็นตารางตายตัว โมเดลธุรกิจของคุณก็เป็นของผู้ให้บริการ ไม่ใช่ของคุณ
ขอบเขต PCI ตกอยู่กับใคร?
บน SaaS ส่วนที่รับส่งข้อมูลบัตรควรเป็นของผู้ให้บริการ และส่งต่อให้ร้านค้าของคุณ แต่ถ้าติดตั้งบนโครงสร้างพื้นฐานของคุณเอง ภาระนี้จะย้ายมาที่คุณ ทั้งสองแบบใช้ได้ แต่คุณต้องรู้ว่ากำลังซื้อแบบไหน
นำ acquirer ของคุณเองมาใช้ได้ไหม?
ความสัมพันธ์และเรตที่คุณมีอยู่แล้วมักเป็นเหตุผลที่ธุรกิจคุณไปต่อได้ แพลตฟอร์มที่ route ไปยังช่องทางของตัวเองเท่านั้น เป็นข้อเสนอที่แตกต่างและเล็กกว่ามาก
SaaS อย่างเดียว หรือใช้โครงสร้างพื้นฐานของคุณเองได้?
หากหน่วยงานกำกับดูแลหรือคณะกรรมการความเสี่ยงต้องการให้ระบบอยู่ภายในเครือข่ายของคุณในที่สุด ควรรู้ตั้งแต่ตอนนี้ว่าทำได้หรือไม่ ไม่ใช่หลังจากย้ายฐานร้านค้าไปแล้ว
สิ่งที่คุณซื้อจริง ๆ
ไม่ใช่แค่ checkout แต่เป็นธุรกิจชำระเงินที่คุณดำเนินการได้จริง นั่นหมายถึงวงจรชีวิตของร้านค้า (onboarding, เอกสาร, การแบ่งระดับ, สิทธิ์การใช้งาน, การย้ายฐานร้านค้าเดิม) ส่วนของเงิน (การคำนวณค่าธรรมเนียม, settlement, rolling reserve, reconciliation, statement) งานปฏิบัติการ (บทบาท, สิทธิ์, audit, คิว, tracing) และงานวิศวกรรมเบื้องหลังที่ต้องทันสมัยอยู่เสมอเมื่อ scheme mandate ใหม่มีผลบังคับ หากแพลตฟอร์มขาดข้อใดข้อหนึ่ง คุณต้องสร้างเอง ซึ่งเป็นสิ่งที่คุณพยายามหลีกเลี่ยงตั้งแต่แรก
- 01วงจรชีวิตของร้านค้าทั้งระบบ ไม่ใช่แค่หน้าชำระเงิน
- 02การคำนวณค่าธรรมเนียมและ settlement ที่เป็นไปตามราคาของคุณ
- 03คอนโซลสำหรับผู้ดูแลระบบ พร้อมบทบาท audit และ tracing
- 04มีคนอื่นรับภาระ scheme mandate และการรับรองมาตรฐานแทนคุณ
คำถามที่มักได้คำตอบช้าเกินไป
การย้ายฐานร้านค้าเดิม บัตรที่บันทึกไว้ย้ายเป็น token ได้หรือไม่ สถานะ PCI ของคุณเป็นอย่างไรในแต่ละรูปแบบการติดตั้ง และใครจะสร้าง connector ที่คุณต้องการแต่ยังไม่มี ไม่มีข้อใดปรากฏในการ demo แต่ทุกข้อเป็นตัวตัดสินว่าแพลตฟอร์มจะเวิร์กกับคุณในปีที่สองหรือไม่ และผู้ให้บริการที่จริงจังควรตอบทุกข้อได้อย่างเป็นรูปธรรมก่อนคุณเซ็นสัญญา
- 01ฐานร้านค้าเดิมย้ายมาอย่างไร และใช้เวลานานเท่าไร
- 02บัตรที่บันทึกไว้ย้ายเป็น token หรือต้องเริ่มใหม่
- 03ใครสร้างและรับรอง connector ที่คุณต้องการ
- 04สถานะ PCI ของคุณจะเป็นอย่างไรในแต่ละรูปแบบการติดตั้ง
Protocore อยู่ตรงไหน
แพลตฟอร์ม white-label ของเราตอบหกคำถามนั้นดังนี้: ไม่มีหน้าจอใดแสดงชื่อ Protocore; รองรับหลายร้านค้าตั้งแต่บรรทัดแรก พร้อม onboarding การแบ่งระดับ และสิทธิ์การใช้งาน; ค่าธรรมเนียมคำนวณตามที่กำหนด ไม่ใช่ตายตัว; ส่วนที่รับส่งข้อมูลบัตรเป็นของเราบน SaaS และเป็นของคุณแบบ on-premises; acquirer ของคุณเชื่อมต่อควบคู่กับของเรา และรายใหม่เราสร้างให้เป็นส่วนหนึ่งของโครงการ; และติดตั้งได้ทั้งแบบ SaaS บนคลาวด์ของคุณ หรือ on-premises ทีมที่ตอบคุณเมื่อ settlement ผิดปกติคือทีมที่เขียนระบบนี้เอง เราเป็น product studio ซึ่งเป็นความหมายที่ตรงไปตรงมาของคำว่า “dedicated support”
- 01แบรนด์ของคุณครอบคลุมทุกส่วน รวมถึงโดเมน
- 02รองรับหลายร้านค้าโดยออกแบบ พร้อมวงจรชีวิตครบถ้วน
- 03acquirer ของคุณ ราคาของคุณ การติดตั้งของคุณ
- 04วิศวกรผู้ดูแลแพลตฟอร์ม ติดต่อได้จริง
FAQ
คำถามที่ควรถามทุกเจ้า
หน้าชำระเงิน back office ของร้านค้า และคอนโซลผู้ดูแลระบบ ภายใต้แบรนด์และโดเมนของคุณ รวมถึง onboarding ร้านค้า ราคาของคุณเอง และ settlement หากส่วนใดยังแสดงชื่อผู้ให้บริการ หรือบังคับใช้โมเดลธุรกิจของผู้ให้บริการ นั่นเป็นเพียง checkout ที่เปลี่ยนแบรนด์ ไม่ใช่แพลตฟอร์ม white-label
คุณต้องมีตามที่ตลาดของคุณกำหนดสำหรับธุรกิจที่คุณทำ ผู้ให้บริการซอฟต์แวร์ไม่ใช่ฝ่ายที่ถูกกำกับดูแล ผู้ให้บริการส่วนใหญ่ใช้ acquiring ของตัวเองหรือ acquirer ที่ได้รับการแนะนำ ควรถามให้ชัดว่าผู้ให้บริการอยู่ในเส้นทางการไหลของเงินหรือไม่ เพราะคำตอบจะเปลี่ยนไป
ควรทำได้แบบเป็นชุดใหญ่ โดยบัตรที่บันทึกไว้ย้ายเป็น token และทั้งสองแพลตฟอร์มทำงานคู่ขนานจนกว่าระบบเก่าจะ settle เสร็จ ขอแผนการย้ายก่อนเซ็นสัญญา ผู้ให้บริการที่ไม่เคยทำจะอธิบายได้แค่ในเชิงนามธรรม
เลือก SaaS เว้นแต่มีเหตุเฉพาะที่บังคับเป็นอย่างอื่น เช่น หน่วยงานกำกับดูแล ธนาคาร หรือคณะกรรมการความเสี่ยงที่ต้องการให้ระบบอยู่ภายในเครือข่ายของคุณ On-premises ย้ายขอบเขต PCI และภาระปฏิบัติการมาที่คุณ ซึ่งเป็นต้นทุนจริงที่ควรจ่ายเมื่อจำเป็นเท่านั้น
ดูแพลตฟอร์มในแบรนด์ของคุณ
Walkthrough แพลตฟอร์มที่ใช้งานจริง พร้อมอัตลักษณ์ของคุณบน checkout และคอนโซล และความเห็นตรงไปตรงมาเรื่องการย้ายและเศรษฐศาสตร์เทียบกับปริมาณธุรกรรมของคุณ