home / skills / phrazzld / claude-config / check-btcpay

check-btcpay skill

/skills/check-btcpay

This skill audits BTCPay Server configuration, checks API connectivity, webhooks, payment notifications, and lightning node status to surface critical issues.

npx playbooks add skill phrazzld/claude-config --skill check-btcpay

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
5.2 KB
---
name: check-btcpay
description: |
  Audit BTCPay Server configuration. Checks store settings, webhook health,
  payment notifications, and API connectivity. Use when: running BTCPay
  as payment processor, diagnosing webhook issues, or verifying setup.
  Keywords: btcpay, btcpayserver, greenfield, payment processor.
effort: high
---

# /check-btcpay

Audit BTCPay Server configuration. Output findings as structured report.

## What This Does

1. Check Greenfield API connectivity
2. Audit store configuration
3. Review webhook endpoints + signature verification
4. Check payment notification settings
5. Verify Lightning node connection
6. Verify wallet hot/cold separation
7. Output prioritized findings (P0-P3)

**This is a primitive.** It only investigates and reports. Use `/log-production-issues` to create issues or `/check-production` for infra review.

## Process

### 1. API Connectivity (Greenfield API health)

```bash
export BTCPAY_URL="https://btcpay.example.com"
export BTCPAY_API_KEY="your-api-key"

# Greenfield health
curl -s -H "Authorization: token $BTCPAY_API_KEY" "$BTCPAY_URL/api/v1/health"

# List stores (requires valid API key)
curl -s -H "Authorization: token $BTCPAY_API_KEY" "$BTCPAY_URL/api/v1/stores" | jq
```

### 2. Store Configuration

```bash
# Set STORE_ID from the stores list above
export STORE_ID="store_id_here"

# Store details
curl -s -H "Authorization: token $BTCPAY_API_KEY" "$BTCPAY_URL/api/v1/stores/$STORE_ID" | jq

# Enabled payment methods
curl -s -H "Authorization: token $BTCPAY_API_KEY" "$BTCPAY_URL/api/v1/stores/$STORE_ID/payment-methods" | jq
```

### 3. Webhook Endpoints + Signature Verification

```bash
# List configured webhooks
curl -s -H "Authorization: token $BTCPAY_API_KEY" "$BTCPAY_URL/api/v1/stores/$STORE_ID/webhooks" | jq

# Webhook handlers in code
find . -path "*/api/*webhook*" -name "*.ts" 2>/dev/null | head -5

# Signature verification in handlers?
grep -rE "btcpay|webhook.*signature|hmac" --include="*.ts" . 2>/dev/null | grep -v node_modules | head -5
```

### 4. Payment Notification Settings

```bash
# In-app notification handlers (invoice paid/confirmed)
grep -rE "invoice.*(paid|confirmed|expired)|payment.*(received|settled)" --include="*.ts" . 2>/dev/null | grep -v node_modules | head -5

# Check for notification URL/config in app env
grep -rE "BTCPAY_.*(NOTIFY|NOTIFICATION|WEBHOOK)" --include="*.env*" . 2>/dev/null | head -5
```

### 5. Lightning Node Connection

```bash
# Confirm Lightning payment method enabled at store
curl -s -H "Authorization: token $BTCPAY_API_KEY" "$BTCPAY_URL/api/v1/stores/$STORE_ID/payment-methods" | jq

# Lightning node health checks in repo
grep -rE "lnd|lightning|lnurl|bolt11" --include="*.ts" . 2>/dev/null | grep -v node_modules | head -5
```

### 6. Wallet Hot/Cold Separation

```bash
# Look for hot wallet usage or private keys in repo
grep -rE "xprv|seed|mnemonic|private key" --include="*.ts" --include="*.env*" . 2>/dev/null | grep -v node_modules | head -5

# Watch-only setup hints (xpub descriptors)
grep -rE "xpub|ypub|zpub|descriptor" --include="*.ts" --include="*.env*" . 2>/dev/null | grep -v node_modules | head -5
```

### 7. Deep Audit

Spawn `btcpay-auditor` agent for comprehensive review:
- Invoice lifecycle handling (new, paid, confirmed, expired)
- Webhook signature verification and replay protection
- Store policies vs code expectations
- Lightning vs on-chain fallback behavior
- Wallet key custody and backup posture

## Output Format

```markdown
## BTCPay Audit

### P0: Critical (Payment Failures)
- Greenfield API unreachable - `GET /api/v1/health` fails
- Webhooks not receiving events (no active endpoints)
- Store has no enabled payment methods

### P1: Essential (Must Fix)
- Webhook signature not verified - security risk
- Invoice status handling missing (paid/confirmed/expired)
- Lightning payment method enabled but node not connected
- Notification URL missing or misconfigured

### P2: Important (Should Fix)
- No retry/backoff on webhook delivery failures
- Payment method config inconsistent between store and app
- Hot wallet usage detected without separation plan
- No monitoring of invoice settlement latency

### P3: Nice to Have
- Add separate store for test vs production
- Add automated webhook replay tooling
- Add dashboard for invoice outcomes

## Current Status
- Greenfield API: Unknown
- Stores: Unknown
- Webhooks: Unknown
- Notifications: Unknown
- Lightning: Unknown
- Wallet separation: Unknown

## Summary
- P0: 3 | P1: 4 | P2: 4 | P3: 3
- Recommendation: Fix API connectivity + webhook verification first
```

## Priority Mapping

| Gap | Priority |
|-----|----------|
| Greenfield API unreachable | P0 |
| No enabled payment methods | P0 |
| Webhooks not receiving events | P0 |
| Webhook signature not verified | P1 |
| Missing invoice status handling | P1 |
| Lightning node not connected | P1 |
| Notification URL missing | P1 |
| Missing retry/backoff | P2 |
| Config mismatch store vs app | P2 |
| Hot wallet without separation | P2 |
| Monitoring gaps | P2 |
| Optimization/analytics | P3 |

## Related

- `/check-lightning` - Lightning setup review
- `/check-bitcoin` - On-chain wallet review
- `/check-production` - Infra readiness
- `/log-production-issues` - Create issues from findings

Overview

This skill audits a BTCPay Server deployment and produces a prioritized, actionable report. It inspects Greenfield API connectivity, store settings, webhook health, payment notifications, Lightning connection, and wallet custody signals. Use the findings to triage payment failures and harden integrations.

How this skill works

The auditor queries the Greenfield API to validate health and list stores, then reviews each store’s payment methods and Lightning enablement. It inspects configured webhooks and verifies signature handling and retry behavior, scans for notification endpoints, and checks for hot/cold wallet cues (xprv/xpub, descriptors). Results are aggregated into P0–P3 prioritized findings and a concise remediation summary.

When to use it

  • Validating a BTCPay instance before going live with payments
  • Diagnosing missed or duplicated payment notifications
  • Investigating webhook signature or replay protection problems
  • Verifying Lightning node connectivity and fallback behavior
  • Auditing wallet custody and hot/cold key separation

Best practices

  • Ensure Greenfield API health and access tokens are valid before deeper checks
  • Require webhook signature verification and implement replay protection
  • Keep payment methods consistent between store config and application logic
  • Avoid storing private keys or mnemonics in app repos or env files; use watch-only descriptors where possible
  • Add retry/backoff and observability for webhook deliveries and invoice settlement

Example use cases

  • Run after deploying BTCPay to confirm API and store connectivity
  • Triage incidents where invoices show paid on BTCPay but app never received notification
  • Pre-launch checklist to ensure Lightning node is connected and payments can settle
  • Compliance check to detect accidental inclusion of private keys or hot-wallet usage in codebase
  • Prioritize fixes when payment processing is disrupted (focus P0 items first)

FAQ

What does a P0 finding mean?

P0 indicates a critical issue that will cause payment processing failures or loss of funds, such as unreachable Greenfield API, no enabled payment methods, or webhooks not receiving events.

Does this tool change configuration or remediate issues?

No. It only inspects and reports findings. Use your change process or a ticketing workflow to remediate; link findings to follow-up tasks.

How does it verify webhook signatures?

It checks webhook configuration for expected signature headers and looks for signature/HMAC validation in handlers; it flags missing verification and recommends replay protection.