ในปี 2024 การละเมิดการรักษาความปลอดภัยทั่วโลก 35.5% เชื่อมโยงกับบุคคลที่สาม ผลลัพธ์ของการละเมิดประเภทนี้อาจแย่ลงเมื่อคุณทำงานร่วมกับผู้ประมวลผลการชำระเงิน นั่นเป็นเหตุผลว่าทำไมการรักษาความปลอดภัยและการปฏิบัติตามข้อกำหนดจึงไม่สามารถต่อรองได้ในคำขอข้อเสนอ (RFP) สำหรับการชำระเงิน RFP ของคุณควรขอให้ผู้ให้บริการชำระเงินที่มีศักยภาพระบุถึงวิธีการที่พวกเขาปกป้องข้อมูลที่ละเอียดอ่อน ความเร็วที่พวกเขารับมือกับเหตุการณ์ และวิธีที่จะช่วยให้ธุรกิจของคุณปฏิบัติตามข้อกำหนดทางกฎหมาย
คุณต้องถามคำถามที่ถูกต้องตั้งแต่แรกและขอคำตอบพร้อมหลักฐาน ด้านล่างนี้ เราจะพูดถึงแนวทางปฏิบัติที่ดีที่สุดในการถามเกี่ยวกับการรักษาความปลอดภัยและการปฏิบัติตามข้อกำหนดใน RFP สำหรับการชำระเงิน
เนื้อหาหลักในบทความ
- ข้อกำหนดด้านการรักษาความปลอดภัยและการปฏิบัติตามข้อกำหนดที่ควรระบุในแต่ละ RFP สำหรับการชำระเงินมีอะไรบ้าง
- ฉันจะเขียนข้อกำหนด PCI DSS ลงใน RFP สำหรับการชำระเงินได้อย่างไร
- คำถามพื้นฐานเกี่ยวกับการคุ้มครองข้อมูลและความเป็นส่วนตัวที่คุณควรถามผู้ให้บริการมีอะไรบ้าง
- ฉันจะประเมินการป้องกันการฉ้อโกงของผู้ให้บริการใน RFP ได้อย่างไร
- ผู้ให้บริการควรให้รายละเอียดการรับมือกับเหตุการณ์และการกู้คืนจากภัยพิบัติอะไรบ้าง
- ฉันจะถามเกี่ยวกับข้อกำหนดการปฏิบัติตามข้อกำหนดทั่วโลกใน RFP ได้อย่างไร
- คุณควรร้องขอสิ่งใดจากผู้ให้บริการสำหรับการเข้ารหัส การแปลงเป็นโทเค็น และการตรวจสอบสิทธิ์
- ฉันจะระบุข้อกำหนดด้านการรักษาความปลอดภัยจากการชำระเงินผ่านอุปกรณ์เคลื่อนที่และการชำระเงินในแอปไว้ใน RFP ได้อย่างไร
- ควรขอความสามารถในการรายงานและการตรวจสอบอะไรบ้างใน RFP สำหรับการชำระเงิน
- สัญญาณเตือนใดบ้างในคำตอบ RFP ของผู้ให้บริการที่บ่งชี้ถึงการรักษาความปลอดภัยที่ไม่รัดกุมหรือการปฏิบัติตามข้อกำหนดที่ไม่เพียงพอ
- Stripe Payments ช่วยได้อย่างไร
ข้อกำหนดด้านการรักษาความปลอดภัยและการปฏิบัติตามข้อกำหนดที่ควรระบุในแต่ละ RFP สำหรับการชำระเงินมีอะไรบ้าง
เมื่อคุณจัดทำ RFP สำหรับการชำระเงิน ส่วนการรักษาความปลอดภัยและการปฏิบัติตามข้อกำหนดคือส่วนที่คุณจะกำหนดความคาดหวังพื้นฐานที่ผู้ให้บริการที่จริงจังทุกรายควรปฏิบัติตามสำหรับธุรกิจของคุณ RFP ควรบังคับให้ผู้ให้บริการแสดงให้เห็นถึงการรักษาความปลอดภัยที่เข้มงวดและผ่านการตรวจสอบจากหน่วยงานที่เป็นอิสระในทุกด้านเหล่านี้
การรับรองและการตรวจสอบในระดับอุตสาหกรรม
ขอให้ผู้ให้บริการแสดงหลักฐานการรับรองและการตรวจสอบ: มาตรฐานการรักษาความปลอดภัยของข้อมูลอุตสาหกรรมบัตรชำระเงิน (PCI DSS) สำหรับข้อมูลบัตร, องค์กรระหว่างประเทศว่าด้วยการมาตรฐาน (ISO) 27001 สำหรับการรักษาความปลอดภัยของข้อมูล และการควบคุมระบบและองค์กร (SOC) 2 ประเภท 2 สำหรับการควบคุมการปฏิบัติงาน สิ่งเหล่านี้เป็นการยืนยันว่าผู้ตรวจสอบภายนอกได้ตรวจสอบแนวทางปฏิบัติของผู้ให้บริการ
การปฏิบัติตามข้อกำหนดของ PCI DSS
กำหนดให้ผู้ให้บริการต้องปฏิบัติตามข้อกำหนดของ PCI ในระดับสูงสุดที่เกี่ยวข้อง (ระดับ 1) ขอใบรับรองการปฏิบัติตามข้อกำหนดปัจจุบันของผู้ให้บริการจากผู้ประเมินความปลอดภัยที่ผ่านการรับรองเพื่อเป็นหลักฐานอย่างเป็นทางการ
การคุ้มครองข้อมูลและความเป็นส่วนตัว
กำหนดวิธีที่ผู้ให้บริการปกป้องข้อมูลลูกค้าทั้งหมด รวมถึงรายละเอียดส่วนบุคคล ที่อยู่การเรียกเก็บเงิน และรหัสประจำตัว สอบถามว่าข้อมูลเหล่านั้นถูกจัดเก็บไว้ที่ใดในทางภูมิศาสตร์ ข้อมูลมีการเข้ารหัสอย่างไร และมีการควบคุมการเข้าถึงอย่างไร ตรวจสอบให้แน่ใจว่าผู้ให้บริการจะลงนามในข้อตกลงการประมวลผลข้อมูลและรองรับกฎหมายความเป็นส่วนตัว เช่น ข้อบังคับทั่วไปว่าด้วยการคุ้มครองข้อมูลของสหภาพยุโรป (GDPR) และกฎหมายคุ้มครองความเป็นส่วนตัวของผู้บริโภคแห่งรัฐแคลิฟอร์เนีย (CCPA)
การป้องกันการฉ้อโกง
สอบถามเกี่ยวกับความสามารถในการป้องกันการฉ้อโกงของผู้ให้บริการ ผู้ให้บริการใช้แมชชีนเลิร์นนิง กลไกกฎ และการตรวจสอบสิทธิ์แบบ 3D Secure หรือไม่ พวกเขาหาสมดุลระหว่างการหยุดการฉ้อโกงกับการรักษาอัตราการอนุมัติให้อยู่ในระดับสูงได้อย่างไร คำตอบสำหรับ RFP ของผู้ให้บริการควรทำให้คุณมั่นใจว่าพวกเขาจะช่วยลดการดึงเงินคืนและการสูญเสียจากการฉ้อโกงโดยไม่ทำให้ลูกค้าที่ชอบด้วยกฎหมายต้องหงุดหงิด
การรับมือกับเหตุการณ์และการกู้คืนจากภัยพิบัติ
ผู้ให้บริการทุกรายควรมีแผนสำหรับการละเมิดและเหตุขัดข้อง ถามว่าผู้ให้บริการจะตรวจจับและรับมือกับเหตุการณ์อย่างไร พวกเขาจะแจ้งให้คุณทราบเร็วแค่ไหนหากข้อมูลของคุณได้รับผลกระทบ และเป้าหมายการกู้คืนข้อมูลหลักเป็นอย่างไร เช่น เป้าหมายระยะเวลาการกู้คืน (RTO) หรือ เป้าหมายจุดกู้คืน (RPO)
ความครอบคลุมการปฏิบัติตามข้อกำหนดทั่วโลก
หากธุรกิจของคุณดำเนินงานในระดับสากล ผู้ให้บริการของคุณจำเป็นต้องสามารถจัดการกับระเบียบข้อบังคับในพื้นที่เพื่อให้คุณไม่ต้องเจอกับเรื่องที่ไม่คาดคิด กำหนดให้ต้องปฏิบัติตามคำสั่งว่าด้วยบริการชำระเงินฉบับปรับปรุง (PSD2) ในยุโรป การคัดกรองการคว่ำบาตรในสหรัฐอเมริกา และกฎการจำกัดข้อมูลในพื้นที่เฉพาะในประเทศต่างๆ เช่น อินเดีย
การควบคุมการรักษาความปลอดภัยของข้อมูลหลัก
ชี้แจงความคาดหวังสำหรับการเข้ารหัส การแปลงเป็นโทเค็น และการตรวจสอบสิทธิ์ ข้อมูลควรได้รับการเข้ารหัสระหว่างการส่งและขณะที่ไม่ได้ใช้งานด้วยมาตรฐานที่ทันสมัย ข้อมูลที่ละเอียดอ่อนควรได้รับการแปลงเป็นโทเค็นเพื่อไม่ให้คุณเข้าถึงข้อมูลโดยตรง และระบบของผู้ให้บริการควรบังคับใช้การตรวจสอบสิทธิ์ที่รัดกุมสำหรับผู้ใช้ภายใน
การชำระเงินผ่านอุปกรณ์เคลื่อนที่และการชำระเงินในแอป
หากธุรกิจของคุณทำงานบนอุปกรณ์เคลื่อนที่ ให้ระบุข้อกำหนดเฉพาะสำหรับสภาพแวดล้อมนั้น สอบถามเกี่ยวกับการรักษาความปลอดภัยของชุดพัฒนาซอฟต์แวร์ (SDK) ของผู้ให้บริการ และถามว่าข้อมูลที่ละเอียดอ่อนจะข้ามเซิร์ฟเวอร์ของคุณเพื่อลดขอบเขต PCI หรือไม่ และพวกเขารองรับกระเป๋าเงินดิจิทัล เช่น Apple Pay และ Google Pay อย่างไร
การรายงานและความสามารถในการตรวจสอบ
กำหนดให้ต้องมีการรายงานธุรกรรม การวิเคราะห์การฉ้อโกงและการโต้แย้งการชำระเงิน รวมถึงบันทึกการตรวจสอบระบบที่ติดตามการดำเนินการด้านการดูแลระบบ คุณควรมีสิทธิ์เข้าถึงข้อมูลของคุณมากพอที่จะสามารถดำเนินการตรวจสอบและปฏิบัติตามภาระผูกพันในการปฏิบัติตามข้อกำหนดของคุณเองได้
ฉันจะเขียนข้อกำหนด PCI DSS ลงใน RFP สำหรับการชำระเงินได้อย่างไร
PCI DSS เป็นกฎเกณฑ์สากลสำหรับข้อมูลบัตร โดย RFP ของคุณควรระบุการปฏิบัติตามข้อกำหนดของ PCI เสมือนเป็นข้อสัญญา คุณต้องขอการรับรองระดับ 1 พร้อมหลักฐานและตรวจสอบให้แน่ใจว่าผู้ให้บริการมุ่งมั่นที่จะปฏิบัติตามข้อกำหนดเมื่อมาตรฐานมีการพัฒนา
ต่อไปนี้คือวิธีตรวจสอบให้แน่ใจว่าภาษาใน RFP จะไม่ทำให้เกิดความสับสนหรือตีความผิด
ระบุอย่างชัดเจนเกี่ยวกับระดับและหลักฐาน: ระบุว่าผู้ให้บริการต้องผ่านการรับรอง PCI ระดับ 1 ซึ่งถือเป็นเครื่องยืนยันอย่างดีว่าผู้ให้บริการปฏิบัติตามข้อกำหนด
เน้นย้ำถึงการปฏิบัติตามข้อกำหนดอย่างต่อเนื่อง: สอบถามว่าผู้ให้บริการจะปรับตัวตามข้อกำหนด PCI DSS ที่เปลี่ยนแปลงไปอย่างไร คุณอาจกล่าวว่า "ยืนยันว่าคุณจะยังคงปฏิบัติตามข้อกำหนดของ PCI ตลอดอายุสัญญา และอธิบายว่าคุณจะปรับตัวให้เข้ากับ PCI DSS เวอร์ชันใหม่อย่างไร" คำตอบควรกล่าวถึงการตรวจสอบประจำปี การสแกนรายไตรมาส และการตรวจสอบอย่างต่อเนื่อง
ชี้แจงความรับผิดชอบร่วมกัน: พูดคุยเกี่ยวกับภาระผูกพันด้าน PCI ที่คุณต้องรับผิดชอบ เช่น ถามว่า "ข้อกำหนดของ PCI DSS ใดบ้างที่ยังคงเป็นความรับผิดชอบของเรา และคุณจะสนับสนุนให้เราปฏิบัติตามข้อกำหนดเหล่านั้นอย่างไร" มองหาผู้ให้บริการที่ช่วยแบ่งเบาภาระ เช่น ผู้ให้บริการที่กรอกแบบสอบถามการประเมินตนเองของ PCI ล่วงหน้าหรือให้คำแนะนำโดยละเอียด
คำถามพื้นฐานเกี่ยวกับการคุ้มครองข้อมูลและความเป็นส่วนตัวที่คุณควรถามผู้ให้บริการมีอะไรบ้าง
ชื่อ ที่อยู่ อีเมล และ ID อุปกรณ์ล้วนเป็นข้อมูลที่ละเอียดอ่อนด้วยเช่นกัน ผู้ให้บริการที่เหมาะสมจะสามารถบอกคุณได้อย่างชัดเจนว่าข้อมูลของลูกค้ามีการจัดเก็บไว้ที่ใด ได้รับการปกป้องอย่างไร เก็บไว้นานแค่ไหน และจะเกิดอะไรขึ้นหากเกิดปัญหา
ด้านล่างนี้เป็นคำถามที่คุ้มค่าที่จะถาม
ข้อมูลถูกจัดเก็บและประมวลผลที่ไหน
เขตอำนาจศาลมีความสำคัญ ขอให้ผู้ให้บริการระบุประเทศที่มีการจัดเก็บข้อมูลลูกค้า และถามว่าพวกเขาเสนอตัวเลือกการโฮสต์ระดับภูมิภาคหรือไม่ คำตอบที่โปร่งใสจะระบุชื่อสถานที่ อธิบายกรอบกฎหมายที่บังคับใช้ และอธิบายวิธีจัดการการโอนเงินข้ามพรมแดน
ข้อมูลส่วนตัวได้รับการคุ้มครองอย่างไร
การเข้ารหัส การควบคุมการเข้าถึง และการตรวจสอบควรมีการกล่าวถึงทันที สอบถามเกี่ยวกับวิธีการที่แน่นอน เช่น Advanced Encryption Standard (AES) 256 สำหรับข้อมูลที่ไม่ได้ใช้งาน, Transport Layer Security (TLS) 1.2 ขึ้นไปสำหรับข้อมูลที่อยู่ระหว่างการส่ง และการเข้าถึงตามบทบาทโดยใช้หลักสิทธิ์น้อยที่สุด ขอรายละเอียดเกี่ยวกับบันทึกการตรวจสอบว่าใครเข้าถึงบันทึกใด เมื่อใด และเพื่อวัตถุประสงค์อะไร คุณต้องขอหลักฐานยืนยันว่ามีการติดตามทุกจุดที่มีการเข้าถึงข้อมูล
คุณปฏิบัติตามกฎหมายความเป็นส่วนตัวใดบ้าง และมีสัญญาหรือเอกสารใดที่ยืนยันได้
ผู้ให้บริการควรระบุอย่างชัดเจนเกี่ยวกับ GDPR, CCPA และกฎหมายอื่นๆ ที่เกี่ยวข้อง กำหนดให้มีข้อตกลงการประมวลผลข้อมูลที่สอดคล้องกับ GDPR และหลักฐานเกี่ยวกับวิธีที่ผู้ให้บริการจัดการกับสิทธิ์ของเจ้าของข้อมูล เช่น การเข้าถึงและการลบ หากผู้ให้บริการมีใบรับรองหรือมีส่วนร่วมในกรอบการทำงานที่เป็นที่ยอมรับ คุณก็ควรนำมาพิจารณาในการประเมินด้วย
นโยบายการเก็บรักษาและการลบข้อมูลของคุณเป็นอย่างไร
ถามว่าผู้ให้บริการเก็บธุรกรรมและข้อมูลส่วนตัวไว้นานแค่ไหน และมีกระบวนการใดบ้างในการลบหรือทำให้เป็นข้อมูลไม่ระบุตัวตน มองหานโยบายที่มีโครงสร้าง เช่น กรอบเวลาเฉพาะสำหรับการเก็บรักษา การล้างข้อมูลอัตโนมัติ และความสามารถในการดำเนินการตามคำขอลบข้อมูลอย่างรวดเร็ว
ใครคือผู้ประมวลผลช่วงของคุณ และพวกเขาได้รับการตรวจสอบอย่างไร
หากผู้ให้บริการพึ่งพาผู้ให้บริการระบบคลาวด์หรือบุคคลที่สาม ผู้ให้บริการควรเปิดเผยว่าผู้ให้บริการที่ตนพึ่งพาคือใคร และแสดงให้เห็นว่าพาร์ทเนอร์เหล่านั้นมีมาตรฐานเดียวกัน คำตอบที่เหมาะสมจะอธิบายถึงการตรวจสอบข้อมูล ภาระผูกพันตามสัญญา และใบรับรองสำหรับผู้ประมวลผลช่วง
ขั้นตอนการแจ้งการละเมิดเป็นอย่างไร
ขอนโยบายการรายงานเหตุการณ์ที่เป็นลายลักษณ์อักษรจากผู้ให้บริการ สอบถามเกี่ยวกับลำดับเวลา (คุณจะได้รับแจ้งเกี่ยวกับการละเมิดภายในกี่ชั่วโมง) และรายละเอียดที่จะแจ้งให้ทราบ คำตอบที่ดีที่สุดควรกล่าวถึงข้อมูลเฉพาะเกี่ยวกับช่องทางการสื่อสารและการรายงานหลังเหตุการณ์พร้อมขั้นตอนการแก้ไข
ฉันจะประเมินการป้องกันการฉ้อโกงของผู้ให้บริการใน RFP ได้อย่างไร
การฉ้อโกงแต่ละรายการที่ไม่ถูกตรวจพบอาจลดรายรับและอาจทำลายความไว้วางใจของลูกค้า การตรวจจับที่ผิดพลาดแต่ละครั้งซึ่งบล็อกธุรกรรมที่ชอบด้วยกฎหมายอาจทำให้คุณเสียโอกาสในการขาย เมื่อพูดถึงการป้องกันการฉ้อโกง ผู้ให้บริการที่เหมาะสมควรให้รายละเอียดที่เจาะจง เช่น ผู้ให้บริการอาจกล่าวถึงโมเดลแมชชีนเลิร์นนิงที่สร้างขึ้นจากจุดข้อมูลหลายพันล้านจุด แดชบอร์ดที่กำหนดค่าได้ อัตราการฉ้อโกงที่เจาะจง และขั้นตอนการตรวจสอบสิทธิ์ในตัว ผู้ให้บริการควรตระหนักถึงความสมดุลระหว่างการป้องกันการฉ้อโกงและการเปลี่ยนเป็นผู้ใช้แบบชำระเงิน และแสดงให้เห็นว่าผู้ให้บริการจะช่วยคุณจัดการได้อย่างไร
นี่คือสิ่งที่คุณต้องพิจารณา
ระบบตรวจจับการฉ้อโกง
ขอให้ผู้ให้บริการอธิบายระบบการตรวจจับการฉ้อโกงโดยละเอียด มองหาผู้ให้บริการที่มีแนวทางแบบหลายชั้น เช่น แมชชีนเลิร์นนิงที่ได้รับการฝึกฝนจากชุดข้อมูลขนาดใหญ่ กฎที่กำหนดค่าได้ การตรวจสอบเอกลักษณ์ของอุปกรณ์ การตรวจสอบความถี่ และสัญญาณทางลักษณะ ผู้ให้บริการที่ดีที่สุดจะผสานการให้คะแนนอัตโนมัติเข้ากับตัวเลือกต่างๆ เพื่อดำเนินการตรวจสอบด้วยตนเองและส่งข้อมูลกลับอย่างต่อเนื่อง หากผู้ให้บริการกล่าวถึงข้อมูลกลุ่ม (เช่น สัญญาณที่รวบรวมจากธุรกิจหลายแห่ง) นั่นเป็นสัญญาณว่าโมเดลของพวกเขากำลังเรียนรู้จากขอบเขตที่กว้างเกินกว่าธุรกรรมของคุณ
ตัวอย่างเช่น Stripe มีระบบการตรวจจับการฉ้อโกงขั้นสูง และมีโอกาส 92% ที่บัตรใบใดใบหนึ่งจะถูกพบเห็นมาก่อนบนเครือข่าย Stripe ทำให้มีข้อมูลที่ครอบคลุมมากขึ้นสำหรับการประเมินการฉ้อโกง นอกจากนี้ Stripe ยังเปิดเผยคะแนนการฉ้อโกงอย่างปลอดภัยเพื่อช่วยให้บริษัทผู้ออกบัตรสามารถตัดสินใจเกี่ยวกับการอนุมัติได้แม่นยำยิ่งขึ้น
การตรวจสอบสิทธิ์ลูกค้าแบบรัดกุม (SCA)
การควบคุมการฉ้อโกงเชื่อมโยงโดยตรงกับการตรวจสอบสิทธิ์ คุณต้องกำหนดให้ผู้ให้บริการอธิบายว่าพวกเขาสนับสนุนวิธีการต่างๆ เช่น 3D Secure, รหัสผ่านแบบใช้ครั้งเดียว หรือการตรวจสอบข้อมูลไบโอเมตริกอย่างไร สำหรับธุรกิจที่ดำเนินงานในยุโรป นี่คือข้อกำหนด PSD2 แม้แต่นอกยุโรป การตรวจสอบสิทธิ์ขั้นสูงก็เป็นสิ่งจำเป็นสำหรับธุรกรรมที่มีความเสี่ยงสูงหรือน่าสงสัย ผู้ให้บริการที่เหมาะสมควรทำให้เกิดกระบวนการเหล่านี้ได้โดยไม่ต้องให้คุณสร้างเอง
ตัวชี้วัดที่ติดตาม
ขอข้อมูลเกี่ยวกับตัวชี้วัด เช่น อัตราการฉ้อโกง อัตราการดึงเงินคืน อัตราการตรวจพบที่ผิดพลาด และอัตราการอนุมัติ มองหาผู้ให้บริการที่สามารถสร้างสมดุลระหว่างตัวชี้วัดเหล่านี้ได้ เช่น อัตราการอนุมัติที่สูงควบคู่ไปกับการฉ้อโกงต่ำและความยุ่งยากน้อยที่สุด หากผู้ให้บริการเสนอการคุ้มครองการดึงเงินคืนหรือโปรแกรมโอนความรับผิด นั่นแสดงให้เห็นว่าพวกเขามั่นใจในระบบของตน แต่คุณยังต้องเข้าใจว่าผู้ให้บริการได้รับผลลัพธ์อย่างไรด้วย
ความสามารถในการปรับแต่ง
แต่ละธุรกิจมีระดับการยอมรับความเสี่ยงที่แตกต่างกัน บางธุรกิจอาจต้องให้การอัตราการเปลี่ยนเป็นลูกค้าอยู่ในระดับสูงสุด แม้ว่าจะหมายถึงการโต้แย้งการชำระเงินที่มากขึ้นก็ตาม ในขณะที่บางธุรกิจอาจเลือกที่จะเพิ่มความยุ่งยากให้กับลูกค้าเพื่อลดการฉ้อโกง ลองสอบถามดูว่าคุณสามารถปรับแต่งกฎเกี่ยวกับการฉ้อโกง ปรับเกณฑ์ความเสี่ยง และอนุญาตหรือบล็อกสถานการณ์บางอย่างได้หรือไม่ ผู้ให้บริการที่แข็งแกร่งจะเสนอแดชบอร์ดที่คุณสามารถเขียนกฎต่างๆ เช่น "ตั้งค่าสถานะธุรกรรมที่มีมูลค่ามากกว่า 5,000 ดอลลาร์สหรัฐจากลูกค้าใหม่" และ "ต้องใช้ 3D Secure สำหรับคำสั่งซื้อครั้งแรกทั้งหมดจากประเทศ X" ความยืดหยุ่นดังกล่าวเป็นสัญญาณของความเป็นมืออาชีพ
ตัวอย่างเช่น Stripe มอบประสบการณ์การผสานการทำงานที่ง่ายดายและยืดหยุ่นพร้อมเอกสารประกอบทางเทคนิค, API ที่ใช้งานง่ายสำหรับนักพัฒนา, ตัวเลือกการปรับแต่ง, เครื่องมือที่ต้องเขียนโค้ดเพียงเล็กน้อยและเครื่องมือที่ไม่ต้องเขียนโค้ด, องค์ประกอบแบบผสานรวม และความเสี่ยงที่จัดการโดย Stripe
การปกป้องที่ครอบคลุมทุกวิธีการ
วิธีการชำระเงินทุกรูปแบบ ตั้งแต่กระเป๋าเงินดิจิทัลไปจนถึงการซื้อตอนนี้ จ่ายทีหลัง ล้วนมีความเสี่ยงต่อการฉ้อโกง RFP ของคุณควรถามผู้ให้บริการว่าพวกเขาตรวจสอบวิธีการเหล่านี้อย่างไร พวกเขาตรวจสอบบัญชีธนาคาร คัดกรองผู้รับการเบิกจ่ายจากรายชื่อที่ถูกคว่ำบาตร หรือตรวจจับการยึดบัญชีหรือไม่ ผู้ให้บริการที่จัดการแต่เพียงการฉ้อโกงบัตรอาจทำให้คุณตกอยู่ในความเสี่ยงจากช่องทางอื่น
การจัดการการโต้แย้งการชำระเงิน
การป้องกันการฉ้อโกงและการจัดการโต้แย้งการชำระเงินมีความเชื่อมโยงกันอย่างมาก ถามผู้ให้บริการว่าพวกเขารับมือกับการดึงเงินคืนอย่างไร พวกเขารวบรวมหลักฐานโดยอัตโนมัติ แจ้งเตือนการโต้แย้งการชำระเงิน หรือเสนอการวิเคราะห์สาเหตุที่แท้จริงหรือไม่ แม้แต่ระบบที่ดีที่สุดก็ไม่สามารถตรวจจับทุกอย่างได้ ดังนั้นความสามารถในการจำกัดผลกระทบเมื่อเกิดการฉ้อโกงจึงมีความสำคัญเช่นกัน
ผู้ให้บริการควรให้รายละเอียดการรับมือกับเหตุการณ์และการกู้คืนจากภัยพิบัติอะไรบ้าง
วิธีที่ผู้ให้บริการเตรียมพร้อมสำหรับการละเมิดและเหตุขัดข้องสามารถบอกอะไรได้มากมายเกี่ยวกับความเป็นมืออาชีพของผู้ให้บริการ ผู้ให้บริการควรมีแผนรับมือเหตุการณ์ที่ผ่านการทดสอบแล้ว การแจ้งเตือนการละเมิดที่รวดเร็ว วัตถุประสงค์ในการกู้คืนที่วัดผลได้ โครงสร้างพื้นฐานที่ยืดหยุ่น และโปรโตคอลการสื่อสารที่ช่วยให้ธุรกิจของคุณไม่พลาดข้อมูล โดยลำดับเวลา ตัวชี้วัด และความถี่ในการทดสอบคือสัญญาณความพร้อมรับมือ
นี่คือสิ่งที่คุณจะต้องรู้
แผนการรับมือกับเหตุการณ์:สอบถามผู้ให้บริการเกี่ยวกับวิธีการรับมือกับเหตุการณ์ด้านความปลอดภัย คำตอบที่เหมาะสมจะอ้างอิงถึงแผนอย่างเป็นทางการสำหรับการตรวจจับ การกักกัน การสืบสวน และการกู้คืน ผู้ให้บริการที่ดีที่สุดจะทดสอบแผนเหล่านี้ผ่านการซ้อมจริงเป็นประจำหรือการซ้อมแผนบนโต๊ะ และอัปเดตแผนหลังจากเกิดเหตุการณ์จริง พาร์ทเนอร์ของคุณควรมีทีมงานที่ผ่านการฝึกอบรมเกี่ยวกับขั้นตอนนี้
การสื่อสารเกี่ยวกับการละเมิด: ระบุรายละเอียดให้ชัดเจน เช่น "คุณจะแจ้งให้เราทราบถึงการละเมิดที่ได้รับการยืนยันแล้วภายในกี่ชั่วโมง คุณจะให้รายละเอียดอะไรบ้าง" ผู้ให้บริการที่มีศักยภาพควรยืนยันกรอบเวลาที่ชัดเจน (เช่น 24-72 ชั่วโมง) และอธิบายข้อมูลที่พวกเขาจะเปิดเผย ได้แก่ ขอบเขต ข้อมูลที่ได้รับผลกระทบ ขั้นตอนการแก้ไข และการอัปเดตอย่างต่อเนื่อง คุณต้องขอความชัดเจนเกี่ยวกับเส้นทางการแจ้งปัญหาและผู้ติดต่อด้วย เช่น ใครจะเป็นผู้โทรหาคุณ จะติดต่อบ่อยแค่ไหน และผ่านช่องทางใด พวกเขาจะให้ข้อมูลการวิเคราะห์สาเหตุที่แท้จริงหลังเหตุการณ์หรือไม่ ผู้ให้บริการควรปฏิบัติต่อคุณในฐานะพาร์ทเนอร์ในการกู้คืนจากความเสียหาย
แผนการกู้คืนจากภัยพิบัติและความต่อเนื่องทางธุรกิจ: สอบถามเกี่ยวกับ RTO และ RPO โดยตัวชี้วัดเหล่านี้จะกำหนดว่าระบบจะกลับมาออนไลน์ได้เร็วแค่ไหนและข้อมูลอาจสูญหายไปมากน้อยเพียงใด ประเมินตัวเลขที่เป็นรูปธรรมและหลักฐานการมีระบบสำรองในหลายพื้นที่ทางภูมิศาสตร์ (เช่น ศูนย์ข้อมูลหลายแห่ง ภูมิภาคคลาวด์ทางเลือก) ผู้ให้บริการที่ไม่สามารถระบุรายละเอียดเหล่านี้อาจไม่ได้ทดสอบแผนของตน
โครงสร้างพื้นฐานสำรอง: สอบถามเกี่ยวกับเครื่องกำเนิดไฟฟ้าสำรอง ผู้ให้บริการอินเทอร์เน็ตหลายราย กลไกการสลับไปใช้ระบบสำรองโดยอัตโนมัติ และการสำรองข้อมูลอย่างต่อเนื่อง ผู้ให้บริการทดสอบกระบวนการสลับไปใช้ระบบสำรองบ่อยแค่ไหน ผู้ให้บริการบางรายเผยแพร่รายงานหลังเกิดเหตุขัดข้องเพื่อแสดงให้เห็นถึงความรับผิดชอบ โดยความโปร่งใสในระดับนี้ถือเป็นสัญญาณของความมั่นใจ
ฉันจะถามเกี่ยวกับข้อกำหนดการปฏิบัติตามข้อกำหนดทั่วโลกใน RFP ได้อย่างไร
หากคุณดำเนินธุรกิจในหลายตลาด (หรือมีแผนที่จะทำเช่นนั้น) RFP ของคุณต้องยืนยันได้ว่าผู้ให้บริการจะสามารถทำให้คุณปฏิบัติตามข้อกำหนดในทุกที่ที่คุณมีลูกค้าได้หรือไม่ ผู้ให้บริการที่แข็งแกร่งที่สุดจะถือว่าการปฏิบัติตามข้อกำหนดเป็นส่วนหนึ่งของผลิตภัณฑ์ของตน พวกเขาอาจกล่าวถึงระบบอัตโนมัติที่เกี่ยวข้องกับ PSD2, แนวทางปฏิบัติด้านความเป็นส่วนตัวที่เป็นรูปธรรม, การตรวจสอบการคว่ำบาตรที่ฝังอยู่ในการเบิกจ่าย และรายการใบอนุญาตที่ครอบคลุมตลาดที่คุณสนใจ
นี่คือสิ่งที่คุณจำเป็นต้องถามเพื่อพิจารณาว่ามีการปฏิบัติตามข้อกำหนดในระดับที่คุณต้องการหรือไม่
PSD2 และการตรวจสอบสิทธิ์ลูกค้าแบบรัดกุม (SCA)
ข้อบังคับ PSD2 ของสหภาพยุโรปกำหนดให้มีการตรวจสอบสิทธิ์ลูกค้าแบบรัดกุม (SCA) สำหรับการชำระเงินแบบอิเล็กทรอนิกส์ส่วนใหญ่ สอบถามผู้ให้บริการว่า "คุณรับมือกับข้อกำหนด PSD2 รวมถึงการตรวจสอบสิทธิ์ลูกค้าแบบรัดกุม (SCA) อย่างไร คุณจัดการข้อยกเว้นอย่างไร" ผู้ให้บริการที่เชื่อถือได้จะยืนยันว่าตนใช้การตรวจสอบสิทธิ์ลูกค้าแบบรัดกุม (SCA) โดยอัตโนมัติเมื่อจำเป็น และปรับข้อยกเว้น (เช่น การซื้อที่มีมูลค่าต่ำ ผู้รับผลประโยชน์ที่เชื่อถือได้ การชำระเงินตามแบบแผนล่วงหน้า) เพื่อขจัดอุปสรรคที่ไม่จำเป็น ผู้ให้บริการควรจัดการข้อยกเว้นเหล่านี้ด้วยกระบวนการอัตโนมัติ แทนที่จะปล่อยให้คุณต้องเขียนโค้ดเอง
การปกป้องข้อมูลและ GDPR
แต่ละภูมิภาคมีกฎหมายความเป็นส่วนตัว RFP ของคุณควรกำหนดให้ผู้ให้บริการอธิบายว่าพวกเขาปฏิบัติตาม GDPR, CCPA และกฎระเบียบด้านการคุ้มครองข้อมูลอื่นๆ อย่างไร สอบถามว่าข้อมูลลูกค้าถูกจัดเก็บไว้ที่ใด มีตัวเลือกการโฮสต์ระดับภูมิภาคหรือไม่ และกลไกใดที่ใช้สำหรับการโอนข้ามพรมแดน (เช่น กรอบข้อตกลงความเป็นส่วนตัวของข้อมูลระหว่างสหภาพยุโรปและสหรัฐอเมริกา หรือข้อสัญญามาตรฐาน) กำหนดให้ต้องมีข้อตกลงการประมวลผลข้อมูลที่สอดคล้องกับ GDPR เป็นส่วนหนึ่งของสัญญา มองหาผู้ให้บริการที่สามารถแสดงใบรับรอง การตรวจสอบ หรือการตรวจสอบความถูกต้องจากหน่วยงานที่เป็นอิสระเกี่ยวกับสถานะความเป็นส่วนตัวของตนได้
การคัดกรองการคว่ำบาตร
การปฏิบัติตามข้อกำหนดการคว่ำบาตรเป็นข้อบังคับในหลายๆ ประเทศ ตัวอย่างเช่น สำนักงานควบคุมสินทรัพย์ต่างประเทศ (OFAC) บังคับใช้มาตรการคว่ำบาตรในสหรัฐอเมริกา การไม่ตรวจสอบการคว่ำบาตรอาจส่งผลให้ต้องเสียค่าปรับและสร้างความเสียหายต่อชื่อเสียง ลองสอบถามผู้ให้บริการว่า "คุณดำเนินการคัดกรองการคว่ำบาตรตามมาตรการใดบ้าง (เช่น OFAC, EU, UN) คุณบล็อกหรือตั้งสถานะธุรกรรมที่ถูกจำกัดอย่างไร อธิบายขั้นตอนการคัดกรองการคว่ำบาตร รวมถึงรายการที่คุณตรวจสอบและความถี่ในการอัปเดต" คำตอบที่เหมาะสมจะอธิบายถึงการคัดกรองอัตโนมัติในระดับธุรกรรมและการเบิกจ่าย การอัปเดตรายการอย่างต่อเนื่อง และขั้นตอนในการจัดการรายการที่ตรงกัน
กฎระเบียบระดับภูมิภาคและการแปลให้เหมาะกับแต่ละประเทศ
ภูมิภาคต่างๆ มีกฎของตัวเอง และ RFP ควรทำให้แน่ใจว่าคุณจะได้รับความคุ้มครอง ถามผู้ให้บริการว่า "คุณสนับสนุนภาระผูกพันในการปฏิบัติตามข้อกำหนดระดับภูมิภาคใดบ้างโดยตรง และคุณจะช่วยให้เราปฏิบัติตามภาระผูกพันดังกล่าวได้อย่างไร" ผู้ให้บริการที่ดีที่สุดจะแสดงให้เห็นว่าพวกเขาติดตามกฎระดับภูมิภาคอย่างจริงจัง
การออกใบอนุญาตและการกำกับดูแลด้านกฎระเบียบ
พิจารณาว่าผู้ให้บริการมีใบอนุญาตหรือการจดทะเบียนที่เหมาะสมในตลาดหลักหรือไม่ สิ่งนี้จะเป็นตัวกำหนดว่าใครเป็นผู้รับผิดชอบด้านกฎระเบียบ และการชำระเงินของคุณจะสามารถดำเนินไปได้อย่างราบรื่นหรือไม่ ขอให้ผู้ให้บริการแสดงรายการใบอนุญาตด้านกฎระเบียบที่ตนถือครองและระบุภูมิภาคที่ครอบคลุม
คุณควรร้องขอสิ่งใดจากผู้ให้บริการสำหรับการเข้ารหัส การแปลงเป็นโทเค็น และการตรวจสอบสิทธิ์
หากผู้ให้บริการไม่สามารถอธิบายวิธีการเข้ารหัส การแปลงเป็นโทเค็น และการจำกัดการเข้าถึงได้ คุณก็ไม่จำเป็นต้องอ่านข้อเสนอต่อไป คุณควรดูรายละเอียดต่างๆ เช่น ผู้ให้บริการควรสามารถระบุมาตรฐานการเข้ารหัส อธิบายขั้นตอนการแปลงเป็นโทเค็น อธิบายรายละเอียดเกี่ยวกับการเข้าสู่ระบบครั้งเดียว (SSO) และการตรวจสอบสิทธิ์แบบหลายปัจจัย (MFA) จำกัดคีย์ของอินเทอร์เฟซการเขียนโปรแกรมแอปพลิเคชัน (API) และระบุลายเซ็น Webhook ได้
RFP ของคุณควรระบุคุณสมบัติต่อไปนี้อย่างชัดเจน
การเข้ารหัส
กำหนดให้มีการเข้ารหัสแบบต้นทางถึงปลายทางสำหรับข้อมูลการชำระเงิน ทั้งข้อมูลที่อยู่ระหว่างการส่งและข้อมูลที่ไม่ได้ใช้งาน ระบุให้ชัดเจนว่าต้องใช้ TLS 1.2 หรือ TLS 1.3 สำหรับข้อมูลที่กำลังส่ง และ AES-256 หรือมาตรฐานที่เทียบเท่าสำหรับข้อมูลที่ไม่ได้ใช้งาน ขอให้ผู้ให้บริการอธิบายวิธีจัดการคีย์ โดยถามว่าพวกเขาใช้โมดูลการรักษาความปลอดภัยของฮาร์ดแวร์ หมุนเวียนคีย์ตามกำหนดเวลาที่กำหนดไว้ และปกป้องคีย์ด้วยการแยกหน้าที่หรือไม่ การเข้ารหัสจะแข็งแกร่งเพียงใดนั้นขึ้นอยู่กับการจัดการคีย์ที่อยู่เบื้องหลัง
การแปลงเป็นโทเค็น
การแปลงเป็นโทเค็นจะลบหมายเลขบัตรที่เป็นข้อมูลดิบออกจากสภาพแวดล้อมของคุณและแทนที่ด้วยโทเค็นแบบสุ่มที่มีเพียงระบบของผู้ให้บริการเท่านั้นที่สามารถแก้ไขได้ กำหนดให้สิ่งนี้เป็นข้อกำหนด เช่น คุณอาจกล่าวว่า "ข้อมูลเจ้าของบัตรต้องมีการแปลงเป็นโทเค็น เพื่อไม่ให้ระบบของเราเห็นหรือจัดเก็บข้อมูลดิบ" ถามผู้ให้บริการว่าพวกเขารักษาความปลอดภัยของที่เก็บข้อมูลอย่างไรและสามารถนำโทเค็นกลับมาใช้ซ้ำสำหรับการเรียกเก็บเงินตามรอบบิล การชำระเงินตามรอบบิล หรือการคืนเงินได้หรือไม่
การตรวจสอบสิทธิ์และการควบคุมการเข้าถึง
ขอให้ผู้ให้บริการอธิบายวิธีรักษาความปลอดภัยในการเข้าถึงแพลตฟอร์มและ API ของตน MFA ควรเป็นสิ่งจำเป็นสำหรับการเข้าถึงแดชบอร์ดในระดับผู้ดูแลระบบ การผสาน SSO กับผู้ให้บริการข้อมูลประจำตัวขององค์กรคุณจะได้รับการพิจารณาเป็นพิเศษ ขอรายละเอียดเกี่ยวกับการเข้าถึงตามบทบาทและเส้นทางการตรวจสอบ โดยถามว่า คุณสามารถกำหนดระดับการเข้าถึงที่แตกต่างกันให้กับสมาชิกแต่ละคนในทีมได้หรือไม่ และคุณสามารถติดตามว่าใครทำอะไรและเมื่อไหร่ได้หรือไม่ สำหรับ API ให้มองหาการควบคุมที่รับรองว่ามีเพียงระบบที่ได้รับอนุญาตเท่านั้นที่สื่อสารกัน เช่น คีย์ที่กำหนดขอบเขต โทเค็นชั่วคราว และการลงนาม Webhook
การตรวจสอบสิทธิ์ที่ลูกค้าต้องดำเนินการ
การป้องกันการฉ้อโกงมักจะเชื่อมโยงกับการตรวจสอบสิทธิ์ ผู้ให้บริการควรอธิบายว่าพวกเขารองรับ 3D Secure, การตรวจสอบสิทธิ์ด้วยไบโอเมตริกในกระเป๋าเงินดิจิทัล และการตรวจสอบอย่างเข้มงวดในรูปแบบอื่นๆ อย่างไรเมื่อธุรกรรมดูมีความเสี่ยงหรือเมื่อกฎระเบียบกำหนด
ฉันจะระบุข้อกำหนดด้านการรักษาความปลอดภัยจากการชำระเงินผ่านอุปกรณ์เคลื่อนที่และการชำระเงินในแอปไว้ใน RFP ได้อย่างไร
RFP ควรแสดงให้เห็นว่าการผสานกับระบบอุปกรณ์เคลื่อนที่ของผู้ให้บริการปกป้องข้อมูลบัตรอย่างเข้มงวดเทียบเท่ากับสภาพแวดล้อมบนเว็บหรือระบบบันทึกการขาย รวมถึงข้อมูลเฉพาะเกี่ยวกับวิธีการไหลของข้อมูลบัตรใน SDK, การรับรองว่าข้อมูลที่ละเอียดอ่อนจะไม่ส่งไปที่แอป, การรองรับกระเป๋าเงินในตัว และหลักฐานของการทดสอบการรักษาความปลอดภัยเชิงรุก การชำระเงินผ่านอุปกรณ์เคลื่อนที่จะมีความปลอดภัยเทียบเท่ากับการชำระเงินในช่องทางอื่นๆ ก็ต่อเมื่อผู้ให้บริการออกแบบการผสานการทำงานโดยคำนึงถึงประเด็นดังกล่าว
นี่คือจุดที่ควรเน้นในการตั้งคำถามใน RFP ของคุณ
SDK ที่สอดคล้องกับ PCI: สอบถามผู้ให้บริการว่า SDK สำหรับ iOS และ Android ได้รับการตรวจสอบการปฏิบัติตามข้อกำหนดของ PCI หรือไม่ SDK ที่แข็งแกร่งจะไม่ปล่อยให้มีการส่งข้อมูลดิบของบัตรไปที่แอปของคุณ โดยจะเข้ารหัสข้อมูลบนอุปกรณ์และส่งตรงไปยังเซิร์ฟเวอร์ที่ปลอดภัยของผู้ให้บริการ โดยส่งคืนเฉพาะโทเค็นเท่านั้น
การรองรับกระเป๋าเงินและแพลตฟอร์ม: กำหนดให้ผู้ให้บริการต้องรองรับกระเป๋าเงินดิจิทัล (เช่น Apple Pay, Google Pay, Samsung Pay) และให้อธิบายวิธีที่โทเค็นที่สร้างขึ้นบนอุปกรณ์ไหลผ่านระบบของพวกเขา ผู้ให้บริการที่แข็งแกร่งจะเน้นย้ำว่าหมายเลขบัตรจริงจะไม่เล็ดลอดออกจากอุปกรณ์ของลูกค้า และการตรวจสอบสิทธิ์ด้วยไบโอเมตริกจะดำเนินการโดยตัวกระเป๋าเงินเอง นี่เป็นหนึ่งในวิธีการชำระเงินที่ปลอดภัยที่สุดที่มีอยู่
การป้องกันอุปกรณ์และแอป: ถามว่า SDK จัดการกับสภาพแวดล้อมที่ถูกบุกรุกอย่างไร เช่น SDK ตรวจจับอุปกรณ์ที่ถูกเจลเบรคหรือถูกปลดล็อกสิทธิ์ระดับสูง ป้องกันไม่ให้มีการบันทึกข้อมูลที่ละเอียดอ่อน และปกป้องคีย์ที่จัดเก็บไว้ในโทรศัพท์หรือไม่ คำตอบที่เหมาะสมจะอธิบายถึงมาตรการป้องกัน เช่น การปักใบรับรอง การจัดเก็บแบบจำกัด และการตรวจสอบรันไทม์ที่บล็อกการชำระเงินในสภาวะที่ไม่ปลอดภัย
การอัปเดตและการทดสอบ: กำหนดให้ผู้ให้บริการต้องอธิบายความถี่ในการอัปเดต SDK สำหรับแพตช์การรักษาความปลอดภัยและวิธีทดสอบช่องโหว่ เนื่องจากสภาพแวดล้อมบนอุปกรณ์เคลื่อนที่สามารถพัฒนาได้อย่างรวดเร็วมองหารอบเวลาการทดสอบการเจาะระบบอย่างสม่ำเสมอและความมุ่งมั่นที่จะเผยแพร่การอัปเดตเมื่อ iOS หรือ Android เวอร์ชันใหม่เปิดตัว
ควรขอความสามารถในการรายงานและการตรวจสอบอะไรบ้างใน RFP สำหรับการชำระเงิน
ทีมการเงิน การรักษาความปลอดภัย และการปฏิบัติตามข้อใช้เครื่องมือการรายงานและการตรวจสอบเพื่อพิสูจน์ว่าการควบคุมได้ผล รวมถึงเพื่อกระทบยอดเงิน และตอบสนองเมื่อหน่วยงานกำกับดูแลถามคำถามยากๆ ผู้ให้บริการที่ให้ความสำคัญกับการรายงานอย่างจริงจังควรอธิบายแดชบอร์ด, API, รายงานที่ปรับแต่งได้, เส้นทางการตรวจสอบ, ใบรับรองการปฏิบัติตามข้อกำหนด และการแจ้งเตือนในข้อกำหนดที่เป็นรูปธรรมพร้อมข้อมูลเฉพาะเกี่ยวกับระยะเวลาการเก็บรักษาข้อมูล รูปแบบ และการผสานการทำงาน โดย RFP ควรแสดงให้เห็นว่าผู้ให้บริการสามารถให้ข้อมูลเชิงลึกที่แท้จริงแก่คุณได้หรือไม่
นี่คือคุณสมบัติที่คุณควรสอบถามข้อมูลเพิ่มเติม
การรายงานธุรกรรมและการรายงานทางการเงิน
มีการรายงานอะไรบ้างสำหรับธุรกรรม การชำระเงิน การคืนเงิน การโต้แย้งการชำระเงิน และค่าธรรมเนียม รูปแบบของรายงานเป็นอย่างไร และคุณสามารถปรับแต่งรายงานโดยใช้ตัวกรองต่างๆ เช่น ช่วงวันที่ ภูมิศาสตร์ และวิธีการชำระเงินได้หรือไม่ มองหาแดชบอร์ดแบบเรียลไทม์และ API ที่ช่วยให้คุณดึงข้อมูลโดยรายละเอียดลงในระบบของคุณเองได้ หากทีมการเงินไม่สามารถกระทบยอดการเบิกจ่ายกับเงินฝากธนาคารได้อย่างง่ายดาย ทุกอย่างที่ตามมาก็อาจยากขึ้น
บันทึกการตรวจสอบกิจกรรมของระบบ
แพลตฟอร์มที่มีความเป็นมืออาชีพจะติดตามทุกการดำเนินการที่ละเอียดอ่อน เช่น การเข้าสู่ระบบ, การเปลี่ยนแปลงสิทธิ์, การสร้างคีย์ API, การคืนเงินที่ออกให้ และการตั้งค่าที่อัปเดต กำหนดให้มีบันทึกการตรวจสอบโดยละเอียดสำหรับทั้งเหตุการณ์ของระบบและกิจกรรมผู้ใช้ ถามผู้ให้บริการว่าจะเก็บบันทึกไว้นานเพียงใดและบันทึกไม่สามารถเปลี่ยนแปลงได้ใช่หรือไม่ ความสามารถในการติดตามอย่างแม่นยำว่าใครทำอะไรและเมื่อใดนั้นเป็นสิ่งที่ไม่อาจต่อรองได้เมื่อคุณกำลังเผชิญกับการตรวจสอบภายในหรือกำลังสืบหากิจกรรมที่น่าสงสัย
การสนับสนุนการตรวจสอบการปฏิบัติตามข้อกำหนดภายนอก
ผู้ตรวจสอบของคุณเองอาจขอหลักฐานที่แสดงว่าผู้ให้บริการชำระเงินกำลังดำเนินการตามที่อ้างไว้ ขอให้ผู้ให้บริการอธิบายเอกสารที่พวกเขาจัดเตรียมไว้ให้ (เช่น SOC 1, SOC 2, ใบรับรอง ISO, การรับรอง PCI DSS) และวิธีการแชร์รายงานเหล่านั้น ผู้ให้บริการบางรายอาจเสนอเอกสารเหล่านี้ภายใต้ข้อตกลงการไม่เปิดเผยข้อมูล ในขณะที่บางรายอาจมีพอร์ทัลลูกค้า
การตรวจสอบและการแจ้งเตือนแบบเรียลไทม์
ผู้ให้บริการที่แข็งแกร่งควรมีการแจ้งเตือนหรือ Webhook ที่กำหนดค่าได้ ซึ่งจะแจ้งให้คุณทราบถึงความผิดปกติแบบเรียลไทม์ เช่น การดึงเงินคืนที่เพิ่มขึ้น กลุ่มการปฏิเสธการชำระเงินที่ผิดปกติ หรืออัตราข้อผิดพลาดของ API ที่มีแนวโน้มเพิ่มขึ้น ทีมไม่สามารถตอบสนองได้อย่างรวดเร็วหากไม่มีระบบแจ้งเตือนล่วงหน้า และ RFP ของคุณควรระบุให้ชัดเจนว่าการมองเห็นตัวชี้วัดแบบเรียลไทม์เป็นสิ่งจำเป็น
การเข้าถึงและการเก็บรักษาข้อมูล
คุณอาจต้องใช้ประวัติธุรกรรมและเส้นทางการตรวจสอบย้อนหลังหลายปีเพื่อให้เป็นไปตามข้อกำหนดของหน่วยงานกำกับดูแลทางการเงิน ถามผู้ให้บริการว่า "รายงานและบันทึกการตรวจสอบจะถูกเก็บไว้นานแค่ไหน เราสามารถการส่งออกและเก็บถาวรรายงานและบันทึกดังกล่าวเพื่อปฏิบัติตามข้อกำหนดของเราเองได้หรือไม่" คำตอบที่ดีจะระบุชัดเจนว่าข้อมูลจะได้รับการเก็บรักษาไว้เป็นเวลาหลายปี โดยมีวิธีง่ายๆ การส่งออกหรือซิงค์ข้อมูลไปยังคลังสินค้าของคุณเอง
สัญญาณเตือนใดบ้างในคำตอบ RFP ของผู้ให้บริการที่บ่งชี้ถึงการรักษาความปลอดภัยที่ไม่รัดกุมหรือการปฏิบัติตามข้อกำหนดที่ไม่เพียงพอ
RFP ให้ความสำคัญกับการระบุสิ่งที่ขาดหายไปพอๆ กับการประเมินสิ่งที่เขียน ผู้ให้บริการที่มีประสิทธิภาพจะให้คำตอบที่ชัดเจนโดยมีข้อมูลเฉพาะและหลักฐานรองรับ หากข้อมูลไม่ครบถ้วน ข้อนี้ก็เป็นเหตุผลให้คุณต้องชะลอการตัดสินใจและศึกษาเพิ่มเติมก่อนที่จะไปต่อ
ต่อไปนี้เป็นสัญญาณเตือนหลักๆ ที่ควรระวังเมื่อคุณประเมิน RFP
ภาษาที่คลุมเครือ: หากคำตอบอาศัยวลีต่างๆ เช่น "การรักษาความปลอดภัยที่ล้ำสมัย" โดยไม่ระบุชื่อมาตรฐาน โปรโตคอล หรือใบรับรองที่แท้จริง นั่นก็บ่งบอกว่าผู้ให้บริการไม่สามารถหรือไม่ยอมให้รายละเอียด ผู้ให้บริการที่จริงจังจะอ้างอิงถึง PCI DSS, SOC 2, ISO 27001, วิธีการเข้ารหัสเฉพาะ และกระบวนการที่เป็นรูปธรรม
ไม่มีการตรวจสอบความถูกต้องจากหน่วยงานที่เป็นอิสระ: ผู้ให้บริการที่ประมวลผลการชำระเงินควรมีการตรวจสอบจากภายนอก หากผู้ให้บริการรายใดไม่ได้รับการรับรองจาก PCI หรือไม่สามารถส่งรายงาน SOC หรือ ISO ได้ ให้หาผู้ให้บริการรายอื่นที่มีใบรับรองเหล่านี้
แผนการรับมือกับเหตุการณ์ที่ไม่ชัดเจน: RFP ควรแสดงกรอบเวลาที่เป็นรูปธรรมและแผนที่ผ่านการทดสอบแล้วสำหรับการแจ้งเตือนการละเมิด นอกเหนือไปจากแผนการกู้คืนที่จัดทำเป็นเอกสาร หากผู้ให้บริการกล่าวอย่างคลุมเครือ เช่น "เราจะแจ้งให้ลูกค้าทราบตามความเหมาะสม" คุณก็รับประกันไม่ได้ว่าจะได้รับการสื่อสารอย่างทันท่วงทีเมื่อถึงเวลาสำคัญที่สุด
การโอนความรับผิดชอบ: ระวังคำตอบที่ส่งภาระผูกพันที่สำคัญกลับมาสู่ทีมของคุณ (เช่น "เรามอบเครื่องมือให้ แต่การปฏิบัติตามข้อกำหนดเป็นหน้าที่ของธุรกิจ") คุณจะมีความรับผิดชอบอยู่เสมอ แต่ผู้ให้บริการที่แข็งแกร่งจะแบ่งเบาภาระและให้การสนับสนุนอย่างชัดเจน
แนวทางปฏิบัติที่ล้าสมัย: การอ้างอิงถึงมาตรฐานที่ไม่เข้มงวดหรือล้าสมัย (เช่น MD5 สำหรับการแฮชรหัสผ่าน, PCI เวอร์ชันเก่ากว่า) ถือเป็นสัญญาณว่าระบบรักษาความปลอดภัยยังไม่ทันสมัย คุณควรคาดหวังการเข้ารหัสที่ทันสมัย, MFA สำหรับการเข้าถึงระดับผู้ดูแลระบบ และการสอดคล้องตาม PCI DSS ในปัจจุบัน
การขัดแย้งหรือการสัญญาเกินจริง: ความไม่สอดคล้องกันระหว่างคำตอบ (เช่น การอ้างว่าข้อมูลไม่ได้ถูกจัดเก็บไว้เลย แต่กลับกล่าวว่าข้อมูลถูกเข้ารหัสไว้ในขณะที่ไม่ได้ใช้งาน) บ่งบอกถึงความประมาทหรือการสื่อสารภายในที่ไม่ดี การรับประกันว่า "ปลอดการฉ้อโกง" หรือ "ระยะเวลาให้บริการ 100%" โดยไม่มีหลักฐานก็น่าสงสัยไม่แพ้กัน
Stripe Payments ช่วยได้อย่างไร
Stripe Payments มอบโซลูชันการชำระเงินระดับโลกแบบครบวงจรที่ช่วยให้ธุรกิจทุกขนาด ตั้งแต่สตาร์ทอัพที่กำลังเติบโตไปจนถึงองค์กรระดับโลก โดยรับชำระเงินออนไลน์ ที่จุดขาย และทั่วโลกได้
Stripe Payments สามารถช่วยคุณทำสิ่งต่อไปนี้
เพิ่มประสิทธิภาพให้ประสบการณ์การชำระเงินของคุณ: สร้างประสบการณ์ที่ราบรื่นให้กับลูกค้าและประหยัดเวลาในการทำงานวิศวกรรมได้หลายพันชั่วโมงด้วย UI การชำระเงินที่สร้างไว้ให้แล้ว, สิทธิ์เข้าถึงวิธีการชำระเงินมากกว่า 125 วิธี และ Link ซึ่งเป็นกระเป๋าเงินที่สร้างโดย Stripe
ขยายไปสู่ตลาดใหม่ๆ ได้เร็วขึ้น: เข้าถึงลูกค้าทั่วโลกและลดความซับซ้อนและค่าใช้จ่ายในการจัดการหลายสกุลเงินด้วยตัวเลือกการชำระเงินข้ามพรมแดนที่มีให้บริการใน 195 ประเทศและกว่า 135 สกุลเงิน
รวมการชำระเงินที่จุดขายและทางออนไลน์ไว้ด้วยกัน: สร้างประสบการณ์การค้าแบบแพลตฟอร์มรวมในช่องทางออนไลน์และที่จุดขายเพื่อปรับแต่งการโต้ตอบ ตอบแทนความภักดี และเพิ่มรายรับ
ปรับปรุงประสิทธิภาพการชำระเงิน: เพิ่มรายรับด้วยเครื่องมือการชำระเงินที่กำหนดเองได้และปรับแต่งได้ง่ายๆ ซึ่งรวมถึงระบบป้องกันการฉ้อโกงแบบไม่ต้องเขียนโค้ดและฟังก์ชันขั้นสูงเพื่อเพิ่มอัตราการอนุมัติ
เดินหน้าได้เร็วขึ้นด้วยแพลตฟอร์มที่ยืดหยุ่นและเชื่อถือได้เพื่อการเติบโต: สร้างบนแพลตฟอร์มที่ออกแบบมาเพื่อขยับขยายไปพร้อมกับคุณ โดยมีระยะเวลาให้บริการที่แทบจะไม่หยุดทำงานเลยในระยะเวลาที่ผ่านมา และมีความน่าเชื่อถือระดับแนวหน้าของวงการ
ดูข้อมูลเพิ่มเติมว่า Stripe Payments ช่วยให้คุณสามารถรับการชำระเงินออนไลน์และการชำระเงินที่จุดขายได้อย่างไร หรือเริ่มใช้งานเลยวันนี้