hunt-payment-workflow

Validates payment, refund, and subscription state machines against server-side ledger authority.

10|3|Updated Aug 10, 2026
One-click install
npx skills add https://github.com/baiqigo/baiqi-redteam-lab --skill hunt-payment-workflow-baiqigo
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: hunt-payment-workflow
Source: https://github.com/baiqigo/baiqi-redteam-lab/tree/main/.agents/skills/hunt-payment-workflow
Command: npx skills add https://github.com/baiqigo/baiqi-redteam-lab --skill hunt-payment-workflow-baiqigo

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Payment and billing flows often trust client-side amounts, UI discounts, or asynchronous callbacks, letting testers report false positives or miss real ledger inconsistencies. This Skill enforces an evidence-gated method to verify that amounts, inventory, coupons, callbacks, refunds, and subscription states are authoritative only at the server-side ledger. ## Core Features & Use Cases - Engagement Gating: Requires recorded authorization, locked scope, and host/identity baselines before any probe runs, and stops immediately on third-party assets or production side effects. - Server-Authoritative Oracles: Treats only persistent ledger, entitlement, and inventory results that violate defined invariants as valid findings; frontend discounts, payment failure pages, and async delays are rejected. - Controlled Routing: Hands signed-callback cases to webhook-signature testing and concurrency cases to race-condition testing, keeping each probe single-variable and low-frequency. - Use Case: During an authorized test window, compare normal and boundary inputs on your own sandbox orders, read back results from the payment provider sandbox and backend ledger, and capture pre/post state with rollback evidence. ## Quick Start Use $hunt-payment-workflow to plan an evidence-gated, authorized validation path for my test payment orders.

Frequently Asked Questions about hunt-payment-workflow

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I test payment workflow logic for ledger inconsistencies?

Payment workflow testing compares normal and boundary inputs on your own test orders, then reads results back from the payment provider sandbox and backend ledger. A finding is valid only when the server-side ledger, entitlement, or inventory shows a persistent result violating a defined invariant.

What counts as a real payment bug versus a false positive?

A real bug produces a persistent server-side ledger, entitlement, or inventory state that violates defined invariants and reproduces after rollback. Frontend discount displays, payment failure pages, and asynchronous delays are false positives and do not qualify.

Can I test payment flows without touching real money?

Yes, this approach uses only sandbox payment providers, zero-value or sandbox amounts, self-owned test accounts, and rollback-capable orders. It stops immediately if real currency, production inventory, or third-party accounts would be affected.

When should concurrency testing be used in payment validation?

Concurrency probes are only performed when the separate race-condition testing capability's additional requirements are met. Otherwise all probes remain single-variable and low-frequency to avoid uncontrolled side effects.

What are the limitations of black-box payment state testing?

WAF blocks, captchas, timeouts, and single anomalous responses are treated as inconclusive rather than vulnerabilities. Testing also requires a written authorization window and stops on any out-of-scope or production impact.