crypto-payer-mcp
# Crypto Payer MCP Server
[](https://www.npmjs.com/package/crypto-payer-mcp)
[](https://github.com/syamai/crypto-payer-mcp/actions/workflows/ci.yml)
MCP (Model Context Protocol) Server for [Crypto Payer Solution](https://bclass-solution.com) - cryptocurrency payment integration.
## Quick Start
### 1. Create Configuration File
Create `.env` file in one of these locations:
```bash
# Option 1: Home directory (recommended)
~/.crypto-payer-mcp.env
# Option 2: XDG config directory
~/.config/crypto-payer-mcp/.env
# Option 3: Current working directory
./.env
```
**Example `.env` file:**
```bash
# Required
CRYPTO_PAYER_OPERATOR_ID=your-operator-id
CRYPTO_PAYER_SECRET_KEY=your-secret-key
CRYPTO_PAYER_OPERATOR_NAME=Your Operator Name
CRYPTO_PAYER_PUBLIC_KEY="-----BEGIN PUBLIC KEY-----\nMIICIjAN...\n-----END PUBLIC KEY-----"
# Optional (defaults to testnet)
CRYPTO_PAYER_API_URL=https://dev-api.bclass-solution.com/v1
CRYPTO_PAYER_DOMAIN_URL=https://dev-front.bclass-solution.com
```
### 2. Configure Claude Desktop
Add to `~/Library/Application Support/Claude/claude_desktop_config.json` (macOS) or `%APPDATA%\Claude\claude_desktop_config.json` (Windows):
```json
{
"mcpServers": {
"crypto-payer": {
"command": "npx",
"args": ["-y", "crypto-payer-mcp"]
}
}
}
```
That's it! The server automatically loads configuration from your `.env` file.
### Advanced: Custom .env Path
```json
{
"mcpServers": {
"crypto-payer": {
"command": "npx",
"args": ["-y", "crypto-payer-mcp"],
"env": {
"CRYPTO_PAYER_ENV_FILE": "/path/to/your/.env"
}
}
}
}
```
## Configuration File Locations
The server searches for `.env` file in this order:
1. `CRYPTO_PAYER_ENV_FILE` environment variable (if set)
2. `./.env` (current working directory)
3. `~/.crypto-payer-mcp.env` (home directory)
4. `~/.config/crypto-payer-mcp/.env` (XDG config)
## Available Tools
| Tool | Description |
|------|-------------|
| `request_payment` | Request a new payment session from PLATFORM |
| `generate_auth_header` | Generate X-Operator-Authorization header |
| `verify_webhook` | Verify webhook signature (RSA-SHA512) |
| `build_payment_url` | Build payment page URL |
| `parse_webhook_event` | Parse webhook event data |
| `get_config` | Get current configuration (shows loaded .env path) |
## Environment Variables
| Variable | Required | Description |
|----------|----------|-------------|
| `CRYPTO_PAYER_OPERATOR_ID` | Yes | Operator ID from PLATFORM |
| `CRYPTO_PAYER_SECRET_KEY` | Yes | Secret key from PLATFORM |
| `CRYPTO_PAYER_PUBLIC_KEY` | Yes | RSA public key for webhook verification |
| `CRYPTO_PAYER_OPERATOR_NAME` | Yes | Your operator display name |
| `CRYPTO_PAYER_API_URL` | No | API URL (default: testnet) |
| `CRYPTO_PAYER_DOMAIN_URL` | No | Domain URL (default: testnet) |
| `CRYPTO_PAYER_ENV_FILE` | No | Custom path to .env file |
## API Endpoints
| Environment | API URL | Domain URL |
|-------------|---------|------------|
| **Testnet** | `https://dev-api.bclass-solution.com/v1` | `https://dev-front.bclass-solution.com` |
| **Mainnet** | `https://api.bclass-solution.com/v1` | `https://bclass-solution.com` |
## Usage Examples
### 1. Check Configuration
```
Tool: get_config
Output: {
"envFile": "/Users/you/.crypto-payer-mcp.env",
"platformApiUrl": "https://dev-api.bclass-solution.com/v1",
"operatorId": "260f52c4...",
"operatorSecretKey": "****",
"isConfigured": true
}
```
### 2. Request Payment
```
Tool: request_payment
Input: { "userAccessToken": "user-jwt-token-from-your-system" }
Output: {
"result": true,
"data": { "paymentId": "eGrtTN7mIHTtd0uNLGnPweKtz2qXcVoq" }
}
```
### 3. Build Payment URL
```
Tool: build_payment_url
Input: { "paymentId": "eGrtTN7mIHTtd0uNLGnPweKtz2qXcVoq" }
Output: {
"url": "https://dev-front.bclass-solution.com?paymentId=xxx&id=xxx&name=xxx"
}
```
### 4. Verify Webhook
```
Tool: verify_webhook
Input: {
"signature": "base64-signature-from-header",
"webhookBody": {
"event": "DEPOSIT_COMPLETED",
"timestamp": 1746776884590,
"data": { "user": {...}, "result": {...} }
}
}
Output: { "isValid": true, "event": "DEPOSIT_COMPLETED", "message": "Signature verified" }
```
### 5. Parse Webhook Event
```
Tool: parse_webhook_event
Input: {
"webhookBody": {
"event": "DEPOSIT_COMPLETED",
"timestamp": 1746776884590,
"data": {
"user": { "id": "user_123", "name": "john" },
"result": { "id": "tx_abc", "amount": { "amount": "100" }, "instrument": { "symbol": "USDT" } }
}
}
}
Output: {
"eventType": "DEPOSIT_COMPLETED",
"category": "deposit",
"status": "completed",
"user": { "id": "user_123", "name": "john" },
"amount": { "amount": "100", "currency": "USDT", "network": "Ethereum" }
}
```
## Supported Webhook Events
### Deposit Events
- `DEPOSIT_PROCESSING` - Deposit is being processed
- `DEPOSIT_COMPLETED` - Deposit completed successfully
### Withdraw Events
- `WITHDRAW_REQUESTED` - Withdrawal requested by user
- `WITHDRAW_REJECTED` - Withdrawal rejected by admin
- `WITHDRAW_APPROVED` - Withdrawal approved by admin
- `WITHDRAW_PENDING` - Withdrawal pending
- `WITHDRAW_PROCESSING` - Withdrawal being processed
- `WITHDRAW_COMPLETED` - Withdrawal completed
- `WITHDRAW_FAILED` - Withdrawal failed
## Development
```bash
# Clone the repository
git clone https://github.com/syamai/crypto-payer-mcp.git
cd crypto-payer-mcp
# Install dependencies
npm install
# Create local .env for testing
cp .env.example .env
# Edit .env with your credentials
# Build
npm run build
# Run locally
npm start
```
## License
MIT - see [LICENSE](LICENSE)
TDQS
Scored across 6 tools
Each tool targets a distinct action: payment session creation, auth header generation, webhook signature verification, URL construction, webhook parsing, and config retrieval. Even closely related webhook tools are separated by verification versus parsing, and request_payment versus build_payment_url are clearly different stages.
All tool names follow a consistent verb_noun snake_case pattern: request_, generate_, verify_, build_, parse_, get_. There are no mixed conventions or vague verbs.
Six tools is a well-scoped set for a payment integration server. Each tool covers a distinct part of the payment flow without redundancy or bloat.
The set covers the core flow: create a payment request, build the redirect URL, generate API auth, and verify/parse incoming webhooks. A notable gap is the lack of a direct payment-status lookup or cancellation/refund operation, though webhooks may partially cover status delivery.