unified-pay-cli
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| STRIPE_KEY | No | Your Stripe secret API key (sk_test_... or sk_live_...) | |
| RAZORPAY_ID | No | Your Razorpay key ID (rzp_test_... or rzp_live_...) | |
| RAZORPAY_SECRET | No | Your Razorpay key secret | |
| LEMONSQUEEZY_KEY | No | Your LemonSqueezy API key | |
| LEMONSQUEEZY_STORE | No | Your LemonSqueezy store ID |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| create_payment_linkA | Generates a secure hosted payment checkout URL across Stripe, Razorpay, or LemonSqueezy. Supports custom transaction amounts, automatic currency formatting, customer prefill metadata (name, email, phone), customizable link expiry timeouts, and intelligent multi-gateway routing. Returns a JSON object containing the checkout URL, payment link ID, status, and assigned gateway provider. |
| compare_gateway_feesA | Evaluates and compares the transaction processing fees, percentage cuts, fixed interchange fees, and estimated net payouts across Stripe, Razorpay, and LemonSqueezy for a given transaction amount and currency. Returns an itemized fee breakdown for each supported gateway alongside the recommended lowest-cost provider. |
| trigger_mock_webhookA | Constructs and dispatches a cryptographically authentic HMAC-SHA256 signed synthetic webhook event payload directly to a local or remote backend endpoint. Useful for verifying webhook signature parsing, event processing handlers, and local integration pipelines without executing live card charges. Returns the HTTP status code, response headers, and response body received from the target server. |
| verify_webhook_signatureA | Validates the cryptographic HMAC-SHA256 signature and tamper-resistance of an incoming webhook HTTP request payload against a shared webhook signing secret. Returns a JSON boolean indicating whether the signature matches the payload digest. |
| get_payment_analyticsA | Aggregates real-time transaction performance, total gross volume, captured revenue volume, settled payouts, and payment success/conversion rates by querying recent transaction histories across connected payment gateway accounts. Returns statistical aggregates and settlement ratios. |
| create_itemized_invoiceA | Constructs a multi-item commercial invoice checkout link containing itemized product line descriptions, per-unit pricing, item quantities, total tax calculations, and customer billing details. Returns the generated hosted invoice payment URL and itemized receipt breakdown. |
| create_refundA | Executes an immediate full or partial monetary refund for a previously settled payment or charge transaction across supported payment gateways. Returns a JSON confirmation object containing the refund ID, status, refunded amount, and currency. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 7 tools
Most tools are clearly distinct, but create_payment_link and create_itemized_invoice both generate hosted checkout URLs, potentially causing confusion. Other tools (fees, webhooks, refunds, analytics) have clear boundaries.
All tools follow a consistent verb_noun snake_case pattern (create_, compare_, trigger_, verify_, get_). The naming is uniform and predictable across the entire set.
Seven tools is a well-scoped size for a payment CLI, covering common operations without overwhelming the user. Each tool addresses a distinct payment workflow, making the count appropriate.
Core operations like creating payments, refunds, and webhook verification are covered, but there are notable gaps such as no way to retrieve a payment by ID or list past payments. This forces agents to rely on analytics for status, which is a workaround rather than a direct access pattern.