A. Security & Data Safety · Prompt 9

Payments & Webhooks Deep Check

Get the free PDF

Why it matters

Payment bugs spend real money: access without paying, a double charge, or a paid order that never unlocks.

Modeled on

Stripe and Razorpay webhook guidance: signature checks, idempotency, and retries.

How to run this prompt

Switch to a mode that does not edit files. In Cursor that is Ask or Plan. In Claude Code that is Plan mode.
Paste the audit prompt. Wait for the report. It must stop and ask which IDs to fix.
Read the report. Keep the IDs you agree with.
Switch to a mode that can edit. Paste the fix prompt and the IDs you chose.
Switch back to the read-only mode and paste the same audit prompt again. Confirm those IDs are gone.

Cursor: audit in Ask mode or Plan mode. Fix in Agent mode.
Claude Code: audit in Plan mode (Shift+Tab cycles to it). Fix in Normal mode, which can edit.
Any other tool: audit in Chat, Discuss, or Plan mode, whichever answers without editing files. If the tool has no such mode, the prompt itself forbids edits. Fix in the mode that is allowed to edit files.

The audit prompt

MODE: AUDIT ONLY. Do not create, edit, or delete any file. Do not run commands
that change anything: no installs, migrations, git commits, deploys, or "--fix" flags.
If your tool has an Ask, Plan, Chat, or Discuss mode, use it for this prompt.

Before you start:
- Tell me the stack you detect (framework, language, database, auth, hosting,
  payment provider) and which folders you will review.
- If a check below does not apply to this stack, write "Not applicable" and why.
- If you can run read-only commands, run the ones listed. If you cannot, list them
  so I can run them and paste the output.

Payments & Webhooks Deep Check: what to check
Trace payment from checkout to fulfillment to refund. Do not send test charges unless I give you a sandbox key and ask you to.
1. Trace the flow in code: what the client sends, what the server computes, what the provider is asked to charge, and what grants access.
2. Confirm the server sets price, currency, quantity limits, tax, and discounts. The client should send product ids, not amounts. Cite the handler.
3. Confirm fulfillment runs from a verified webhook or a server-side status check. Flag fulfillment that runs because the browser hit a success URL or posted payment succeeded.
4. Webhook signatures must be checked on the raw body, before JSON parsing changes bytes. Stripe sends Stripe-Signature and a timestamp tolerance. Razorpay sends X-Razorpay-Signature as HMAC-SHA256 of the raw body. Say which provider this repo uses and whether the raw body is preserved.
5. Say whether the handler is idempotent (the same event id must not grant twice), responds quickly, and stores processed event ids. Out-of-order events should not grant access early.
6. Say what the code does on a declined card, an abandoned checkout, a 3-D Secure challenge, a timeout, a charge that succeeded but fulfillment failed, a refund, and a chargeback. If a branch is missing, say so.
7. Confirm test and live secrets are different env vars, and live secrets are not in the client bundle.
8. Say whether there is a way to compare provider payments to your orders and find paid-but-not-fulfilled or fulfilled-but-not-paid rows. If it is only a dashboard report, mark Needs manual check.
9. Confirm card numbers do not touch your server or logs. Hosted fields or a hosted checkout should collect them. Search logs and request types for pan, cvc, or card number fields.

Evidence rules:
- Every finding cites a file path and line number, or the exact command output used.
- Mark each finding Confirmed (seen in the code) or Needs manual check (depends on
  something outside the repo, such as a dashboard setting or production data).
- Never print a full secret. Show the first 4 characters and the location only.
- If you are not sure, say so. Do not invent files, settings, or results.

Severity: Critical = exploitable now, or leaks real data or money. High = serious
with little effort. Medium = weakens defenses or needs a second bug. Low = hygiene.

Report:
- Summary: count of findings by severity.
- Table: ID | Severity | Confirmed? | Finding | Evidence | Why it matters | Suggested fix | Effort
  (IDs for this prompt use the prefix P09, for example P09-1, P09-2.)
- Checked and fine: what you verified is already OK.
- Could not check: what I need to look at myself, and where.

Then stop. Do not fix anything. Ask me which IDs I want fixed.

Get the free PDF

Related prompts

Share this prompt

WhatsApp LinkedIn X

How to run this prompt

Switch to a mode that does not edit files. In Cursor that is Ask or Plan. In Claude Code that is Plan mode.

Paste the audit prompt. Wait for the report. It must stop and ask which IDs to fix.

Read the report. Keep the IDs you agree with.

Switch to a mode that can edit. Paste the fix prompt and the IDs you chose.

Switch back to the read-only mode and paste the same audit prompt again. Confirm those IDs are gone.

Cursor: audit in Ask mode or Plan mode. Fix in Agent mode.

Claude Code: audit in Plan mode (Shift+Tab cycles to it). Fix in Normal mode, which can edit.

Any other tool: audit in Chat, Discuss, or Plan mode, whichever answers without editing files. If the tool has no such mode, the prompt itself forbids edits. Fix in the mode that is allowed to edit files.

The audit prompt

MODE: AUDIT ONLY. Do not create, edit, or delete any file. Do not run commands that change anything: no installs, migrations, git commits, deploys, or "--fix" flags. If your tool has an Ask, Plan, Chat, or Discuss mode, use it for this prompt. Before you start: - Tell me the stack you detect (framework, language, database, auth, hosting, payment provider) and which folders you will review. - If a check below does not apply to this stack, write "Not applicable" and why. - If you can run read-only commands, run the ones listed. If you cannot, list them so I can run them and paste the output. Payments & Webhooks Deep Check: what to check Trace payment from checkout to fulfillment to refund. Do not send test charges unless I give you a sandbox key and ask you to. 1. Trace the flow in code: what the client sends, what the server computes, what the provider is asked to charge, and what grants access. 2. Confirm the server sets price, currency, quantity limits, tax, and discounts. The client should send product ids, not amounts. Cite the handler. 3. Confirm fulfillment runs from a verified webhook or a server-side status check. Flag fulfillment that runs because the browser hit a success URL or posted payment succeeded. 4. Webhook signatures must be checked on the raw body, before JSON parsing changes bytes. Stripe sends Stripe-Signature and a timestamp tolerance. Razorpay sends X-Razorpay-Signature as HMAC-SHA256 of the raw body. Say which provider this repo uses and whether the raw body is preserved. 5. Say whether the handler is idempotent (the same event id must not grant twice), responds quickly, and stores processed event ids. Out-of-order events should not grant access early. 6. Say what the code does on a declined card, an abandoned checkout, a 3-D Secure challenge, a timeout, a charge that succeeded but fulfillment failed, a refund, and a chargeback. If a branch is missing, say so. 7. Confirm test and live secrets are different env vars, and live secrets are not in the client bundle. 8. Say whether there is a way to compare provider payments to your orders and find paid-but-not-fulfilled or fulfilled-but-not-paid rows. If it is only a dashboard report, mark Needs manual check. 9. Confirm card numbers do not touch your server or logs. Hosted fields or a hosted checkout should collect them. Search logs and request types for pan, cvc, or card number fields. Evidence rules: - Every finding cites a file path and line number, or the exact command output used. - Mark each finding Confirmed (seen in the code) or Needs manual check (depends on something outside the repo, such as a dashboard setting or production data). - Never print a full secret. Show the first 4 characters and the location only. - If you are not sure, say so. Do not invent files, settings, or results. Severity: Critical = exploitable now, or leaks real data or money. High = serious with little effort. Medium = weakens defenses or needs a second bug. Low = hygiene. Report: - Summary: count of findings by severity. - Table: ID | Severity | Confirmed? | Finding | Evidence | Why it matters | Suggested fix | Effort (IDs for this prompt use the prefix P09, for example P09-1, P09-2.) - Checked and fine: what you verified is already OK. - Could not check: what I need to look at myself, and where. Then stop. Do not fix anything. Ask me which IDs I want fixed.