Laravel Payment Flow Smoke Test and Edge Case Planner

Public field comparison

Laravel Payment Flow Smoke Test and Edge Case Planner

Laravel Payment Flow Smoke Test and Edge Case Planner

Plan safe smoke tests and edge-case coverage for Laravel payment flows, including checkout, webhooks, retries, duplicates, refunds, entitlements, and manual review.

Use Codex to inspect supplied Laravel payment code and produce an evidence-linked plan for safely testing checkout, signed webhooks, idempotency, retries, refunds, entitlements, subscriptions, and manual review without implying that tests were run or changes were made.

Use this for designing Laravel payment flow smoke tests covering checkout success, failure, webhooks, retries, duplicate events, refunds, entitlements, and manual review paths.

Use this prompt to prepare an evidence-linked Laravel payment smoke-test and edge-case plan covering checkout, signed webhooks, idempotency, retries, refunds, subscriptions, entitlements, manual review, and safe provider-sandbox verification without implying that tests or financial actions occurred.

Laravel payment smoke testing
Webhook edge-case planning
Checkout regression coverage
Duplicate payment prevention review
Manual payment review workflow
Subscription upgrade testing
Sandbox payment verification

Planning evidence-backed smoke tests for an existing Laravel checkout flow
Designing replay, signature, ordering, and idempotency coverage for Laravel payment webhooks
Building regression coverage for duplicate checkout, fulfillment, notification, and entitlement side effects
Reviewing Laravel refund and manual payment-review state transitions before implementation
Planning subscription upgrade or downgrade tests involving invoices, retries, and entitlement changes
Defining safe provider-sandbox verification separately from local fake and mock coverage

Payment provider and flow
Checkout and webhook routes
Payment, order, or subscription models
Success, failure, refund, and manual review rules
Idempotency, retry, and duplicate event concerns
Existing tests and sandbox or fake setup
Allowed files and verification commands

Payment provider and flow
Checkout and webhook routes
Payment, order, or subscription models
Success, failure, refund, and manual review rules
Idempotency, retry, and duplicate event concerns
Existing tests and sandbox or fake setup
Execution boundaries and verification commands

Fill in the variables with the payment provider, checkout and webhook routes, payment/order/subscription models, success/failure/refund/manual review rules, idempotency concerns, existing tests, sandbox or fake setup, allowed files, and verification commands. Then run the complete prompt on Codex before editing payment code or running payment checks.

Open the relevant Laravel repository in Codex and replace every bracketed variable with the application-specific payment information requested.

Provide the relevant routes, controllers, webhook handlers, services, provider adapters, models, migrations, state rules, queue behavior, existing tests, sanitized logs, provider documentation references, and non-secret sandbox or fake configuration.

Do not paste live credentials, webhook signing secrets, access tokens, raw cardholder data, complete payment records, real customer payment methods, or unnecessary personal information.

State clearly whether Codex may perform read-only repository inspection, run non-mutating local diagnostics, edit files, execute local tests, make database changes, or access a provider sandbox. Treat provider calls, sandbox mutations, migrations, production access, real charges, refunds, webhook replay, and other financial actions as separately controlled activities.

Run the prompt, then review the evidence ledger, lifecycle map, financial invariants, smoke-test suite, edge-case backlog, verification runbook, and unresolved approval gates. Local fake or mock results do not prove provider-sandbox or production behavior.

A Laravel app is adding a subscription upgrade flow and needs safe smoke tests for checkout, webhook confirmation, failed payment, duplicate webhook events, entitlement updates, refunds, and manual review paths.

A Laravel application is introducing subscription upgrades. The team supplies Codex with its checkout and webhook handlers, subscription and entitlement models, migrations, provider event mapping, manual-review policy, existing feature tests, sandbox boundary, and permitted PHPUnit command. Codex then proposes evidence-linked tests for proration-related invoice states, failed upgrade payment, duplicate and out-of-order webhooks, atomic entitlement changes, refund effects, queue retries, and unauthorized review actions. Any command not actually run remains proposed or unverified, and sandbox observations require separate evidence.

Expert

Expert

Codex

Codex

testing

testing

codex
laravel
payments
checkout
webhooks
testing
smoke-tests
idempotency
edge-cases
risk-reduction
refunds
subscriptions
sandbox-testing

codex
laravel
payments
checkout
webhooks
testing
smoke-tests
idempotency
refunds
subscriptions
sandbox-testing

Laravel Payment Flow Smoke Test Prompt for Codex

Laravel Payment Smoke Test and Edge Case Planner for Codex

Plan Laravel payment smoke tests with Codex for checkout, webhooks, retries, duplicate events, refunds, entitlements, manual review, sandbox safety, and verification commands.

Plan evidence-backed Laravel payment tests for checkout, webhooks, retries, refunds, subscriptions, entitlements, and sandbox safety with Codex.

Prompt-body line comparison

Removed Added Unchanged context

−You are an expert Laravel payment systems engineer specializing in smoke testing, webhook safety, idempotency, checkout reliability, and financial-risk reduction.
−
−Inspect the supplied Laravel payment flow and design smoke tests, edge-case tests, regression coverage, and verification commands that protect money movement, customer entitlements, order state, manual review paths, and customer communication.
−
−The goal is to help Codex test or harden payment behavior without causing real charges, duplicate fulfillment, broken subscriptions, incorrect access, leaked secrets, or unsafe production changes.
−
−## Context Placeholders
−
−Use the context below. If the payment provider, checkout route, webhook route, or payment lifecycle is missing, ask for them before making risky recommendations.
−
−* [Payment provider and flow]
−* [Checkout and webhook routes]
−* [Payment, order, or subscription models]
−* [Success, failure, refund, and manual review rules]
−* [Idempotency, retry, and duplicate event concerns]
−* [Existing tests and sandbox or fake setup]
−* [Allowed files and verification commands]
−
−## Important Constraints
−
−* Inspect before editing. Identify relevant routes, controllers, webhook handlers, models, migrations, enums, services, jobs, events, listeners, notifications, policies, middleware, config, provider SDK usage, existing payment logs, and tests.
−* Do not change unrelated files, public UI, data, generated assets, lockfiles, or out-of-scope areas unless explicitly requested.
−* Respect allowed file scopes. If required changes fall outside scope, explain why before touching them.
−* Protect existing behavior. Prefer characterization tests, fakes, sandbox tests, or focused regression tests before risky payment edits.
−* Avoid destructive commands such as `git reset`, `git checkout`, `rm`, database wipes, production mutations, or real payment actions.
−* Do not use live payment credentials, real cards, real customer payment methods, or production webhooks during tests unless the user explicitly approves a controlled production check.
−* Do not expose secrets, API keys, webhook signing secrets, tokens, customer payment data, card data, billing addresses, or sensitive payloads in logs or test output.
−* Verify webhook signatures where applicable. Treat missing or weak signature validation as high risk.
−* Treat duplicate webhook delivery, delayed webhooks, out-of-order events, retries, and replay attempts as expected payment behavior.
−* Retry recommendations must avoid duplicate charges, duplicate fulfillment, duplicate invoices, duplicate emails, or repeated entitlement changes.
−* Separate confirmed code behavior from assumptions, risks, and recommendations.
−* Provide exact verification commands and explain what each command proves.
−
−## Step-by-Step Instructions
−
−1. Inspect the payment flow:
−
−   * checkout routes
−   * checkout controllers
−   * payment service classes
−   * provider SDK usage
−   * webhook routes
−   * webhook controllers or handlers
−   * payment models
−   * order models
−   * subscription or entitlement models
−   * jobs and queues
−   * events and listeners
−   * notifications and emails
−   * config and env assumptions
−   * existing payment logs
−   * existing tests
−
−2. Map the payment lifecycle:
−
−   * checkout started
−   * checkout session created
−   * customer redirected
−   * payment succeeded
−   * payment failed
−   * payment canceled
−   * webhook received
−   * webhook verified
−   * order or subscription updated
−   * entitlement granted or revoked
−   * invoice or receipt sent
−   * refund requested
−   * refund completed
−   * manual review started
−   * manual review approved or rejected
−
−3. Identify payment risk areas:
−
−   * missing webhook signature verification
−   * missing idempotency key
−   * duplicate webhook event handling
−   * delayed or out-of-order webhook events
−   * retry creating duplicate side effects
−   * checkout success page trusting redirect without webhook confirmation
−   * failed payment leaving incorrect status
−   * cancellation leaving pending records
−   * refund not updating entitlement or order state
−   * manual review bypass risk
−   * queue retry duplicating notifications
−   * race condition between return URL and webhook
−   * missing audit trail
−   * unsafe logging of payment data
−   * missing sandbox or fake coverage
−
−4. Design smoke tests:
−
−   * successful checkout path
−   * failed payment path
−   * canceled checkout path
−   * valid webhook path
−   * invalid webhook signature path
−   * duplicate webhook path
−   * delayed webhook path
−   * refund path
−   * manual review approval path
−   * manual review rejection path
−   * entitlement grant or access update path
−   * customer notification path
−
−5. Design edge-case and regression tests:
−
−   * duplicate provider event ID
−   * duplicate internal payment reference
−   * out-of-order status updates
−   * job retry after partial failure
−   * webhook replay attempt
−   * network timeout from provider
−   * provider 4xx or 5xx response
−   * currency mismatch
−   * amount mismatch
−   * user abandons checkout
−   * existing paid order receives duplicate success event
−   * unauthorized user attempts manual approval
−   * refund after entitlement was already used
−   * subscription upgrade or downgrade if applicable
−
−6. Define safe test boundaries:
−
−   * use Laravel fakes where possible
−   * use provider sandbox only where needed
−   * never require live payment credentials for automated tests
−   * avoid real customer data
−   * fake webhooks with signed payloads where possible
−   * document manual sandbox checks separately from automated tests
−
−7. Provide a safe verification sequence that avoids real charges, destructive data changes, and production mutations.
−
−## Output Format
−
−### 1. Missing Context
−
−List missing inputs needed before a safe payment smoke test plan can be completed. If enough context is available, say so.
−
−### 2. Payment Flow Map
−
−Use this table:
−
−| Stage | Route/Handler | Model or State Change | Side Effect | Risk or Assumption |
−| ----- | ------------- | --------------------- | ----------- | ------------------ |
−
−### 3. Risk and Edge Case Matrix
−
−Use this table:
−
−| Risk or Edge Case | Why It Matters | Current Evidence | Severity | Test Needed |
−| ----------------- | -------------- | ---------------- | -------- | ----------- |
−
−### 4. Smoke Test Plan
−
−Use this table:
−
−| Smoke Test | Setup | Expected Result | Data Safety Boundary | Suggested Test Name |
−| ---------- | ----- | --------------- | -------------------- | ------------------- |
−
−### 5. Webhook Safety Plan
−
−Use this table:
−
−| Webhook Scenario | Expected Handling | Idempotency Check | Signature Check | Side Effect Control |
−| ---------------- | ----------------- | ----------------- | --------------- | ------------------- |
−
−### 6. Manual Review and Refund Paths
−
−Use this table:
−
−| Path | Expected State Change | Approval Rule | Customer Impact | Test or Human Check |
−| ---- | --------------------- | ------------- | --------------- | ------------------- |
−
−### 7. Regression Test Plan
−
−Use this table:
−
−| Scenario | Failure Prevented | Test Type | Suggested Test Name | Priority |
−| -------- | ----------------- | --------- | ------------------- | -------- |
−
−### 8. Safe Implementation Sequence
−
−Provide a step-by-step plan for adding or improving tests before changing payment behavior.
−
−### 9. Verification Commands
−
−List exact commands and explain what each command proves.
−
−### 10. Assumptions and Human Checks
−
−Separate confirmed behavior from assumptions. List unresolved risks and human checks before implementation.
−
−## Verification Checklist
−
−Before finalizing, confirm that:
−
−* all payment tests use sandbox, fakes, mocks, or safe fixtures unless explicitly approved
−* no live payment credentials or real customer payment methods are required
−* webhook signature validation is considered
−* duplicate webhook delivery is covered
−* retry behavior avoids duplicate charges and duplicate fulfillment
−* checkout return behavior is not treated as proof of payment unless the system is designed that way
−* refunds and manual review paths are covered
−* entitlement, access, order, subscription, invoice, and notification side effects are considered
−* payment logs avoid secrets and sensitive customer payment data
−* verification commands are specific and runnable
−* missing inputs and human checks are clearly listed
−
−## Final Instruction to Begin
−
−Begin now. Inspect the supplied Laravel payment context first. If required context is missing, ask for it. Otherwise, produce the full Laravel payment flow smoke test and edge-case plan in the requested markdown format.
+Use Codex to inspect the supplied Laravel repository and prepare a payment-flow smoke-test and edge-case plan.
+
+This is a planning and verification task by default. It is not permission to edit files, execute migrations, contact a payment provider, create charges, issue refunds, replay live webhooks, mutate production data, or claim that testing succeeded.
+
+## Inputs
+
+- Payment provider, environment, and lifecycle: [Payment provider and flow]
+- Checkout, callback, and webhook endpoints: [Checkout and webhook routes]
+- Payment, order, invoice, subscription, and entitlement records: [Payment, order, or subscription models]
+- Required business-state behavior: [Success, failure, refund, and manual review rules]
+- Delivery, concurrency, and replay concerns: [Idempotency, retry, and duplicate event concerns]
+- Existing local tests, fakes, mocks, and provider-sandbox facilities: [Existing tests and sandbox or fake setup]
+- Permitted inspection, edits, commands, environments, and data operations: [Execution boundaries and verification commands]
+
+## Scope, authority, and evidence rules
+
+Unless [Execution boundaries and verification commands] explicitly restricts it, permit:
+
+- read-only repository inspection;
+- review of supplied documentation and sanitized logs;
+- non-mutating local diagnostics.
+
+Treat the following as unauthorized unless expressly approved:
+
+- file edits;
+- mutating commands;
+- dependency changes;
+- database writes or migrations;
+- cache or queue mutations;
+- provider API calls;
+- provider-sandbox actions;
+- production access;
+- webhook replay;
+- real charges, captures, cancellations, disputes, or refunds;
+- customer notifications or entitlement changes.
+
+Do not interrupt ordinary read-only inspection by repeatedly narrating permission checks. Verify authority before any edit, mutating command, external call, database action, or financially consequential activity.
+
+Use only repository files, snippets, documentation, logs, command results, and workspace capabilities actually available in the current session. Do not imply access to a provider dashboard, network, database, queue, logs platform, sandbox, test runner, or production system unless that access exists and the resulting evidence can be identified.
+
+Never request or reproduce:
+
+- live credentials;
+- signing secrets;
+- access tokens;
+- authorization headers;
+- raw cardholder data;
+- complete payment tokens;
+- real customer payment methods;
+- full customer payment records;
+- unnecessary personal information.
+
+Use synthetic customers, provider test identifiers, redacted configuration descriptions, safe fixtures, Laravel fakes, mocks, and approved provider test facilities.
+
+If a blocking input is missing, ask one consolidated set of focused questions. Blocking inputs include:
+
+- the provider and environment;
+- the authoritative payment-confirmation mechanism;
+- relevant checkout and webhook code;
+- the supported lifecycle states;
+- material business rules;
+- the test boundary;
+- execution authority.
+
+A partial plan may still be produced for supported areas, but affected conclusions must be marked blocked or unverified.
+
+When user descriptions, code, tests, migrations, configuration, logs, and provider documentation conflict:
+
+1. Preserve the conflicting statements.
+2. Identify their sources.
+3. Explain the financial, state, entitlement, or authorization consequence.
+4. Identify the evidence or owner needed to reconcile them.
+5. Do not silently select one version.
+
+Use these work states consistently:
+
+- **Observed** — directly found in an accessible repository file, configuration, migration, test, log, or command result.
+- **Supplied** — provided by the user but not independently reproduced by Codex.
+- **Proposed** — recommended but not executed.
+- **Executed** — actually performed in the current session with recorded evidence.
+- **Unavailable** — the required source, capability, or environment could not be accessed.
+- **Unverified** — plausible but not established by sufficient evidence.
+- **Conflicting** — available sources disagree.
+- **Not applicable** — excluded for a payment-flow-specific reason.
+
+Never claim that a defect was reproduced or fixed, that a test passed, that a payment was verified, that a refund occurred, or that provider or production behavior is safe without direct evidence for that exact statement.
+
+## Review workflow
+
+### 1. Establish the authoritative payment lifecycle
+
+Map the observed flow from the first checkout request through payment confirmation and downstream effects.
+
+Identify, where applicable:
+
+- checkout route and controller;
+- request validation and authorization;
+- server-side product, price, amount, currency, quantity, tax, and discount calculation;
+- provider adapter or SDK call;
+- checkout session, payment intent, charge, subscription, invoice, customer, refund, and event identifiers;
+- internal order, payment, subscription, invoice, and entitlement references;
+- browser success and cancellation returns;
+- synchronous provider responses;
+- webhook receipt and verification;
+- queued processing;
+- local state changes;
+- fulfillment;
+- entitlement changes;
+- customer notifications;
+- reconciliation and manual-review paths.
+
+Determine the authoritative source of payment confirmation.
+
+Do not treat a browser redirect, success page, client-supplied value, or local pending record as proof of payment unless the supplied application and provider contract explicitly establish that behavior.
+
+Record only lifecycle states supported by the repository or supplied rules, such as:
+
+- pending;
+- processing;
+- paid;
+- failed;
+- canceled;
+- expired;
+- refunded;
+- partially refunded;
+- disputed;
+- manual review.
+
+Identify which transitions are legal and which states are terminal. Flag any path that allows a stale or lower-authority event to regress a terminal successful state.
+
+### 2. Review checkout trust and duplicate prevention
+
+Inspect applicable controls for:
+
+- authentication and authorization;
+- request validation;
+- server-side price and product lookup;
+- client-value distrust;
+- provider request construction;
+- idempotency-key creation and reuse;
+- internal order or payment reference uniqueness;
+- repeated form submission;
+- browser refresh and retry;
+- abandoned checkout;
+- simultaneous requests;
+- repeated provider-object creation.
+
+Determine whether duplicate requests can create duplicate:
+
+- provider payment objects;
+- internal orders;
+- invoices;
+- fulfillment;
+- customer notifications;
+- entitlements;
+- ledger entries.
+
+An application-level “record exists” check is not sufficient evidence of concurrency safety unless it is supported by an atomic operation, unique constraint, lock, compare-and-set transition, or equivalent durable control.
+
+### 3. Review webhook authenticity, correlation, and replay safety
+
+Inspect:
+
+- raw request-body preservation;
+- signature or SDK verification;
+- signing-secret selection;
+- required headers;
+- timestamp tolerance;
+- replay handling;
+- malformed and oversized payload handling;
+- unsupported event behavior;
+- test versus live environment separation.
+
+Confirm that an accepted event is correlated to the expected:
+
+- provider account and environment;
+- event ID;
+- payment, checkout, charge, invoice, subscription, or refund object;
+- internal order or payment reference;
+- customer;
+- amount;
+- currency;
+- product or plan;
+- expected prior state.
+
+Identify the durable deduplication mechanism, such as:
+
+- a unique provider-event constraint;
+- a processed-events table;
+- an atomic insert;
+- row locking;
+- a compare-and-set update;
+- a transactional state transition.
+
+Trace duplicate, delayed, replayed, stale, and out-of-order events.
+
+Confirm that repeated or reordered processing cannot duplicate or incorrectly reverse:
+
+- payment state;
+- fulfillment;
+- invoices;
+- notifications;
+- entitlement grants or revocations;
+- subscription transitions;
+- refunds.
+
+Assess acknowledgement behavior. Determine when the handler returns success, how transient failures differ from permanent failures, and how provider retries interact with local transactions and queues.
+
+### 4. Review transaction, queue, and side-effect boundaries
+
+Identify:
+
+- database transactions;
+- row locks;
+- unique constraints;
+- optimistic state checks;
+- after-commit dispatch;
+- queued listeners and jobs;
+- retry counts and backoff;
+- timeouts;
+- failed-job handling;
+- partial-failure windows.
+
+For every externally visible side effect, determine:
+
+- what triggers it;
+- whether it occurs before or after durable state change;
+- whether retry can repeat it;
+- what idempotency guard exists;
+- how failure is reconciled.
+
+Inspect failure windows between:
+
+- provider confirmation and local persistence;
+- local persistence and entitlement grant;
+- state change and job dispatch;
+- transaction commit and notification;
+- webhook receipt and durable event recording.
+
+### 5. Review refunds, subscriptions, entitlements, and manual review
+
+Where applicable, inspect:
+
+#### Refunds
+
+- authorization;
+- requested, pending, succeeded, failed, partial, and reversed states;
+- maximum refundable amount;
+- currency;
+- duplicate refund prevention;
+- provider and local reconciliation;
+- order and entitlement consequences;
+- audit evidence;
+- customer communication.
+
+#### Subscriptions
+
+- plan eligibility;
+- upgrade and downgrade rules;
+- billing-cycle anchors;
+- proration assumptions;
+- invoice state;
+- trial effects;
+- failed payment;
+- scheduled changes;
+- webhook ordering;
+- recovery behavior.
+
+#### Entitlements
+
+Confirm that access grant, change, suspension, and revocation:
+
+- derive from documented payment or subscription states;
+- are idempotent;
+- cannot occur twice from a duplicate event;
+- cannot be lost after a partial failure;
+- reconcile with refunds and subscription changes.
+
+#### Manual review
+
+Inspect:
+
+- entry criteria;
+- authorized roles or policies;
+- approval and rejection transitions;
+- reason capture;
+- audit records;
+- stale reviews;
+- duplicate actions;
+- segregation of duties where required;
+- customer communication.
+
+### 6. Define financial and entitlement invariants
+
+Create evidence-linked invariants for the observed flow.
+
+Applicable examples include:
+
+- one logical checkout produces no more than one intended provider payment object;
+- only authenticated, correlated provider evidence can authorize a successful local payment transition;
+- accepted amount, currency, customer, account, product, plan, and internal reference match expectations;
+- one provider event produces no more than one durable business transition;
+- a duplicate or retried event cannot repeat fulfillment, invoice creation, notification, refund, or entitlement mutation;
+- stale or out-of-order events cannot regress a valid terminal state;
+- failed or canceled payment cannot grant paid access;
+- refund amount cannot exceed the supported refundable balance;
+- manual decisions require the documented authority;
+- retries and partial failures remain reconcilable.
+
+Do not assume every example applies. Add only invariants supported by the flow or necessary to prevent a credible failure.
+
+## Test architecture
+
+Separate the test plan into three evidence levels.
+
+### A. Minimal smoke suite
+
+Design a small, fast, deterministic suite that answers whether the application’s most critical payment paths still work.
+
+Include only the highest-value applicable cases, normally:
+
+- checkout creation with correct local initial state;
+- valid authoritative confirmation and intended state transition;
+- invalid or unauthenticated webhook rejection;
+- duplicate event without duplicate business effects;
+- failed or canceled payment without paid entitlement;
+- one critical refund, subscription, or manual-review path where relevant.
+
+The smoke suite should be suitable for frequent local or CI execution and should not require live credentials or real financial actions.
+
+### B. Edge-case and regression suite
+
+Design broader coverage for applicable risks such as:
+
+- stale signature;
+- malformed payload;
+- unsupported event;
+- duplicate internal reference;
+- amount or currency mismatch;
+- wrong account or customer;
+- delayed and out-of-order events;
+- simultaneous processing;
+- transaction rollback;
+- queue retry after partial failure;
+- notification retry;
+- abandoned checkout;
+- unauthorized manual action;
+- refund failure;
+- partial refund;
+- upgrade, downgrade, proration, invoice, and entitlement transitions.
+
+Do not force irrelevant cases into the suite merely to increase coverage.
+
+### C. Provider-sandbox checks
+
+Use provider-sandbox checks only where local fakes and integration tests cannot establish the required behavior.
+
+A sandbox call is still an external, state-changing action and requires explicit authorization.
+
+For every sandbox check define:
+
+- purpose;
+- test account and environment;
+- synthetic input;
+- prohibited data and actions;
+- exact steps;
+- expected provider evidence;
+- expected Laravel evidence;
+- cleanup;
+- approval owner;
+- limitation.
+
+A local fake does not prove provider behavior. A provider-sandbox result does not prove production behavior.
+
+## Test-design rules
+
+Prefer Laravel feature or integration tests for:
+
+- routes;
+- middleware;
+- authorization;
+- database state;
+- transactions;
+- queues;
+- events;
+- notifications;
+- webhooks;
+- end-to-end local state transitions.
+
+Use unit tests for isolated mappings, validators, or state-transition logic.
+
+Use Laravel fakes only where they preserve the behavior being tested. State when a fake bypasses:
+
+- real signature verification;
+- SDK serialization;
+- network transport;
+- database transactions;
+- queue serialization;
+- provider retries.
+
+Use synthetic fixtures and test-mode provider identifiers.
+
+Do not weaken assertions, suppress failures, delete tests, or replace meaningful integration coverage with mocks merely to obtain a passing suite.
+
+## Risk labels
+
+Use these qualitative labels:
+
+- **Critical** — credible risk of unauthorized or duplicate money movement, unrecoverable financial-state corruption, widespread incorrect entitlement, exposed payment secrets, or a state from which safe reconciliation is not possible.
+- **High** — material risk involving authentication, idempotency, ordering, amount or currency integrity, refunds, subscriptions, entitlements, authorization, or repeated customer-facing side effects.
+- **Medium** — a meaningful but bounded weakness requiring additional tests, controls, monitoring, or human review.
+- **Low** — evidence supports limited impact and adequate controls within the stated test scope.
+- **Unknown** — evidence is insufficient to classify the risk defensibly.
+
+Do not classify a risk Low merely because an existing test passes or a familiar provider SDK is used.
+
+## Verification rules
+
+Derive commands from the accessible repository’s:
+
+- Composer scripts;
+- test configuration;
+- CI workflow;
+- project documentation;
+- existing test layout.
+
+Do not invent runnable commands.
+
+Begin with the smallest targeted checks, then expand according to the affected flow and blast radius.
+
+For every command or procedure report:
+
+- purpose;
+- work state;
+- authorization basis;
+- target environment;
+- data boundary;
+- exact command or method;
+- expected observation;
+- actual exit status and relevant output only when executed;
+- failure meaning;
+- what the result cannot prove.
+
+Do not run destructive migrations, resets, real provider calls, production webhooks, queue purges, live refunds, or real charges.
+
+## Required deliverable
+
+Keep the deliverable concise and proportional to the observed payment flow and evidence.
+
+Use `Not applicable` with an evidence-based reason instead of filling unsupported sections with generic content.
+
+### A. Scope, evidence, and conflict register
+
+Provide:
+
+- files and sources inspected;
+- unavailable evidence;
+- missing inputs;
+- conflicts;
+- assumptions;
+- execution permissions;
+- blocked decisions.
+
+### B. Payment lifecycle and authority map
+
+Provide a table containing:
+
+- lifecycle stage;
+- initiating route or event;
+- Laravel handler;
+- provider object or event;
+- internal record and state;
+- transaction or queue boundary;
+- business side effect;
+- authoritative confirmation source;
+- evidence;
+- uncertainty.
+
+### C. Financial and entitlement invariant register
+
+Provide:
+
+- invariant ID;
+- protected asset or outcome;
+- current enforcement evidence;
+- credible failure mode;
+- risk;
+- required assertion;
+- remaining gap.
+
+### D. Webhook trust, ordering, and idempotency review
+
+Provide:
+
+- scenario;
+- authenticity requirement;
+- correlation checks;
+- deduplication control;
+- ordering rule;
+- transaction boundary;
+- expected acknowledgement or retry behavior;
+- protected side effects;
+- evidence;
+- gap.
+
+### E. Minimal smoke suite
+
+For each test provide:
+
+- priority;
+- suggested test name;
+- Laravel test level;
+- setup and fixtures;
+- stimulus;
+- expected payment and business state;
+- database assertions;
+- queue, event, or notification assertions;
+- negative assertions;
+- risk covered;
+- acceptance criterion.
+
+### F. Edge-case and regression backlog
+
+Group applicable tests under:
+
+- checkout;
+- webhook authenticity;
+- replay and ordering;
+- retries and concurrency;
+- refunds;
+- subscriptions and entitlements;
+- manual review;
+- notifications and reconciliation.
+
+Distinguish essential release coverage from lower-priority hardening.
+
+### G. Verification and provider-sandbox runbook
+
+Separate:
+
+- authorized local commands;
+- proposed but unexecuted commands;
+- provider-sandbox checks;
+- human review;
+- production checks that remain out of scope.
+
+Record actual results only where execution evidence exists.
+
+### H. Risk-ranked implementation sequence
+
+Order:
+
+1. characterization or missing baseline tests;
+2. high-risk smoke coverage;
+3. schema or uniqueness requirements;
+4. idempotency and state-transition controls;
+5. side-effect isolation;
+6. edge-case regression tests;
+7. provider-sandbox checks;
+8. broader regression execution.
+
+Identify every step requiring:
+
+- file-edit approval;
+- migration review;
+- provider access;
+- financial approval;
+- security review;
+- production change control.
+
+### I. Evidence and readiness record
+
+List every statement that could imply:
+
+- tests passed;
+- a defect was fixed;
+- provider behavior was verified;
+- financial action occurred;
+- production is safe.
+
+For each statement report:
+
+- status;
+- supporting evidence;
+- limitation.
+
+End with exactly one readiness status:
+
+- **Blocked** — a critical lifecycle, evidence, authorization, or test-boundary gap prevents a reliable plan.
+- **Ready for test-plan review** — the proposed coverage is coherent and ready for human review, but implementation or execution is not yet authorized.
+- **Ready for authorized local test implementation or execution** — repository evidence and boundaries are sufficient for the specified local work to be considered by an authorized human.
+- **Ready to request authorized provider-sandbox verification** — local evidence is complete for the stated scope and the remaining provider-specific checks are clearly defined.
+
+None of these statuses means that tests passed, provider behavior was verified, production is safe, or financial action is authorized.
+
+## Final acceptance gate
+
+Before returning the plan, confirm that:
+
+1. Every material payment state and business side effect is linked to repository or supplied-rule evidence.
+2. The authoritative payment-confirmation source is identified.
+3. Checkout does not trust client-supplied financial values without server-side validation.
+4. Webhook authenticity, correlation, duplicate delivery, replay, delay, ordering, retries, and concurrency are covered where applicable.
+5. Partial failures cannot silently duplicate or lose critical financial or entitlement effects.
+6. The smoke suite remains minimal, fast, and focused on critical invariants.
+7. Broader edge cases are separated into a prioritized regression backlog.
+8. Local fake, provider-sandbox, and production evidence are not conflated.
+9. Commands are repository-supported and have explicit safety boundaries.
+10. No live credentials, real customer payment methods, or raw restricted data are required.
+11. Conflicts, unavailable evidence, and human approval requirements are explicit.
+12. No testing, fix, provider, production, refund, charge, deployment, or safety claim exceeds the evidence actually obtained.