PandaPayLens

Payment providers each describe a payment differently. A failed charge can arrive as a JSON error from an API, an XML document from an older gateway, a form-encoded postback, a raw HTTP response with a plain-text body, or a series of webhook deliveries that may be duplicated or out of order. Debugging means translating all of that into one picture: which events belong to the same transaction, what the provider actually reported, and what is merely missing.

PandaPayLens takes pasted input from 40 providers, detects the provider and format, normalizes the records, rebuilds the timeline and runs a catalog of explainable rules over it. It runs in three places from the same engine: a web analyzer, a static demo on GitHub Pages, and an offline CLI published to npm as pandapaylens.

The design constraint that shapes most decisions is privacy. Payment payloads contain card data, names, emails and credentials, so the analysis must run where the data already is: in the browser or on the developer's machine.

The repository is a pnpm workspace. packages/core holds the engine with no dependencies, packages/adapters/* holds one package per provider, packages/rules holds the diagnostic catalog, packages/providers is the registry, and packages/cli bundles everything into the npm package. Two apps reuse the same pages: apps/web for Vercel and apps/pages as a static export for GitHub Pages.

The analysis is a pipeline. parseInput decides the format, every adapter scores how likely the record is its provider, the best candidate above a threshold of 0.5 normalizes it, and the engine sorts, correlates and evaluates rules.

Each adapter implements the same interface: detect, parse, normalize, decodeErrors and correlationKeys, plus a capability manifest that states what is supported, limited or experimental. A manifest capability is marked supported only when it is implemented and tested.

Normalization copies only allowlisted fields. Amounts are kept as integer strings in minor units, never floats, and an UNSAFE_INTEGER warning is raised when a value is not an exact integer. Every normalized event carries a coarse lifecycle stage, but the type documentation is explicit that this is a display aid: authorization is not settlement, and a capture is not necessarily settlement either.

Rules are pure functions of the normalized context. A rule that throws becomes a RULE_FAILED warning instead of crashing the analysis, and finding text never quotes payment identifiers, so masking in reports stays effective.

Speed of delivery created its own failure modes, and the issue tracker records them. Two regular expressions used for redaction turned out to run in quadratic time on long text without whitespace; one was flagged by CodeQL, and the companion fix measured 18 to 26 seconds for 80,000 characters before it was rewritten (see the problem record). Timeline ordering pushed events without timestamps to the end, which put a Paystack webhook before the PIN and OTP steps that caused it. A shared pay_ id prefix made Checkout.com appear as an alternative for every Razorpay payment.

The documentation link checker failed on its first scheduled run with 14 Razorpay links that load from Europe but answer 404 to GitHub-hosted runners. Each of these is documented as a problem record with the fix and its validation.

• The web app sends a per-request nonce Content Security Policy with connect-src 'self', object-src 'none', base-uri 'none' and frame-ancestors 'none'. The static GitHub Pages build cannot send headers, so it uses a meta-tag policy and a build check fails if any page lacks it.
• Redaction is defense in depth, and the README says so: normalization copies only allowlisted fields, then about 330 blocked key names, 11 text patterns and Luhn-checked card numbers are redacted from everything shown or exported. Identifiers are masked in reports by default.
• Pasted signature headers are never treated as proof; the tool does not verify webhook signatures and does not confirm settlement.
• Keys named __proto__, constructor and prototype are removed during parsing and reported.
• The analyzer stores no payment data. The interface does store the theme preference in the browser.
• SECURITY.md states that the project is not PCI DSS certified and has not had an independent penetration test.

Tests run against source through workspace aliases. Coverage thresholds in vitest.config.ts are 90% statements, 85% branches, 90% functions and 90% lines. Rule tests include scenario, property (fast-check) and lifecycle suites, and every adapter has its own test file driven by synthetic fixtures whose identifiers contain PPLsynth.

Playwright covers the analyzer and a privacy suite marked as a release blocker: it plants marker values in the input and fails if any of them appears in a network request or if any request goes to another origin. CI runs type checks, formatting, coverage, the README provider table drift check, bundle size budgets, a CLI smoke test, the npm pack smoke test and both Playwright suites. CodeQL runs on every push and weekly.