Project Analysis

Scan payment integration

Analyze an application package or source archive for implementation vulnerabilities across checkout flow, signature verification and secret handling.

Drop project archive or APK
ZIP or APK · Maximum 50 MB
01
Signature verification
Checks that payment completion verifies an HMAC signature on the server before marking an order as paid.
02
Webhook verification
Checks that asynchronous webhook handlers verify the signature header before acting on the payload.
03
Amount integrity
Checks that the confirmed payment amount matches the original order amount stored in the database.
04
Secret exposure
Detects private API keys and secret tokens hardcoded in frontend scripts or mobile app packages.
Security Inspection

Findings

NO ACTIVE SCAN

Upload a project archive (.zip) or Android package (.apk) from the Scan tab to run static analysis.

Evaluation Report

Detection performance

Held-out evaluation · 19 fixtures
Loading evaluation metrics…
Product Handbook

Understanding Loosewire

A comprehensive guide to payment integration security, detection mechanics, how to interpret findings, evaluation methodology and the estimated value model.

01

What is Loosewire?

Loosewire is a specialized static analysis security scanner designed specifically for payment gateway integrations. It inspects application source archives (.zip) and compiled Android packages (.apk) to detect implementation flaws that could allow an attacker to bypass payment verification, manipulate transaction amounts or extract private merchant credentials.

The crucial distinction: Loosewire is not a customer fraud-detection engine that evaluates whether a shopper or credit card is suspicious. Instead, it inspects the merchant's application codebase to ensure that backend handlers correctly verify cryptographic proofs, authenticate gateway callbacks and enforce transaction invariants before fulfilling orders.

Scanner Evaluation vs. Current Scan: When you open Loosewire, you will see published evaluation benchmarks (88.9% Precision, 100% Recall, 94.1% F1). These numbers describe Loosewire's own scanner accuracy across 19 benchmark fixtures. They are not findings from your project. Your project findings only appear after you run an active scan on the Scan tab. If no project has been uploaded, there are zero project findings and no fake project statistics.

02

What Does Loosewire Look For?

Modern checkout architectures split responsibilities between untrusted clients (browsers and mobile apps) and trusted server backends. Loosewire inspects code across four critical security checks:

1. Signature Verification

When a customer completes payment at a gateway modal, the gateway returns a cryptographic signature (an HMAC hash combining order ID and payment ID, signed with the merchant's secret key). The merchant backend must independently recalculate and verify this HMAC signature before trusting the payment.

The Risk: If the server merely accepts a payment_id from the client without verifying the HMAC signature, an adversary can send synthetic HTTP requests with fabricated IDs to mark orders as paid without executing a real transaction.

INSECURE FLOW
Customer Browser "Payment OK" (Unverified ID) Server fulfills order
SECURE FLOW
Customer Browser Payment Payload Server recalculates & validates HMAC Order fulfilled

2. Webhook Verification

Webhooks are automated server-to-server HTTP notifications sent by payment gateways for asynchronous events (e.g. offline bank transfers clearing, subscription renewals or disputes). Because webhook endpoints are public HTTP URLs, anyone can post payloads to them. The receiving server must check the cryptographic signature in request headers against the webhook secret before processing the event.

3. Amount Validation & Integrity

Authenticating that a transaction occurred is not the same as verifying the transaction amount. If a backend fails to check that the captured payment amount matches the authoritative database price for that order, an attacker can modify client-side checkout parameters to pay $1 for an item priced at $500.

Authoritative Database Price: $500.00
Client Manipulated Payment: $1.00
Integrity Validation Rule: Price $500.00 does not match paid $1.00 → REJECT & ALERT

4. Secret Exposure

Payment gateways provide Public Keys (safe for frontend widgets) and Private Secrets (for backend server signing, refunds and transfers). Private secret keys must never be hardcoded into frontend scripts, HTML templates or mobile Android APK bytecode, where decompilation easily exposes them.

INSECURE
Client Script / APK [ Contains Private Secret Key ] Decompilation extracts credentials
SECURE
Client (Public Key only) Secure Backend [ Private Secret stored in Vault / ENV ] Gateway API
03

Understanding a Finding

When Loosewire analyzes your codebase, each identified security issue is presented with six standardized fields in the Findings workspace:

Severity How critical the potential vulnerability is (Critical, High, Medium, Low) based on exploitability and impact.
Confidence The scanner's certainty (High, Medium, Low) that the detected code pattern constitutes a genuine defect.
Rule The specific detection rule and check identifier that was triggered.
Location The exact file path and line number where the issue was detected in your codebase.
Description A clear explanation of why the detected code structure is insecure.
Fix Actionable code modifications and remediation steps to resolve the finding.
04

Evaluation Metrics & Full Forms

To evaluate how reliably Loosewire performs, we use standard classification metrics. You do not need any background in statistics or machine learning to understand them:

Core Classification Terms

TP
True Positive: Loosewire correctly identifies a real vulnerability that actually exists in the code.
FP
False Positive: Loosewire reports a vulnerability that is not actually present. This is a false alarm. While no security hole exists, too many false alarms cause alert fatigue and waste engineering time investigating non-issues.
FN
False Negative: A real vulnerability exists in the code but Loosewire fails to detect it. This is a missed issue. False negatives are dangerous because an undetected flaw can reach production.
F1
F1 Score / F-measure: A combined measure that balances Precision and Recall into a single overall performance score using their harmonic mean. The "1" refers to the standard equal-weight version of the F-measure (giving equal importance to precision and recall).

Precision, Recall, and F1 Explained

Precision
Formula: TP / (TP + FP)

Precision asks: "When Loosewire says it found something, how often is it actually correct?"

Simple Example: If Loosewire reports 10 findings and 9 are real vulnerabilities while 1 is a false alarm, Precision is 90% (9 / 10).

Why it matters: High precision means fewer false alarms and low alert noise for developers.
Recall
Formula: TP / (TP + FN)

Recall asks: "Of all the real vulnerabilities that existed, how many did Loosewire actually find?"

Simple Example: If there are 10 real vulnerabilities across the codebase and Loosewire catches all 10, Recall is 100% (10 / 10, with 0 missed).

Why it matters: High recall means comprehensive security coverage with fewer missed vulnerabilities.
F1 Score
Formula: 2 × (P × R) / (P + R)

F1 Score balances both: Combines Precision and Recall into one overall quality score.

Why it matters: A scanner could flag every line of code to achieve 100% recall but produce overwhelming false alarms (poor precision). Or it could only flag 1 obvious flaw for 100% precision, while missing 9 others (poor recall). F1 balances both into one score.
05

The Held-Out Evaluation (19 Fixtures)

On the Metrics tab, you see published benchmark scores: 88.9% Precision, 100% Recall and 94.1% F1.

What does this mean? These are NOT metrics from your uploaded project. They measure Loosewire's scanner performance. They were calculated by testing Loosewire against an isolated test suite of 19 held-out evaluation fixtures (containing both clean and deliberately vulnerable checkout implementations) where expected findings were strictly partitioned during detector rule authoring.

Evaluation Results Breakdown:

8 TP Loosewire correctly detected 8 real vulnerabilities across the test suite.
1 FP Loosewire produced 1 false alarm candidate during rule evaluation.
0 FN Loosewire missed 0 real vulnerabilities across all test fixtures (100% recall).
Key Distinction:
Scanner Evaluation: Measures how well Loosewire itself detects known issues across benchmark fixtures.
Current Scan: Measures what Loosewire found in your specific uploaded project.
These are two completely separate things.
06

The Estimated Value Model ($3,975)

The Metrics tab displays an Estimated Value Saved ($3,975) along with assumptions of $25 / false positive and $500 / false negative.

What is it?

It is an assumption-based cost model used to illustrate the potential financial value of catching security defects early versus manual triage overhead.

$3,975 is an illustrative, assumption-based estimate. It is not measured financial savings and is not audited telemetry.

The Model Assumptions

$25 / False Positive (FP)

The assumed engineering/security triage cost required for a developer or security engineer to investigate, review and dismiss a finding that turns out not to be a real vulnerability (false alarm).

$500 / False Negative (FN)

The assumed downstream exposure and remediation cost associated with a real payment vulnerability being missed and reaching production (fraud loss, unauthorized order fulfillment, emergency patching).

How $3,975 is Calculated:

Using the evaluation results from the 19 benchmark fixtures (8 TP, 1 FP, 0 FN):

  • • 8 True Positives detected × $500 avoided exposure = +$4,000
  • • 1 False Positive raised × $25 triage overhead = -$25
  • • 0 False Negatives missed × $500 exposure = -$0
  • • Net Modeled Value = $4,000 - $25 = $3,975

The displayed $3,975 represents the difference between the modeled cost of Loosewire's evaluation outcome and a hypothetical zero-coverage baseline where no automated analysis is run.

Why Does This Model Exist?

The purpose of the Estimated Value Model is to translate abstract scanner performance statistics (precision and recall) into a simple, business-oriented estimate. It helps answer: "Why does improving detection accuracy matter?" It clearly illustrates the economic trade-off between the substantial benefits of catching vulnerabilities and the minor operational friction of reviewing false alarms.

07

What Loosewire Does Not Claim

Loosewire is an automated static analysis tool. A clean scan does not constitute a formal guarantee that an application is 100% secure. Comprehensive payment security requires a defense-in-depth posture including:

• Thorough manual code review
• End-to-end sandbox payment testing
• Strict server-side authorization
• Secure secret management vaults
• Web application firewall (WAF)
• Continuous ledger anomaly monitoring
08

Safe & Authorized Use

Loosewire is intended for scanning source code and application packages that you own or have explicit authorization to audit.

All analysis is performed entirely locally on your machine using temporary memory directories. No source code, credentials, or findings are transmitted to external servers or retained after analysis completes.