กลับไปที่คลังพรอมป์
คลังพรอมป์พรอมป์แชต

การตรวจสอบ Webhook การชำระเงิน

ตรวจสอบเส้นทาง payment webhook ในเรื่อง idempotency ความปลอดภัยจากการ replay การเขียนเครดิต และการจัดการความล้มเหลวที่ลูกค้ามองเห็นได้

การชำระเงินความปลอดภัยวิศวกรรม
ตัวอย่าง

พรอมป์แชต

โมเดลแนะนำ

GPT-5.2 Codex

รูปแบบผลลัพธ์

บันทึกตรวจสอบ Webhook

ตัวอย่าง

พรอมป์แชต

เธรดแชต

อีเวนต์ checkout completed จะเพิ่มเครดิต อีเวนต์ retry อาจมาถึงซ้ำสองครั้ง หน้า Wallet อ่านข้อมูลจาก credit ledger

Idempotency: event ID ต้องไม่ซ้ำก่อนเขียนเครดิต Replay safety: ตรวจสอบลายเซ็นและช่วงยอมรับ timestamp Credit write: รายการใน ledger ควรอ้างอิง checkout session Customer-visible failure: หากชำระเงินสำเร็จแต่เขียนเครดิตล้มเหลว ให้แสดงสถานะรอการตรวจสอบ Test gap: เคสอีเวนต์ซ้ำและอีเวนต์มาผิดลำดับ

ผลลัพธ์

idempotency / ความปลอดภัยเมื่อ replay / การเขียนเครดิต / failure ที่ลูกค้าเห็น / ช่องว่างการทดสอบ

ตรวจสอบเส้นทาง payment webhook ในเรื่อง idempotency ความปลอดภัยจากการ replay การเขียนเครดิต และการจัดการความล้มเหลวที่ลูกค้ามองเห็นได้

พรอมป์เต็ม

การตรวจสอบ Webhook การชำระเงิน

ตรวจสอบเส้นทาง payment webhook ในเรื่อง idempotency ความปลอดภัยจากการ replay การเขียนเครดิต และการจัดการความล้มเหลวที่ลูกค้ามองเห็นได้

โมเดลแนะนำ: GPT-5.2 Codexรูปแบบผลลัพธ์: บันทึกตรวจสอบ Webhook
พรอมป์เต็ม
พรอมป์แชต
คุณคือวิศวกรแบ็กเอนด์ที่กำลังตรวจสอบการติดตั้ง payment webhook แปลงบันทึกที่ให้มาให้เป็นผลรีวิวเชิงปฏิบัติที่ทีมสามารถนำไปดำเนินการได้ ส่งคำตอบโดยมีหัวข้อ: Idempotency, replay safety, credit write, customer-visible failure, test gap ยึดทุกข้อกล่าวอ้างกับบันทึกที่ให้มา ระบุข้อเท็จจริงที่ขาดหายแทนการแต่งขึ้นเอง

หมายเหตุการใช้งาน

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

FAQ ของพรอมป์

ก่อนใช้พรอมป์นี้

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

ควรใช้ Payment Webhook Audit เมื่อใด

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

ควรใส่อะไรก่อนเรียกใช้งาน

ใส่แหล่งข้อมูล กลุ่มผู้อ่าน ข้อจำกัด ข้อเท็จจริงสำคัญ และขอบเขตที่คำตอบต้องไม่แต่งขึ้นเอง เอาต์พุตจะจัดตาม Idempotency / replay safety / credit write / customer-visible failure / test gap

ตัวอย่างเธรด

อีเวนต์ checkout completed จะเพิ่มเครดิต อีเวนต์ retry อาจมาถึงซ้ำสองครั้ง หน้า Wallet อ่านข้อมูลจาก credit ledger
Idempotency: event ID ต้องไม่ซ้ำก่อนเขียนเครดิต Replay safety: ตรวจสอบลายเซ็นและช่วงยอมรับ timestamp Credit write: รายการใน ledger ควรอ้างอิง checkout session Customer-visible failure: หากชำระเงินสำเร็จแต่เขียนเครดิตล้มเหลว ให้แสดงสถานะรอการตรวจสอบ Test gap: เคสอีเวนต์ซ้ำและอีเวนต์มาผิดลำดับ

ผลลัพธ์

idempotency / ความปลอดภัยเมื่อ replay / การเขียนเครดิต / failure ที่ลูกค้าเห็น / ช่องว่างการทดสอบ

พรอมป์เพิ่มเติมในโหมดนี้

เธรดแชต

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

สมมติฐานปัญหา: ทีมอีคอมเมิร์ซขนาดเล็กเสียเวลาในการเปลี่ยนภาพสินค้าดิบให้เป็นแอสเซ็ตแคมเปญพร้อมใช้ในแต่ละช่องทาง สมมติฐานที่เสี่ยงที่สุด: คุณภาพภาพสูงพอ ทีมเชื่อถือการสร้างรูปแบบแอสเซ็ตด้วย AI และเวลาตรวจทานคือคอขวดจริง คำถามวิจัย: ใครเป็นเจ้าของการสร้างแอสเซ็ตแคมเปญ การแก้ไขติดขัดตรงไหน และมาตรฐานคุณภาพใดที่ขวางการเผยแพร่ แผนตรวจสอบ: สัมภาษณ์ operator 5 คน ทดสอบ flow สร้างแอสเซ็ตด้วยพรอมป์ต์ 3 แบบ และเปรียบเทียบเวลาจนได้แอสเซ็ตที่อนุมัติครั้งแรก เกตตัดสินใจ: ไปต่อเฉพาะเมื่อทีมสามารถได้ดราฟต์ที่เผยแพร่ได้เร็วกว่ากระบวนการปัจจุบัน

เธรดแชต

เรากำลังสำรวจผลิตภัณฑ์โน้ต AI ใหม่สำหรับที่ปรึกษาเดี่ยว ช่วยเปลี่ยนเรื่องนี้ให้เป็นบรีฟวิจัย

วัตถุประสงค์: ระบุว่าที่ปรึกษาเดี่ยวต้องการ workspace โน้ต AI หรือเลเยอร์ติดตามลูกค้าที่เบากว่า สมมติฐานที่ใช้ทำงาน: พวกเขาจดโน้ตอยู่แล้ว แต่การสังเคราะห์และร่างขั้นตอนถัดไปยังไม่สม่ำเสมอ กลุ่มเป้าหมาย: ที่ปรึกษาเดี่ยวที่มีสายคุยลูกค้าซ้ำและมีซัพพอร์ตด้านปฏิบัติการจำกัด คำถามหลัก: โน้ตแบบใดกลายเป็นงานที่คิดเงินได้ อะไรตกหล่นหลังการคุย และเครื่องมือ CRM หนักเกินไปตรงไหน แผนวิจัย: สัมภาษณ์ 6 คน ทบทวนเวิร์กโฟลว์โน้ตการโทรล่าสุด 10 ชุด และทดสอบต้นแบบบรีฟติดตามผลหนึ่งแบบ

เธรดแชต

นี่คือโครงหน้า Landing Page สำหรับผลิตภัณฑ์ AI ของเรา ช่วยบอกหน่อยว่าอะไรยังไม่ชัดเจนก่อนที่เราจะออกแบบ

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