0.15.0 - Elastic License 2.0

License

• PandaPayLens is now source available under the Elastic License 2.0 instead of the Apache License 2.0. It stays free to use, change and share; offering it as a hosted or managed service, or other commercial terms, need the maintainer's permission. Releases up to and including 0.14.0 stay available under Apache-2.0. Contributors license their contributions under ELv2 and allow the maintainer to offer them under other terms.

Documentation

• A 60 second demo video (synthetic data, served from the site itself) on the home page, in the README and in the npm README. The home page loads it only when play is pressed; the static export check requires the video and its poster.

Install: npx pandapaylens analyze events.json or npm install pandapaylens.

0.14.0 - npm package

Packages

• The CLI and the engine are published to npm as one package, pandapaylens: the pandapaylens binary, and a library entry with analyze(text, options?), the engine, every adapter, the default rules and the report helpers. JavaScript is bundled (no runtime dependencies) and type declarations resolve on their own. CI installs the packed tarball into an empty project and checks the binary and a typed import; a workflow publishes to npm with provenance when a GitHub release is published.

Documentation

• The getting-started page, README and roadmap use the npm package (npx pandapaylens, import { analyze } from "pandapaylens").

Maintenance

• A monthly workflow requests every official documentation link cited by adapters, catalogs, manifests and rules, and fails when one returns 404 or 410, redirects to a "page not found" page or names a host that does not resolve (node scripts/check-doc-links.mjs).

Install: npx pandapaylens analyze events.json or npm install pandapaylens.

0.13.0 - Plain text responses

Analyzer

• Plain text with one name: value pair per line is read as one record, pasted alone (at least two lines, so a sentence such as "Error: not found" is not read as data) or as a text/plain HTTP response body (one line is enough there when the status is below 400). Repeated names become lists.
• Form fields named like built-in object members (for example toString) are no longer merged with them.
• Keys of flattened billing and shipping address groups (billingAddr_*, shippingAddr_*) are hidden in the inspector and exports.

Providers

• Verotel: the FlexPay status page (response: FOUND|NOTFOUND|ERROR) is analyzed as a snapshot of the sale, linked by saleID. saleResult: APPROVED is the only documented success; subscription facts are shown as attributes; NOTFOUND is decoded as an invalid request and ERROR as unknown with the scrubbed error text. Buyer name, email, address and one-click token are never copied.

0.12.0 - Worldpay XML and time zones

Analyzer

• Event and arrival times are used only when they are ISO 8601 with a time zone; anything else is removed from the event and reported once (TIMESTAMP_IGNORED), so ordering never depends on the time zone of the computer running the analysis.
• Times that a provider documents without a time zone and that are read as UTC (CCBill, Trust Payments) are marked "UTC assumed" in the timeline and the Markdown report, and a TIME_ZONE_ASSUMED warning appears when they are analyzed together with another provider's times.

Web app

• Findings show their documentation link for every provider, not only Stripe and Adyen. Links are shown only for https hosts that a provider manifest cites as official documentation, the same check the error decoder uses.
• The unsafe retry finding links the idempotency documentation of PayPal, Square, Mollie and Checkout.com as well.

Providers

• Worldpay XML is analyzed:
  • WPG paymentService replies (error codes, order status with lastEvent, the standard ISO8583ReturnCode values) and order notifications, linked by order code. Amounts follow the documented exponent; partial captures and refunds use the journal amount. Paste WPG documents without their DOCTYPE line, which is rejected for safety.
  • cnpAPI cnpOnlineResponse transaction responses with the 379 documented payment transaction response codes and the request validation codes.
  • WPG requests, reports, batch files and other replies are recognized and reported as unsupported. Extended ISO 8583 codes are shown with Worldpay's description but not decoded, because the WPG documentation does not tie them to a table.
• Checkout.com no longer appears as a 0.4 alternative for records whose only Checkout.com trait is a pay_ id, such as Razorpay payment entities. A bare pay_ id now scores 0.3 (documented length) or 0.15 (other lengths), below a record with documented fields.

0.11.0 - XML input

Analyzer

• XML input is read instead of rejected. One document (or an HTTP message with an XML body) becomes one record that adapters can analyze; the root element and its namespace are kept so adapters can identify the provider. Until an adapter supports a provider's XML, such records are reported as unsupported records instead of a parse error.
• XML is read safely: documents with a DOCTYPE or entity declarations are rejected, so external entities and entity expansion cannot happen; only predefined and numeric character references are decoded; depth, element count and text length are limited, and parsing is a single linear pass.
• The getting-started page and the CLI help list every accepted input format.

Providers

• XML responses are analyzed for five providers, each detected by its documented root element, namespace and fields, and decoded with the same logic as the JSON form:
  • emerchantpay: Genesis payment_response (Processing API, reconcile and Smart Routing). Other Genesis XML roots are recognized and reported as unsupported.
  • Skrill: refund.pl, pay.pl and ondemand_request.pl responses and API error strings. A refund response is never read as a payment, and where the documentation does not say whether a transfer was a payout or a 1-Tap payment, the event says so. Plain-text MQI errors are used when Skrill is selected manually.
  • Authorize.net: XML API createTransactionResponse and ErrorResponse in the AnetApi namespace.
  • BlueSnap: XML Payment API card transactions and error messages in the http://ws.plimus.com namespace, decoded by error name.
  • Inpay: ISO 20022 pain.002 and pacs.002 status reports as payout events. ISO 20022 is a generic standard, so a report is attributed to Inpay automatically only when it names Inpay as initiating party; otherwise select Inpay manually.
• XML fixtures are included in the cross-provider detection test, and the demo has two XML examples.

0.10.0 - Repeats without delivery ids

Analyzer

• Identical records from providers that send no delivery id are recognized as a possible repeated delivery and counted once by the lifecycle rules, so a refund notification delivered twice no longer looks like two refunds (rule catalog 2026.10.5). Adapters can mark events whose provider documents that identical records may be separate events (Paymentwall partial refunds, EBANX refund and chargeback notifications); those are never merged.

0.9.0 - Analyzer UX and redaction

Analyzer

• The provider list is grouped into "Full support" and "Limited support".
• When a record resembles a provider but cannot be identified automatically, the result explains why and offers an "Analyze as " button.
• In the event-time view, events without their own timestamp stay where they occurred in the input instead of moving to the end, so lifecycles such as initialize, authentication steps, webhook and verify read in order.
• Decoded errors show their official documentation links for every provider; before, only Stripe and Adyen links were shown. Links are limited to https hosts cited in the provider manifests.

Security

• The PayU India text scrubber runs in linear time on any input (code scanning alert 4).
• Redaction covers the sensitive fields documented by the wave 3 and wave 4 providers: card data, tokens and integration keys, 3-D Secure references, bank, wallet and UPI ids, identity documents, names and contact data, device ids and links that carry access keys.
• Request headers verif-hash (which carries a Flutterwave merchant secret), x-login and x-client-id are hidden.
• Free text redaction catches Flutterwave secret and public keys, JWT-style secrets and UPI ids.
• The email pattern in text redaction now runs in linear time on long input.

0.8.0 - Wave 4 gateways

Wave 4: the last general providers on the roadmap.

Providers

• New adapters with limited support, built from official documentation and tested with synthetic fixtures:
  • BlueSnap: JSON Payment API card transactions, refunds and errors decoded by error name, and form-encoded webhooks.
  • PayU India: form-encoded payment responses and webhooks, Verify Payment JSON and refund command responses.
  • Razorpay: Payments API errors and entities (payment, order, refund, dispute, settlement, payout) and webhooks.
  • Paystack: Transactions and Charge API responses, errors, refunds, disputes, transfers and webhooks.
  • Flutterwave: v3 and v4 responses and webhooks, including refunds, chargebacks, voids and transfers.
• 40 of 42 roadmap providers can now be analyzed. The remaining two, Pavilion Payments and Epoch, publish no developer documentation and stay blocked.

0.7.0 - Wave 3 gateways

Wave 3 general providers.

Providers

• New adapters with limited support, built from official documentation and tested with synthetic fixtures:
  • Paysafe: Payments API v1 resources, errors and webhooks, with merchant advice and ISO response codes.
  • Airwallex: PaymentIntents, attempts, refunds, disputes and payments webhooks; issuer codes are decoded with the card brand.
  • Rapyd: Merchant API responses and webhooks for payments, refunds, disputes and payouts.
  • dLocal: Payins payments, refunds, chargebacks and errors, and Payouts v3, with status codes decoded per object type.
  • EBANX: Pay-in Direct API responses and errors, notifications and payouts.
• Research for BlueSnap, PayU India, Razorpay, Paystack and Flutterwave; all five passed the documentation gate.
• 35 of 42 roadmap providers can now be analyzed.

Security

• Redaction now covers Nuvei checksums, session tokens, card, 3-D Secure and payer fields (advanceResponseChecksum, responsechecksum, checksum, sessionToken, userTokenId, ccCardNumber, last4Digits, MaskedCardNumber, cavv, acsUrl, cReq, ARN, AuthCode, ClientName, externalEmail, apmPayerInfo).

0.6.0 - Wave 2 gateways

Wave 2 general providers.

Providers

• New adapters with limited support, built from official documentation and tested with synthetic fixtures:
  • Worldpay (Access Worldpay JSON): Events webhooks, Payments API and Card Payments v7 responses, errorName errors and Payment Queries. Refusal codes are decoded with the Worldpay or raw scheme reading the payload supports.
  • Cybersource: REST Payments API responses and errors, the webhook envelope, Transaction Details and Pay by Bank payloads.
  • Authorize.net: JSON transaction responses with the API and transaction result layers decoded separately, and webhooks.
  • Nuvei: REST API 1.0 responses, payment and withdrawal DMNs and chargeback events, with codes decoded by field.
• 30 of 42 roadmap providers can now be analyzed.

Fixed

• MISSING_REFERENCE no longer reports events that share a correlation group with other events, for example events linked by a transaction or root id instead of a payment id (rule catalog 2026.10.4).

Security

• Redaction now covers Authorize.net card, track, credential and verification fields (cardCode, expirationDate, track1, track2, tlvData, dataValue, cardholderAuthenticationValue, transactionKey, nameOnAccount, customerIP, PayerEmail, SecureAcceptanceUrl, transHash, transHashSha2).