Tillbaka till promptbiblioteket
PromptbibliotekChattprompt

Granskning av betalningswebhook

Granska en betalningswebhook-väg för idempotens, skydd mot replay, credit-skrivningar och kundsynlig felhantering.

BetalningSäkerhetIngenjörsarbete
Förhandsvisning

Chattprompt

Rekommenderad modell

GPT-5.2 Codex

Outputformat

Anteckning för webhookgranskning

Förhandsvisning

Chattprompt

chattråd

Checkout completed-händelser lägger till credits. Retry-händelser kan komma två gånger. Wallet-sidan läser credit-ledgern.

Idempotens: event-ID måste vara unikt före credit-skrivningen. Replay-säkerhet: verifiera signatur och tolerans för tidsstämpel. Credit-skrivning: ledgerposten bör referera till checkout-sessionen. Kundsynligt fel: visa väntar på granskning om betalningen lyckades men credit-skrivningen misslyckades. Testlucka: fall med duplicerad händelse och händelser i fel ordning.

Resultat

Idempotens / replay-säkerhet / credit-skrivning / kundsynligt fel / testlucka

Granska en betalningswebhook-väg för idempotens, replay-säkerhet, credit-skrivningar och kundsynlig felhantering.

Fullständig prompt

Granskning av betalningswebhook

Granska en betalningswebhook-väg för idempotens, replay-säkerhet, credit-skrivningar och kundsynlig felhantering.

Rekommenderad modell: GPT-5.2 CodexOutputformat: Anteckning för webhookgranskning
Fullständig prompt
Chattprompt
Du är en backendingenjör som granskar en betalningswebhook-implementation. Gör om de bifogade anteckningarna till en praktisk granskning som ett team kan agera på. Returnera svaret med: Idempotens, replay-säkerhet, credit-skrivning, kundsynligt fel, testlucka. Förankra varje påstående i de bifogade anteckningarna. Markera saknade fakta i stället för att hitta på dem.

Användningsanteckningar

Klistra in de verkliga anteckningarna, begränsningarna och källmaterialet. Håll privata data utanför om de inte är nödvändiga för granskningen.

Prompt-FAQ

Innan du använder denna prompt

Snabba kontroller för inmatningar, modellpassning och hur du anpassar mallen utan att försvaga resultatet.

När bör jag använda Granskning av betalningswebhook?

Granska en betalningswebhook-väg för idempotens, replay-säkerhet, credit-skrivningar och kundsynlig felhantering. Använd den när du redan har anteckningar, begränsningar eller ett grovt utkast och behöver ett strukturerat nästa steg som ett team kan granska.

Vad bör jag inkludera innan jag kör den?

Inkludera källmaterialet, målgruppen, begränsningarna, nyckelfakta och gränserna som svaret inte får hitta på. Resultatet organiseras som Idempotens / replay-säkerhet / credit-skrivning / kundsynligt fel / testlucka.

Trådförhandsvisning

Checkout completed-händelser lägger till credits. Retry-händelser kan komma två gånger. Wallet-sidan läser credit-ledgern.
Idempotens: event-ID måste vara unikt före credit-skrivningen. Replay-säkerhet: verifiera signatur och tolerans för tidsstämpel. Credit-skrivning: ledgerposten bör referera till checkout-sessionen. Kundsynligt fel: visa väntar på granskning om betalningen lyckades men credit-skrivningen misslyckades. Testlucka: fall med duplicerad händelse och händelser i fel ordning.

Resultat

Idempotens / replay-säkerhet / credit-skrivning / kundsynligt fel / testlucka

Fler prompter i detta läge

chattråd

Vi vill bygga en AI-assistent för små e-handelsteam som gör produktfoton till kampanjtillgångar.

Problemhypotes: små e-handelsteam förlorar tid när de gör råa produktfoton till kanalredo kampanjtillgångar. Mest riskfyllda antaganden: fotokvaliteten är tillräckligt hög, team litar på AI-baserad tillgångsvariation och granskningstid är den verkliga flaskhalsen. Forskningsfrågor: vem äger skapandet av kampanjtillgångar, var fastnar revideringar och vilken kvalitetsnivå blockerar publicering. Valideringsplan: intervjua 5 operatörer, testa 3 promptstyrda tillgångsflöden och jämför tid till första godkända tillgång. Beslutsgrind: fortsätt endast om team kan nå ett publicerbart utkast snabbare än i sitt nuvarande arbetsflöde.

chattråd

Vi utforskar en ny AI-anteckningsprodukt för solokonsulter. Hjälp mig att göra detta till en researchbrief.

Mål: definiera om solokonsulter behöver en AI-arbetsyta för anteckningar eller ett lättare lager för klientuppföljning. Arbetsantaganden: de fångar redan anteckningar, men syntes och utkast till nästa steg är ojämna. Målgrupp: solokonsulter med återkommande klientsamtal och begränsat operativt stöd. Nyckelfrågor: vilka anteckningar blir fakturerbart arbete, vad går förlorat efter samtal och var känns CRM-verktyg för tunga. Researchplan: genomför 6 intervjuer, granska 10 aktuella arbetsflöden för samtalsanteckningar och testa en prototyp för en uppföljningsbrief.

chattråd

Här är dispositionen för vår AI-produktlandningssida. Säg vad som är otydligt innan vi designar den.

Kärnlöfte: synligt, men fortfarande formulerat som en funktion snarare än ett konkret användarresultat. Otydlig punkt: sidan förklarar inte vem som får värde först eller vilket arbetsflöde som förändras efter registrering. Exempellucka: lägg till före-efter-exempel, exempel på modelloutput och en kort förtroendesignal nära heron. CTA-problem: den primära åtgärden kommer efter för mycket förklaring; flytta en användningsorienterad CTA närmare quick-use-sektionen. Revideringsplan: skärp heron, lägg till resultatkort och skriv sedan om invändningarna innan visuella detaljer poleras.