การรักษาความปลอดภัยและการปฏิบัติตามข้อกำหนดในการชำระเงิน: แนวทางปฏิบัติที่ดีที่สุดสำหรับการเขียน RFP ที่เหมาะสม

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

Payments
Payments

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

ดูข้อมูลเพิ่มเติม 
  1. บทแนะนำ
  2. ข้อกำหนดด้านการรักษาความปลอดภัยและการปฏิบัติตามข้อกำหนดที่ควรระบุในแต่ละ RFP สำหรับการชำระเงินมีอะไรบ้าง
    1. การรับรองและการตรวจสอบในระดับอุตสาหกรรม
    2. การปฏิบัติตามข้อกำหนดของ PCI DSS
    3. การคุ้มครองข้อมูลและความเป็นส่วนตัว
    4. การป้องกันการฉ้อโกง
    5. การรับมือกับเหตุการณ์และการกู้คืนจากภัยพิบัติ
    6. ความครอบคลุมการปฏิบัติตามข้อกำหนดทั่วโลก
    7. การควบคุมการรักษาความปลอดภัยของข้อมูลหลัก
    8. การชำระเงินผ่านอุปกรณ์เคลื่อนที่และการชำระเงินในแอป
    9. การรายงานและความสามารถในการตรวจสอบ
  3. ฉันจะเขียนข้อกำหนด PCI DSS ลงใน RFP สำหรับการชำระเงินได้อย่างไร
  4. คำถามพื้นฐานเกี่ยวกับการคุ้มครองข้อมูลและความเป็นส่วนตัวที่คุณควรถามผู้ให้บริการมีอะไรบ้าง
    1. ข้อมูลถูกจัดเก็บและประมวลผลที่ไหน
    2. ข้อมูลส่วนตัวได้รับการคุ้มครองอย่างไร
    3. คุณปฏิบัติตามกฎหมายความเป็นส่วนตัวใดบ้าง และมีสัญญาหรือเอกสารใดที่ยืนยันได้
    4. นโยบายการเก็บรักษาและการลบข้อมูลของคุณเป็นอย่างไร
    5. ใครคือผู้ประมวลผลช่วงของคุณ และพวกเขาได้รับการตรวจสอบอย่างไร
    6. ขั้นตอนการแจ้งการละเมิดเป็นอย่างไร
  5. ฉันจะประเมินการป้องกันการฉ้อโกงของผู้ให้บริการใน RFP ได้อย่างไร
    1. ระบบตรวจจับการฉ้อโกง
    2. การตรวจสอบสิทธิ์ลูกค้าแบบรัดกุม (SCA)
    3. ตัวชี้วัดที่ติดตาม
    4. ความสามารถในการปรับแต่ง
    5. การปกป้องที่ครอบคลุมทุกวิธีการ
    6. การจัดการการโต้แย้งการชำระเงิน
  6. ผู้ให้บริการควรให้รายละเอียดการรับมือกับเหตุการณ์และการกู้คืนจากภัยพิบัติอะไรบ้าง
  7. ฉันจะถามเกี่ยวกับข้อกำหนดการปฏิบัติตามข้อกำหนดทั่วโลกใน RFP ได้อย่างไร
    1. PSD2 และการตรวจสอบสิทธิ์ลูกค้าแบบรัดกุม (SCA)
    2. การปกป้องข้อมูลและ GDPR
    3. การคัดกรองการคว่ำบาตร
    4. กฎระเบียบระดับภูมิภาคและการแปลให้เหมาะกับแต่ละประเทศ
    5. การออกใบอนุญาตและการกำกับดูแลด้านกฎระเบียบ
  8. คุณควรร้องขอสิ่งใดจากผู้ให้บริการสำหรับการเข้ารหัส การแปลงเป็นโทเค็น และการตรวจสอบสิทธิ์
    1. การเข้ารหัส
    2. การแปลงเป็นโทเค็น
    3. การตรวจสอบสิทธิ์และการควบคุมการเข้าถึง
    4. การตรวจสอบสิทธิ์ที่ลูกค้าต้องดำเนินการ
  9. ฉันจะระบุข้อกำหนดด้านการรักษาความปลอดภัยจากการชำระเงินผ่านอุปกรณ์เคลื่อนที่และการชำระเงินในแอปไว้ใน RFP ได้อย่างไร
  10. ควรขอความสามารถในการรายงานและการตรวจสอบอะไรบ้างใน RFP สำหรับการชำระเงิน
    1. การรายงานธุรกรรมและการรายงานทางการเงิน
    2. บันทึกการตรวจสอบกิจกรรมของระบบ
    3. การสนับสนุนการตรวจสอบการปฏิบัติตามข้อกำหนดภายนอก
    4. การตรวจสอบและการแจ้งเตือนแบบเรียลไทม์
    5. การเข้าถึงและการเก็บรักษาข้อมูล
  11. สัญญาณเตือนใดบ้างในคำตอบ RFP ของผู้ให้บริการที่บ่งชี้ถึงการรักษาความปลอดภัยที่ไม่รัดกุมหรือการปฏิบัติตามข้อกำหนดที่ไม่เพียงพอ
  12. Stripe Payments ช่วยได้อย่างไร

ในปี 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 ช่วยให้คุณสามารถรับการชำระเงินออนไลน์และการชำระเงินที่จุดขายได้อย่างไร หรือเริ่มใช้งานเลยวันนี้

หากพร้อมเริ่มใช้งานแล้ว

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

Payments

รับชำระเงินออนไลน์ ที่จุดขาย และทั่วโลกด้วยโซลูชันการชำระเงินที่สร้างมาสำหรับธุรกิจทุกขนาด

Stripe Docs เกี่ยวกับ Payments

ค้นหาคู่มือเกี่ยวกับการเชื่อมต่อ Payments API ของ Stripe