Copy page

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

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

เริ่มต้นใช้งาน

ฉันควรอ่านอะไรก่อนก่อนที่จะรวมเข้ากับ Brick

เริ่มต้นด้วยกระแสธุรกิจที่คุณต้องการสนับสนุน จากนั้นแม็ปกับผลิตภัณฑ์ Brick ที่เกี่ยวข้อง:

เป้าหมาย	เริ่มที่นี่
ทำความเข้าใจผลิตภัณฑ์และความสามารถของ Brick	What is Brick?
เตรียมการเข้าถึงแดชบอร์ดและการตั้งค่าบัญชี	Brick Dashboard Overview
เตรียมข้อมูลรับรอง API และ URL พื้นฐาน	Prepare Yourself to Use API
ทำความเข้าใจการรับรองความถูกต้องและสภาพแวดล้อม	Authentication and Environment
ตรวจสอบความคาดหวังด้านความปลอดภัย	Security at Brick

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

จะต้องทำอะไรให้เสร็จสิ้นก่อนจึงจะเข้าถึงการผลิตได้?

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

อย่างน้อยที่สุด กรอก:

• การตรวจสอบ KYB
• การตั้งค่าบัญชีแดชบอร์ด
• คีย์ API และการเตรียมข้อมูลลับสำหรับสภาพแวดล้อมที่ถูกต้อง
• การกำหนดค่า URL โทรกลับ
• การทดสอบภายในใน Sandbox
• การตรวจสอบความพร้อมในการผลิตสำหรับการลองใหม่ การจัดการสถานะ การบันทึก และการกระทบยอด

อ้างอิง:

• Verify Your Account (KYB)
• Authentication and Environment
• Production Checklist

ฉันสามารถใช้การผลิต APIs ก่อนที่ KYB จะได้รับการอนุมัติได้หรือไม่

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

ความแตกต่างระหว่าง Sandbox และการผลิตคืออะไร?

Sandbox มีไว้สำหรับการทดสอบการพัฒนาและบูรณาการ ใช้ข้อมูลรับรอง Sandbox, URL ฐาน Sandbox และจำลองหรือทดสอบพฤติกรรมการทำธุรกรรม

การผลิตประมวลผลธุรกรรมจริงและใช้ข้อมูลประจำตัวการผลิต URL ฐานการผลิต และการชำระบัญชีจริงหรือพฤติกรรมเครือข่ายธนาคาร

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

การรับรองความถูกต้องและโทเค็น

ฉันควรใช้โทเค็นใด

Brick มีขั้นตอนการรับรองความถูกต้องมากกว่าหนึ่งขั้นตอน ใช้โทเค็นที่ตรงกับตระกูล API ที่คุณกำลังโทรหา

ครอบครัว API	โทเค็นหรือโฟลว์ข้อมูลรับรอง	หมายเหตุ
ทั่วไป Brick APIs	โทเค็นการเข้าถึงสาธารณะจาก Generate Public Access Token	โทเค็นอายุสั้นที่ใช้สำหรับคำขอ API ทั่วไป
QRIS SNAP APIs	โทเค็นการเข้าถึง SNAP B2B จาก Get Access Token (SNAP)	ขั้นตอนการตรวจสอบสิทธิ์เฉพาะ QRIS SNAP
การกระทำของแดชบอร์ด	การเข้าถึงของผู้ใช้แดชบอร์ด	จัดการจากแดชบอร์ด Brick ไม่ใช่โฟลว์โทเค็น API

หากคุณกำลังรวม QRIS SNAP อย่าถือว่าโทเค็นการเข้าถึงสาธารณะทั่วไปเป็นโทเค็น SNAP เริ่มต้นด้วยโฟลว์โทเค็น QRIS SNAP

ทำไมฉันถึงได้รับ 401 Unauthorized?

สาเหตุทั่วไป ได้แก่:

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

การตรวจสอบที่แนะนำ:

1. ยืนยัน URL ฐาน
2. ยืนยันว่าคู่ข้อมูลรับรองเป็นของสภาพแวดล้อมนั้น
3. สร้างโทเค็นใหม่
4. สร้างส่วนหัวคำขอใหม่
5. เปรียบเทียบคำขอกับการอ้างอิง API ที่เกี่ยวข้อง

อ้างอิง:

• Authentication and Environment
• Generate Public Access Token
• Get Access Token (SNAP)

เหตุใดโทเค็นของฉันจึงล้มเหลวอย่างต่อเนื่องหลังจากลองอีกครั้ง

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

สำหรับระบบที่ใช้งานจริง ให้สร้างโทเค็นเป็นส่วนหนึ่งของโฟลว์คำขอที่มีการควบคุม แทนที่จะแคชโทเค็นมากเกินไป

ฉันจะรักษาความปลอดภัยข้อมูลรับรอง API ได้อย่างไร

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

แนวทางปฏิบัติที่แนะนำ:

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

อ้างอิง:

• Security at Brick

พฤติกรรม API

การตอบสนองของ API ที่สำเร็จหมายความว่าธุรกรรมเสร็จสมบูรณ์หรือไม่

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

สร้างระบบของคุณตามสถานะการทำธุรกรรมขั้นสุดท้าย ไม่ใช่แค่การตอบสนอง API ครั้งแรก

ฉันควรพึ่งพาการโทรกลับหรือสถานะ APIs หรือไม่

ใช้ทั้งสองอย่างโดยมีความรับผิดชอบที่ชัดเจน:

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

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

อ้างอิง:

• Error Handling
• Regular Disbursement Callback
• Callback Virtual Account
• Callback E-wallet Payment

ฉันสามารถใช้รหัสอ้างอิงเดียวกันซ้ำได้หรือไม่

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

รูปแบบที่แนะนำ:

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

ฉันควรจัดการกับการหมดเวลาอย่างไร?

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

การไหลที่แนะนำ:

1. บันทึกรหัสอ้างอิงคำขอ
2. สอบถามจุดสิ้นสุดสถานะที่เกี่ยวข้อง
3. รอการติดต่อกลับหากสถานะยังค้างอยู่
4. ลองอีกครั้งเฉพาะเมื่อการผสานรวมของคุณสามารถทำได้อย่างปลอดภัยด้วยการป้องกันค่าเดิม

อ้างอิง:

• Error Handling

โทรกลับ

ทำไมฉันถึงไม่ได้รับการติดต่อกลับ?

ตรวจสอบสิ่งต่อไปนี้:

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

หากคุณเพิ่งเปลี่ยน URL เรียกกลับ ให้ทดสอบอีกครั้งใน Sandbox ก่อนที่จะใช้จริงในเวอร์ชันที่ใช้งานจริง

ตัวจัดการการติดต่อกลับของฉันควรทำอย่างไร?

รักษาการประมวลผลการโทรกลับให้เชื่อถือได้และสั้น:

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

หลีกเลี่ยงตรรกะทางธุรกิจที่ใช้เวลานานโดยตรงภายในเส้นทางการตอบสนองการโทรกลับ

จะเกิดอะไรขึ้นหากมีการติดต่อกลับก่อนที่ส่วนหน้าของฉันจะได้รับการอัปเดต?

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

ส่งเงิน: การเบิกจ่าย

ฉันควรใช้วิธีการชำระเงินแบบใด?

เลือกตามความต้องการในการดำเนินงานของคุณ:

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

ยืนยันความครอบคลุม ขีดจำกัด และลักษณะการทำงานในปัจจุบันในหน้า API ก่อนเผยแพร่เสมอ

อ้างอิง:

• BIFAST Disbursement API
• Regular Disbursement
• List of Bank Coverage

ฉันควรตรวจสอบบัญชีธนาคารก่อนชำระเงินหรือไม่

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

อ้างอิง:

• Account Validation

เหตุใดการเบิกจ่ายจึงติดอยู่ใน PENDING?

เหตุผลที่เป็นไปได้:

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

การตรวจสอบที่แนะนำ:

1. ค้นหาตามรหัสอ้างอิงของคุณ
2. ตรวจสอบสถานะด้วยรหัสการเบิกจ่ายหรือรหัสอ้างอิง
3. ตรวจสอบบันทึกการโทรกลับ
4. ยืนยันว่าธนาคารปลายทางประสบความล่าช้าหรือไม่

อ้างอิง:

• Check Status by Disbursement ID
• Check Status by Reference ID
• BIFAST Callback
• Regular Callback

เหตุใดยอดคงเหลือของฉันจึงแตกต่างจากบัญชีแยกประเภทหรือประวัติการทำธุรกรรม?

มุมมองที่แตกต่างกันสามารถตอบคำถามที่แตกต่างกัน:

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

ใช้บัญชีแยกประเภทและประวัติธุรกรรมสำหรับการกระทบยอด ไม่ใช่แค่ยอดแดชบอร์ดเท่านั้น

อ้างอิง:

• Ledger / Disbursement History
• Transaction History
• Export Data

ฉันจะแสดงหลักฐานการโอนเงินได้อย่างไร?

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

อ้างอิง:

• Download Transfer Proof API

รับเงิน

Open VA และ Closed VA แตกต่างกันอย่างไร?

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

อ้างอิง:

• Virtual Account Overview
• Generate Open VA
• Generate Close VA

เหตุใดการชำระเงิน VA จึงยังไม่สะท้อนให้เห็น

สาเหตุที่เป็นไปได้:

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

การตรวจสอบที่แนะนำ:

1. ตรวจสอบบันทึกการส่งโทรกลับ
2. สอบถามสถานะ VA
3. ยืนยันจำนวนเงินที่ชำระและตัวระบุ VA
4. กระทบยอดกับประวัติการทำธุรกรรมหากจำเป็น

อ้างอิง:

• Callback Virtual Account
• Status of Open VA
• Status of Close VA

อะไรคือความแตกต่างระหว่าง Static QRIS, Dynamic QRIS และ QRIS SNAP?

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

หากคุณใช้ QRIS SNAP ให้เริ่มต้นด้วยโฟลว์โทเค็น SNAP ก่อนที่จะสร้างหรือสืบค้นธุรกรรม QRIS

อ้างอิง:

• QRIS Overview
• Generate Dynamic QRIS
• Get Access Token (SNAP)
• Generate Dynamic QRIS (SNAP)

เหตุใดฉันจึงไม่สามารถสร้าง QRIS ได้

สาเหตุทั่วไป ได้แก่:

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

อ้างอิง:

• Registering for QRIS
• QRIS Testing in Sandbox
• Dynamic QRIS Status (SNAP)

ฉันควรใช้ E-Wallet หรือหน้าชำระเงินเมื่อใด

ใช้ e-wallet APIs เมื่อคุณต้องการสร้างและควบคุมขั้นตอนการชำระเงิน e-wallet โดยตรงจากระบบของคุณ

ใช้หน้าชำระเงินเมื่อคุณต้องการหน้าการชำระเงินที่โฮสต์พร้อมประสบการณ์การชำระเงินที่จัดการโดย Brick การเปลี่ยนเส้นทาง และการจัดการสถานะการชำระเงิน

อ้างอิง:

• E-Wallet Overview
• Create E-Wallet Payment Link
• Checkout Page Overview
• Create Checkout Page Session

เหตุใดการชำระเงินผ่าน e-wallet หรือ checkout จึงยังคงค้างชำระ?

สาเหตุที่เป็นไปได้:

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

การตรวจสอบที่แนะนำ:

1. สอบถามสถานะการชำระเงิน
2. ตรวจสอบบันทึกการโทรกลับ
3. ยืนยันเวลาหมดอายุการชำระเงิน
4. ยืนยันพฤติกรรมการเปลี่ยนเส้นทางของลูกค้า

อ้างอิง:

• Status E-wallet Payment
• Callback E-wallet Payment
• Checkout Status

การกระทบยอดและการปฏิบัติการ

ฉันควรจัดเก็บข้อมูลใดเพื่อการกระทบยอด

จัดเก็บข้อมูลให้เพียงพอเพื่อติดตามแต่ละธุรกรรมในระบบของคุณ, Brick, โทรกลับ และเครื่องมือสนับสนุนลูกค้า:

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

ทำให้การสนับสนุน การกระทบยอดทางการเงิน และการตรวจสอบเหตุการณ์รวดเร็วขึ้นมาก

ฉันควรกระทบยอดสถานะธุรกรรมบ่อยแค่ไหน?

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

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

ฉันควรทำอย่างไรก่อนจะถ่ายทอดสด?

ใช้การทบทวนความพร้อมในการผลิต:

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

อ้างอิง:

• Production Checklist

การแก้ไขปัญหาและการสนับสนุน

ฉันควรให้ข้อมูลอะไรบ้างเมื่อรายงานปัญหา?

รวม:

• สภาพแวดล้อม: Sandbox หรือการผลิต
• สินค้า: การเบิกจ่าย, VA, QRIS, กระเป๋าเงินอิเล็กทรอนิกส์, การชำระเงิน หรือผลิตภัณฑ์อื่น
• ปลายทางถูกเรียก
• รหัสอ้างอิงของคุณ
• รหัสธุรกรรม Brick รหัสการชำระเงิน หรือรหัสการชำระเงิน หากมี
• การประทับเวลาด้วยเขตเวลา
• ขอตัวอย่างเพย์โหลดโดยลบข้อมูลลับออก
• เนื้อหาการตอบสนองและรหัสสถานะ HTTP
• เพย์โหลดการโทรกลับหรือบันทึกการจัดส่งการโทรกลับ หากเกี่ยวข้อง
• ผลลัพธ์ที่คาดหวังและผลลัพธ์ที่แท้จริง

อย่าส่งความลับ API คีย์ส่วนตัว หรือส่วนหัวการให้สิทธิ์แบบเต็มในข้อความสนับสนุน

อ้างอิง:

• Error Handling

BrickI หรือ Brick MCP สามารถช่วยในระหว่างการนำไปใช้งานได้อย่างไร?

ใช้ Meet BrickI เมื่อคุณต้องการความช่วยเหลือพร้อมคำแนะนำหรือช่วยค้นหาเส้นทางเอกสารที่ถูกต้อง

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

สำหรับการเปลี่ยนแปลงการผลิต ให้ตรวจสอบเอาต์พุตที่ AI สร้างขึ้นกับเอกสารอย่างเป็นทางการ พฤติกรรมของ Sandbox และกระบวนการตรวจสอบทางวิศวกรรมภายในของคุณเสมอ