ข้ามไปยังเนื้อหาหลัก

รายการตรวจสอบก่อนเปิดใช้งานจริง

พร้อมที่จะรับชำระเงินจริงหรือยัง? รายการตรวจสอบที่ครอบคลุมนี้จะแนะนำคุณผ่านการตรวจสอบธุรกิจ ข้อกำหนดด้านความปลอดภัย การทดสอบ และการเปิดตัว

ภาพรวม

การเปิดใช้งานจริงกับ Omise ประกอบด้วยสามขั้นตอนหลัก:

  1. การตรวจสอบธุรกิจ - ส่งเอกสารที่จำเป็น
  2. การเตรียมความพร้อมทางเทคนิค - ดำเนินการ integration และการทดสอบให้เสร็จสมบูรณ์
  3. การเปิดตัว - เปลี่ยนเป็น live keys และเปิดใช้งานจริง

ระยะเวลา: 3-7 วันทำการสำหรับการตรวจสอบ

ขั้นตอนที่ 1: การตรวจสอบธุรกิจ

ก่อนที่คุณจะสามารถรับชำระเงินจริงได้ Omise จำเป็นต้องตรวจสอบธุรกิจของคุณ ข้อกำหนดจะแตกต่างกันไปตามประเภทของธุรกิจ

สำหรับธุรกิจ (บริษัท)

เอกสารที่จำเป็น

  • หนังสือรับรองการจดทะเบียนบริษัท (DBD หรือเอกสารที่เทียบเท่า)

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

    • เอกสารทางการจากสำนักงานทะเบียน
    • แสดงผู้ถือหุ้นทั้งหมดและเปอร์เซ็นต์การถือหุ้น
  • บัตรประจำตัวของกรรมการ

    • กรรมการบริษัททุกคน
    • สำเนาที่ชัดเจนและอ่านได้
    • ทั้งสองด้านของบัตรประจำตัว
  • หนังสือรับรองบัญชีธนาคาร

    • หน้าแรกของสมุดบัญชีธนาคารไทย
    • statement ธนาคาร (3 เดือนล่าสุด)
    • ชื่อบัญชีต้องตรงกับชื่อบริษัท
  • เว็บไซต์ธุรกิจ

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

    • เอกสารทั้งหมดต้องมีการลงนาม
    • รับรองด้วยตราประทับบริษัท
    • ไม่รับลายเซ็นอิเล็กทรอนิกส์

ข้อกำหนดรูปแบบ

  • ประเภทไฟล์: PDF, JPG หรือ PNG
  • ขนาด: ไฟล์ละไม่เกิน 10MB
  • คุณภาพ: ชัดเจนและอ่านได้
  • ภาษา: ไทยหรืออังกฤษ (อาจต้องแปล)

สำหรับบุคคลธรรมดา / เจ้าของธุรกิจเดี่ยว

เอกสารที่จำเป็น

  • เอกสารระบุตัวตน

    • คนไทย: บัตรประจำตัวประชาชน (ทั้งสองด้าน)
    • ชาวต่างชาติ: หนังสือเดินทาง ใบอนุญาตทำงาน หลักฐานที่อยู่
  • หนังสือรับรองบัญชีธนาคาร

    • หน้าแรกของสมุดบัญชีธนาคารไทย
    • ชื่อบัญชีต้องตรงกับชื่อในบัตรประจำตัว
  • เว็บไซต์ธุรกิจหรือ Social Media

    • เปิดใช้งานและแสดงสินค้า/บริการ
    • มีข้อมูลติดต่อที่มองเห็นได้
  • นโยบายการคืนเงิน

    • ระบุอย่างชัดเจน
    • สามารถเข้าถึงได้ก่อนชำระเงิน

สำหรับธุรกิจต่างประเทศ

ข้อกำหนดจะแตกต่างกันไปตามประเทศ กรุณาติดต่อ support@omise.co พร้อมรายละเอียดธุรกิจของคุณสำหรับข้อกำหนดเฉพาะ

เริ่มต้นตั้งแต่เนิ่นๆ

เริ่มรวบรวมเอกสารในขณะที่คุณกำลังสร้าง integration การตรวจสอบอาจใช้เวลา 3-7 วันทำการ

ขั้นตอนที่ 2: ส่งเอกสารเพื่อตรวจสอบ

วิธีการส่ง

  1. ลงชื่อเข้าใช้ Omise Dashboard
  2. คลิกแท็บ Live Dashboard
  3. คลิก Apply for Live Account
  4. กรอกแบบฟอร์มใบสมัคร
  5. อัปโหลดเอกสารที่จำเป็นทั้งหมด
  6. ส่งเพื่อตรวจสอบ

จะเกิดอะไรขึ้นต่อไป

  1. ได้รับการส่ง - คุณจะได้รับอีเมลยืนยัน
  2. อยู่ระหว่างการตรวจสอบ - ทีม Omise ตรวจสอบ (3-5 วันทำการ)
  3. ต้องการข้อมูลเพิ่มเติม - คุณอาจถูกติดต่อเพื่อชี้แจง
  4. อนุมัติแล้ว - Live keys จะพร้อมใช้งานใน dashboard ของคุณ
  5. ปฏิเสธ - คุณจะได้รับเหตุผลและสามารถส่งใหม่ได้
ระยะเวลาการตรวจสอบ

ใบสมัครส่วนใหญ่จะได้รับการตรวจสอบภายใน 3-5 วันทำการ กรณีที่ซับซ้อนอาจใช้เวลานานกว่านี้

ขั้นตอนที่ 3: การเตรียมความพร้อมทางเทคนิค

ดำเนินการตามข้อกำหนดทางเทคนิคเหล่านี้ให้เสร็จสมบูรณ์ก่อนเปิดตัว:

รายการตรวจสอบด้านความปลอดภัย

  • เปิดใช้งาน HTTPS

    • ติดตั้ง SSL/TLS certificate แล้ว
    • หน้าชำระเงินทั้งหมดใช้ HTTPS
    • ไม่มีการเตือน mixed content
    • TLS 1.2 หรือสูงกว่า
  • รักษาความปลอดภัย API Keys

    • เก็บ secret keys ใน environment variables
    • ไม่เก็บใน code repositories
    • ไม่อยู่ใน client-side code
    • จำกัดการเข้าถึงเฉพาะบุคลากรที่ได้รับอนุญาต
  • การจัดการข้อมูลบัตร

    • บัตรไม่สัมผัสกับ server ของคุณ
    • ใช้ Omise.js หรือ SDKs สำหรับ tokenization
    • ไม่มีข้อมูลบัตรใน logs
    • ไม่มีข้อมูลบัตรใน databases
  • การจัดการข้อผิดพลาด

    • จัดการข้อผิดพลาด API ทั้งหมดอย่างเหมาะสม
    • ข้อความแสดงข้อผิดพลาดที่เป็นมิตรกับผู้ใช้
    • บันทึกการชำระเงินที่ล้มเหลว
    • ใช้งาน retry logic
  • ความปลอดภัยของ Webhook

    • ใช้งานการตรวจสอบ signature
    • HTTPS endpoint ที่มี certificate ที่ถูกต้อง
    • การจัดการ idempotency (events ซ้ำ)
    • การจัดการข้อผิดพลาดและ retries

ตรวจสอบแนวปฏิบัติที่ดีที่สุดด้านความปลอดภัย →

การทดสอบ Integration

  • การชำระเงินที่สำเร็จ

    • ทดสอบวิธีการชำระเงินทั้งหมด
    • คำนวณจำนวนเงินได้อย่างถูกต้อง
    • การยืนยันคำสั่งซื้อทำงาน
    • การแจ้งเตือนทางอีเมลส่ง
  • การชำระเงินที่ล้มเหลว

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

    • การคืนเงินเต็มจำนวนทำงาน
    • การคืนเงินบางส่วนทำงาน
    • อัปเดตสถานะการคืนเงิน
    • การแจ้งเตือนลูกค้า
  • กรณีพิเศษ

    • จัดการ network timeouts
    • ทดสอบ race conditions
    • ป้องกันการส่งซ้ำ
    • จัดการการหมดอายุของ session
  • Webhooks

    • จัดการ event types ทั้งหมด
    • Idempotency ทำงาน
    • การตรวจสอบ signature ใช้งานอยู่
    • บันทึกความล้มเหลวในการส่ง

คู่มือการทดสอบที่สมบูรณ์ →

ประสบการณ์ผู้ใช้

  • ขั้นตอนการชำระเงิน

    • ราคาที่ชัดเจน (รวมค่าธรรมเนียมถ้ามี)
    • ตัวบ่งชี้ความคืบหน้า
    • สถานะการโหลด
    • ข้อเสนอแนะความสำเร็จ/ล้มเหลว
    • รองรับมือถือ
  • วิธีการชำระเงิน

    • วิธีการทั้งหมดมองเห็นได้ชัดเจน
    • แสดงวิธีการตามภูมิภาคอย่างถูกต้อง
    • คำแนะนำการชำระเงินชัดเจน
    • QR codes ทำงาน
  • การสื่อสารกับลูกค้า

    • อีเมลยืนยันคำสั่งซื้อ
    • ใบเสร็จการชำระเงิน
    • การแจ้งเตือนการคืนเงิน
    • การแจ้งเตือนการชำระเงินที่ล้มเหลว
  • นโยบายการคืนเงิน

    • มองเห็นได้ชัดเจน
    • หาได้ง่าย
    • ก่อนการซื้อขั้นสุดท้าย
    • บนหน้ายืนยัน

การปฏิบัติตามข้อกำหนด

  • ข้อกำหนดการให้บริการ

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

    • เผยแพร่และเข้าถึงได้
    • ครอบคลุมข้อมูลการชำระเงิน
    • ปฏิบัติตามกฎหมายท้องถิ่น
  • นโยบายการคืนเงิน

    • กำหนดเวลาที่ชัดเจน
    • อธิบายกระบวนการ
    • มองเห็นได้ก่อนซื้อ
  • ข้อมูลติดต่อ

    • ที่อยู่อีเมล
    • หมายเลขโทรศัพท์ (ถ้ามี)
    • ความคาดหวังเวลาตอบกลับ

ขั้นตอนที่ 4: การทดสอบประสิทธิภาพ

การทดสอบภาระ

ทดสอบ integration ของคุณภายใต้ภาระที่เป็นจริง:

  • การชำระเงินพร้อมกัน

    • การชำระเงินพร้อมกันหลายรายการ
    • ไม่มี race conditions
    • ประสิทธิภาพ database เพียงพอ
  • ปริมาณสูง

    • สถานการณ์ traffic สูงสุด
    • ทรัพยากร server เพียงพอ
    • เวลาตอบสนองที่ยอมรับได้
  • การประมวลผล Webhook

    • การจัดการ webhook ปริมาณสูง
    • ระบบ queue หากจำเป็น
    • ไม่มี events หาย

การตั้งค่าการตรวจสอบ

  • การติดตามข้อผิดพลาด

    • เครื่องมือตรวจสอบข้อผิดพลาดถูกรวมเข้าด้วยกัน (Sentry, Rollbar ฯลฯ)
    • กำหนดค่าเกณฑ์การแจ้งเตือน
    • ตั้งค่าการแจ้งเตือนทีม
  • การวิเคราะห์

    • การติดตามการแปลง
    • การใช้งานวิธีการชำระเงิน
    • การตรวจสอบอัตราความล้มเหลว
    • การวิเคราะห์ funnel
  • การตรวจสอบ Uptime

    • การติดตาม uptime ของหน้าชำระเงิน
    • การตรวจสอบ webhook endpoint
    • แจ้งเตือนเมื่อเกิด downtime

ขั้นตอนที่ 5: การตรวจสอบก่อนเปิดตัว

การตรวจสอบโค้ด

  • การตรวจสอบความปลอดภัย

    • การตรวจสอบความปลอดภัยโดยบุคคลที่สาม (หากจำเป็น)
    • การทดสอบการเจาะระบบ (หากจำเป็น)
    • การตรวจสอบโค้ดเสร็จสมบูรณ์
  • การปฏิบัติตาม PCI

    • แบบสอบถามการประเมินตนเองเสร็จสมบูรณ์
    • หากจัดการข้อมูลบัตรโดยตรง: ได้รับการรับรอง PCI
    • แจ้ง Omise หากคุณได้รับการรับรอง PCI
  • เอกสาร

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

การเปิดตัวนุ่มนวล (แนะนำ)

ก่อนการเปิดตัวสู่สาธารณะเต็มรูปแบบ:

  • การเปิดตัวจำกัด

    • กลุ่มผู้ใช้ทดสอบขนาดเล็ก
    • การชำระเงินจริงด้วยบัตรจริง
    • จำนวนเงินรายการเล็ก
  • ตรวจสอบอย่างใกล้ชิด

    • ดูข้อผิดพลาด
    • ตรวจสอบการส่ง webhook
    • ตรวจสอบขั้นตอนการทำธุรกรรม
    • รวบรวมคำติชมจากผู้ใช้
  • ตรวจสอบการโอนเงิน

    • ยืนยันว่าเงินโอนถูกต้อง
    • ตรวจสอบกำหนดการโอน
    • ตรวจสอบรายละเอียดบัญชีธนาคาร

ขั้นตอนที่ 6: เปลี่ยนเป็น Live Keys

เมื่อการตรวจสอบได้รับการอนุมัติและการทดสอบเสร็จสมบูรณ์:

อัปเดตการกำหนดค่า

// ก่อน (Test Mode)
const omise = require('omise')({
publicKey: 'pkey_test_5xp6c8ltm5wb5o45cls',
secretKey: 'skey_test_5xp6c8n0jvds5mmjizz'
});

// หลัง (Live Mode)
const omise = require('omise')({
publicKey: 'pkey_5xp6c8ltm5wb5o45cls', // ไม่มี "_test_"
secretKey: 'skey_5xp6c8n0jvds5mmjizz' // ไม่มี "_test_"
});

รายการตรวจสอบการ Deploy

  • Environment Variables

    • อัปเดต live public key แล้ว
    • อัปเดต live secret key แล้ว
    • ตรวจสอบใน environments ทั้งหมด (staging, production)
  • การกำหนดค่า

    • จำนวนเงินการชำระเงินถูกต้อง (ไม่ใช่จำนวนทดสอบ)
    • Webhook URLs ชี้ไปที่ production
    • การตั้งค่าอีเมลใช้ค่า production
    • Database ใช้ instance production
  • ลบตัวบ่งชี้การทดสอบ

    • ลบแบนเนอร์ "Test Mode"
    • ลบคำแนะนำบัตรทดสอบ
    • ลบ URLs staging/test
  • ตรวจสอบ Live Dashboard

    • สามารถเห็น Live Dashboard
    • Live keys มองเห็นได้
    • Webhook ถูกกำหนดค่าสำหรับ live

ขั้นตอนที่ 7: วันเปิดตัว

การตรวจสอบขั้นสุดท้าย (1 ชั่วโมงก่อนเปิดตัว)

  • SSL certificate ถูกต้อง
  • บริการทั้งหมดทำงาน
  • การเชื่อมต่อ database ปกติ
  • การตรวจสอบใช้งานอยู่
  • ทีมพร้อมรองรับ

การ Deploy

  1. Deploy ในช่วงที่มี Traffic ต่ำ

    • หลีกเลี่ยงช่วงเวลาที่มีผู้เข้าชมสูงสุด
    • ควรเป็นวันทำการ (ไม่ใช่วันศุกร์)
    • ช่วงเช้า/บ่ายตรุ่นเป็นอุดมคติ
  2. การเปิดตัวแบบแบ่งขั้น

    • Deploy ไปยัง staging ก่อน
    • ตรวจสอบว่า staging ทำงาน
    • Deploy ไปยัง production
    • ตรวจสอบว่า production ทำงาน
  3. การทดสอบเบื้องต้น

    • ทำการซื้อทดสอบจริง (จำนวนเงินเล็กน้อย)
    • ตรวจสอบว่า charge ปรากฏใน live dashboard
    • ตรวจสอบการส่ง webhook
    • ยืนยันการส่งอีเมล
    • ทดสอบการคืนเงินหากเป็นไปได้

การตรวจสอบ 24 ชั่วโมงแรก

  • ดู Dashboard

    • ตรวจสอบการชำระเงินที่ล้มเหลว
    • ตรวจสอบอัตราความสำเร็จ
    • ตรวจสอบข้อความแสดงข้อผิดพลาด
  • ตรวจสอบ Logs

    • ข้อผิดพลาด server
    • ข้อผิดพลาด API
    • ความล้มเหลวของ webhook
  • ฝ่ายสนับสนุนลูกค้าพร้อม

    • ทีมได้รับการบรรยายสรุป
    • ตรวจสอบ support tickets
    • แผนการตอบสนองอย่างรวดเร็ว
  • แผน Rollback อย่างรวดเร็ว

    • สำรองเวอร์ชันก่อนหน้า
    • ทดสอบขั้นตอน rollback
    • แผน rollback database

ขั้นตอนที่ 8: หลังเปิดตัว

สัปดาห์แรก

  • การตรวจสอบรายวัน

    • ตรวจสอบธุรกรรมทั้งหมด
    • ตรวจสอบความผิดปกติ
    • ตรวจสอบอัตราข้อผิดพลาด
    • ตรวจสอบคำขอคืนเงิน
  • การตรวจสอบการโอนเงิน

    • ยืนยันการโอนครั้งแรก
    • ตรวจสอบจำนวนเงินถูกต้อง
    • ตรวจสอบเวลา
  • คำติชมจากลูกค้า

    • สำรวจลูกค้า
    • ตรวจสอบ support tickets
    • แก้ไขปัญหาอย่างรวดเร็ว

ต่อเนื่อง

  • การกระทบยอดปกติ

    • จับคู่ธุรกรรมกับคำสั่งซื้อ
    • ตรวจสอบจำนวนเงินที่โอน
    • กระทบยอดการคืนเงิน
  • การตรวจสอบประสิทธิภาพ

    • ติดตามอัตราความสำเร็จ
    • ตรวจสอบเวลาตอบสนอง
    • ตรวจสอบรูปแบบข้อผิดพลาด
  • การตรวจสอบความปลอดภัย

    • การตรวจสอบความปลอดภัยเป็นประจำ
    • อัปเดต libraries
    • ตรวจสอบช่องโหว่
  • การเพิ่มประสิทธิภาพ

    • วิเคราะห์การใช้งานวิธีการชำระเงิน
    • เพิ่มประสิทธิภาพขั้นตอนการชำระเงิน
    • ลดอัตราการละทิ้ง

ปัญหาที่พบบ่อยและวิธีแก้ไข

การตรวจสอบถูกปฏิเสธ

ปัญหา: ใบสมัครถูกปฏิเสธหรือต้องการข้อมูลเพิ่มเติม

วิธีแก้ไข:

  • ตรวจสอบอีเมลปฏิเสธอย่างรอบคอบ
  • ให้ข้อมูลเพิ่มเติมตามที่ร้องขอ
  • ตรวจสอบให้แน่ใจว่าเอกสารชัดเจนและอ่านได้
  • ติดต่อ support@omise.co เพื่อขอคำชี้แจง

ธุรกรรมล้มเหลว

ปัญหา: อัตราความล้มเหลวสูงหลังเปิดตัว

ตรวจสอบ:

  • คุณใช้ live keys ที่ถูกต้องหรือไม่?
  • API endpoint ถูกต้องหรือไม่ (ไม่ใช่ vault endpoint สำหรับ charges)?
  • จำนวนเงินอยู่ในหน่วยสกุลเงินที่ถูกต้องหรือไม่?
  • ตรวจสอบข้อความแสดงข้อผิดพลาดใน dashboard

Webhooks ไม่ส่ง

ปัญหา: ไม่ได้รับ webhook events

วิธีแก้ไข:

  • ตรวจสอบ HTTPS ที่มี certificate ถูกต้อง
  • ตรวจสอบ webhook URL ในการตั้งค่า live dashboard
  • ตรวจสอบให้แน่ใจว่า endpoint ส่งสถานะ 200
  • ตรวจสอบว่า firewall ไม่ได้บล็อก IPs ของ Omise
  • ตรวจสอบ webhook logs ใน dashboard

การล่าช้าในการโอนเงิน

ปัญหา: เงินไม่ปรากฏในบัญชีธนาคาร

ตรวจสอบ:

  • ระยะเวลาหยุดชำระ: 7 วัน (ไทย), 21 วัน (ญี่ปุ่น)
  • กำหนดการโอน: รายวันประมาณ 10 โมงเช้าเวลาประเทศไทย
  • รายละเอียดบัญชีธนาคารถูกต้องใน dashboard
  • คุณได้สร้างการโอนด้วยตนเองหรือไม่?

คำถามที่พบบ่อย

การตรวจสอบธุรกิจใช้เวลานานเท่าใด?

โดยทั่วไป 3-5 วันทำการสำหรับใบสมัครที่สมบูรณ์ อาจใช้เวลานานกว่านี้หาก:

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

เริ่มกระบวนการตรวจสอบตั้งแต่เนิ่นๆ ในขณะที่สร้าง integration ของคุณ

ฉันสามารถเริ่มต้นด้วยการเปิดตัวขนาดเล็กได้หรือไม่?

ได้! เราขอแนะนำให้เปิดตัวนุ่มนวล:

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

สิ่งนี้ช่วยลดความเสี่ยงและช่วยให้คุณตรวจพบปัญหาได้เร็ว

ถ้าฉันต้องการกลับไปใช้ test mode ล่ะ?

คุณสามารถใช้ test mode ได้เสมอ:

  • Test mode ยังคงพร้อมใช้งานหลังจากเปิดใช้งานจริง
  • ใช้ test keys สำหรับฟีเจอร์ใหม่
  • ข้อมูล test mode แยกจาก live
  • ไม่มีผลกระทบต่อธุรกรรมจริง
ฉันต้องการการรับรอง PCI หรือไม่?

ผู้ค้าส่วนใหญ่ไม่จำเป็นต้องมีการรับรอง PCI แบบเต็มหากใช้:

  • Omise.js สำหรับ tokenization
  • Mobile SDKs
  • E-commerce plugins

คุณจำเป็นต้องมีการรับรอง PCI หาก:

  • คุณจัดการข้อมูลบัตรจริงโดยตรง
  • บัตรผ่าน servers ของคุณ
  • คุณเก็บข้อมูลบัตร

หากคุณได้รับการรับรอง PCI แจ้ง Omise ล่วงหน้า

ฉันสามารถเปลี่ยนกลับไปใช้ test keys หลังเปิดตัวได้หรือไม่?

ได้ แต่เข้าใจผลกระทบ:

  • การเปลี่ยนเป็น test keys หมายความว่าธุรกรรมจริงจะไม่ดำเนินการ
  • ลูกค้าจะไม่สามารถชำระเงินได้
  • เปลี่ยนกลับเฉพาะเมื่อคุณต้องการหยุดรับชำระเงิน

สำหรับการทดสอบฟีเจอร์ใหม่ ใช้ test environment แยกต่างหากด้วย test keys ไม่ใช่ระบบ production ของคุณ

จะเกิดอะไรขึ้นถ้ามีอะไรผิดพลาด?

มีแผน rollback:

  1. เก็บเวอร์ชันก่อนหน้าให้สามารถ deploy ได้
  2. จดบันทึกขั้นตอน rollback
  3. ทดสอบขั้นตอน rollback
  4. มีทีมพร้อมรองรับสำหรับการเปิดตัว

หากเกิดปัญหา:

  1. เปลี่ยนเป็นหน้า maintenance หากจำเป็น
  2. Rollback ไปยังเวอร์ชันก่อนหน้า
  3. ตรวจสอบปัญหา
  4. แก้ไขและทดสอบอย่างละเอียด
  5. Deploy ใหม่

ติดต่อ support@omise.co ทันทีสำหรับปัญหาเร่งด่วน

ทรัพยากร

เคล็ดลับสุดท้าย

  1. อย่าเร่งรีบ: ใช้เวลาทดสอบอย่างละเอียด
  2. เริ่มต้นเล็ก: เปิดตัวนุ่มนวลด้วยปริมาณจำกัด
  3. ตรวจสอบอย่างใกล้ชิด: ดูทุกอย่างในช่วงสองสามวันแรก
  4. เตรียมการสนับสนุน: บรรยายสรุปทีมของคุณ
  5. สื่อสาร: บอกลูกค้าเกี่ยวกับตัวเลือกการชำระเงินใหม่
  6. จดบันทึก: เก็บบันทึกปัญหาและวิธีแก้ไข
  7. ปรับปรุง: ปรับปรุงอย่างต่อเนื่องตามข้อมูล

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

มีคำถามหรือไม่? ติดต่อ support@omise.co - เราพร้อมช่วยเหลือ!