प्रॉम्प्ट लाइब्रेरी पर वापस जाएं
प्रॉम्प्ट लाइब्रेरीचैट प्रॉम्प्ट

पेमेंट webhook audit

idempotency, replay safety, credit writes और customer-visible failure handling के लिए payment webhook path की audit करें।

पेमेंटसिक्योरिटीइंजीनियरिंग
प्रीव्यू

चैट प्रॉम्प्ट

सुझाया गया मॉडल

GPT-5.2 Codex

आउटपुट प्रारूप

Webhook audit नोट

प्रीव्यू

चैट प्रॉम्प्ट

चैट थ्रेड

Checkout completed events credits add करते हैं। Retry events दो बार arrive हो सकते हैं। Wallet page credit ledger पढ़ता है।

Idempotency: credit write से पहले event ID unique होना चाहिए. Replay safety: signature और timestamp tolerance verify करें. Credit write: ledger entry checkout session को reference करे. Customer-visible failure: payment succeeded लेकिन credit write failed हो तो pending review दिखाएं. Test gap: duplicate event और out-of-order event cases.

आउटपुट

Idempotency / replay safety / credit write / customer-visible failure / test gap जांच

idempotency, replay safety, credit writes और customer-visible failure handling के लिए payment webhook path की audit करें।

पूरा प्रॉम्प्ट

पेमेंट webhook audit

idempotency, replay safety, credit writes और customer-visible failure handling के लिए payment webhook path की audit करें।

सुझाया गया मॉडल: GPT-5.2 Codexआउटपुट प्रारूप: Webhook audit नोट
पूरा प्रॉम्प्ट
चैट प्रॉम्प्ट
आप payment webhook implementation audit करने वाले backend engineer हैं। provided notes को ऐसी practical review में बदलें जिस पर team action ले सके। answer में ये sections लौटाएं: Idempotency, replay safety, credit write, customer-visible failure, test gap। हर claim को provided notes पर ground करें। facts missing हों तो उन्हें mark करें, invent न करें।

उपयोग नोट

real notes, constraints और source material paste करें। private data तब तक न डालें जब तक review के लिए जरूरी न हो।

प्रॉम्प्ट के अक्सर पूछे जाने वाले सवाल

इस प्रॉम्प्ट का उपयोग करने से पहले

इनपुट, मॉडल की उपयुक्तता और नतीजा कमजोर किए बिना टेम्पलेट बदलने के तरीके की तेज जांच।

Payment Webhook Audit कब इस्तेमाल करना चाहिए?

idempotency, replay safety, credit writes और customer-visible failure handling के लिए payment webhook path की audit करें। यह तब उपयोगी है जब आपके पास notes, constraints या rough draft पहले से हों और team-reviewable structured next step चाहिए।

इसे चलाने से पहले मुझे क्या include करना चाहिए?

source material, audience, constraints, key facts और वे boundaries include करें जिनके बाहर answer को invent नहीं करना चाहिए। output Idempotency / replay safety / credit write / customer-visible failure / test gap के रूप में organized होता है।

थ्रेड प्रीव्यू

Checkout completed events credits add करते हैं। Retry events दो बार arrive हो सकते हैं। Wallet page credit ledger पढ़ता है।
Idempotency: credit write से पहले event ID unique होना चाहिए. Replay safety: signature और timestamp tolerance verify करें. Credit write: ledger entry checkout session को reference करे. Customer-visible failure: payment succeeded लेकिन credit write failed हो तो pending review दिखाएं. Test gap: duplicate event और out-of-order event cases.

आउटपुट

Idempotency / replay safety / credit write / customer-visible failure / test gap जांच

इस मोड के और प्रॉम्प्ट

चैट थ्रेड

हम छोटे ecommerce टीमों के लिए एक AI assistant बनाना चाहते हैं जो उत्पाद फोटो को campaign assets में बदल दे.

समस्या परिकल्पना: छोटे ecommerce टीमें कच्ची उत्पाद फोटो को चैनल-तैयार campaign assets में बदलते समय समय गंवाती हैं. सबसे जोखिमपूर्ण धारणाएं: फोटो गुणवत्ता पर्याप्त है, टीमें AI asset variations पर भरोसा करेंगी, और असली bottleneck समीक्षा समय है. शोध प्रश्न: campaign asset creation का मालिक कौन है, revisions कहां रुकते हैं, और कौन-सा गुणवत्ता मानक publishing रोकता है. सत्यापन योजना: 5 operators से interview करें, 3 prompt-led asset flows टेस्ट करें, और first approved asset तक लगने वाला समय तुलना करें. निर्णय गेट: तभी आगे बढ़ें जब टीमें अपने मौजूदा workflow से तेज publishable draft तक पहुंच सकें.

चैट थ्रेड

हम स्वतंत्र सलाहकारों के लिए एक नया AI notes product तलाश रहे हैं. इसे शोध ब्रीफ में बदलने में मेरी मदद करें.

उद्देश्य: तय करना कि स्वतंत्र सलाहकारों को AI notes workspace चाहिए या हल्का client-follow-up layer. कामकाजी धारणाएं: वे पहले से notes capture करते हैं, लेकिन synthesis और next-step drafting असंगत है. दर्शक: बार-बार client calls और सीमित operations support वाले स्वतंत्र सलाहकार. मुख्य प्रश्न: कौन-से notes billable work बनते हैं, calls के बाद क्या खो जाता है, और CRM tools कहां बहुत भारी लगते हैं. शोध योजना: 6 interviews चलाएं, 10 recent call-note workflows review करें, और एक follow-up brief prototype test करें.

चैट थ्रेड

यह हमारे AI product landing page की outline है। design से पहले बताएं कि क्या unclear है।

Core promise: दिख रहा है, लेकिन अभी भी concrete user outcome की बजाय feature की तरह framed है। Unclear point: page यह नहीं समझाता कि value सबसे पहले किसे मिलती है या signup के बाद workflow कैसे बदलता है। Example gap: hero के पास before-after examples, model output samples और एक छोटा trust signal जोड़ें। CTA issue: primary action बहुत अधिक explanation के बाद आता है; quick-use section के पास use-oriented CTA रखें। Revision plan: hero sharpen करें, outcome cards जोड़ें, फिर visuals polish करने से पहले objections rewrite करें।