Pop Pay Skill
AdvisoryAudited by VirusTotal on Apr 4, 2026.
Overview
Type: OpenClaw Skill Name: pop-pay Version: 0.6.23 The 'pop-pay' skill enables an AI agent to perform financial transactions by injecting credit card data directly into browser forms using the Chrome DevTools Protocol (CDP). While the documentation in SKILL.md describes several security features—such as local keychain storage and guardrail checks to prevent the agent from seeing the credentials—the skill relies on an external binary (pop-pay) and environment-based configurations that manage sensitive financial data. The inherent high-risk nature of automated payments and browser-level injection, combined with the inability to audit the underlying binary's logic within this bundle, warrants a suspicious classification.
Findings (0)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
An agent could spend real money within the configured policy if it misinterprets a task, is influenced by a page, or chooses the wrong item or merchant.
The skill's documented default/example flow allows automatic card injection and instructs the agent to complete the purchase without requiring a human confirmation on every transaction.
POP_AUTO_INJECT=true ... POP_REQUIRE_HUMAN_APPROVAL=false ... After approval: Click the submit/pay button.
Set POP_REQUIRE_HUMAN_APPROVAL=true, consider POP_AUTO_INJECT=false, use very low per-transaction and daily budgets, and require the user to verify the merchant, item, amount, and final payment click.
If the tool, browser session, policy, or agent behavior is wrong, the user's own card and billing profile could be used for unintended purchases.
The skill delegates use of a high-value payment credential to a local tool accessible by the agent.
Gives your OpenClaw agent the ability to pay at any online store using your own existing credit card ... pop-pay setup # securely stores your card in the system keychain
Use a low-limit or virtual card if possible, keep merchant allowlists narrow, monitor statements, and avoid enabling this for agents or browsing sessions that handle untrusted pages without human review.
The static scan could not verify the code that will handle the card, browser, and purchases, so users must trust the external package supply chain.
The reviewed skill contains no implementation code, but directs users to install and run an external package that performs the sensitive payment and browser-injection behavior.
# Install from PyPI (https://pypi.org/project/pop-pay/)\npip install pop-pay\n... "command": "pop-pay", "args": ["serve"]
Inspect the package source, pin the expected version, verify publisher/provenance, and avoid installing updates automatically for a tool that can access payment credentials.
The local helper can modify checkout pages and fill sensitive fields, so incorrect operation could affect real transactions.
A separate local process controls browser payment forms through Chrome DevTools Protocol; this is central to the stated purpose but is powerful browser automation.
credentials are injected directly into the browser's payment form via CDP ... in a separate process
Run it only in a trusted browser profile/session and review the package before granting it access to payment workflows.
If enabled, transaction details or related context may leave the local machine.
The default is described as local, but optional LLM guardrails and webhooks can send payment-related context to a provider or endpoint chosen by the user.
Guardrail engine (optional) | llm mode — uses your own API key | Your API provider ... Webhook notifications | Disabled by default — only active if POP_WEBHOOK_URL is set
Keep keyword mode and webhooks disabled unless you understand exactly what data is sent and trust the destination.
Users may over-trust the protection and allow autonomous payments without enough oversight.
The documentation makes strong absolute security claims for a high-impact payment workflow, but the reviewed artifacts do not include the implementation needed to validate those claims.
If your agent is compromised by a prompt injection attack, the attacker cannot steal your card. ... Prompt injection scan on every payment | Yes — automatic
Treat the safety claims as unverified until the external implementation is reviewed; keep human approval enabled for every payment.