Skill: elvismusli/moneyclaw (version 5.5.3)

--- name: moneyclaw description: Inspect a MoneyClaw wallet, create bounded payment tasks, and continue user-confirmed payment steps using a prepaid account. Use only when the user clearly asks to use MoneyClaw for their own payments. metadata: openclaw: homepage: https://moneyclaw.ai/openclaw primaryEnv: MONEYCLAW_API_KEY requires: env: - MONEYCLAW_API_KEY --- # MoneyClaw MoneyClaw helps OpenClaw agents inspect prepaid payment state, create auditable payment tasks, and continue explicitly requested payment steps. Primary use case: buyer-side payments for OpenClaw agents. ## Authentication This skill requires one MoneyClaw API key. ```bash Authorization: Bearer $MONEYCLAW_API_KEY ``` Base URL: `https://moneyclaw.ai/api` ## Trust Model MoneyClaw is designed for real, user-authorized agent payments. - use prepaid balances to keep risk bounded - use payment intents as the main auditable execution surface - keep account inbox state inspectable for receipts and account messages - let the user approve the payment step before money moves ## Approval Model Default to dashboard approval unless the account has explicitly enabled agent auto-approval. - MoneyClaw accounts expose an account-level `agentAutoApproveEnabled` flag through `GET /api/me`. - When that flag is off, API-key-created payment tasks wait for dashboard approval before spending. - When that flag is on, API-key-created payment tasks can be auto-approved within the merchant and amount scope of the task. - Do not assume agent auto-approval is enabled unless the account state confirms it. ## Safety Boundaries - Only use MoneyClaw for purchases or payment flows explicitly requested by the user. If the account is not clearly configured for agent auto-approval and the user has not explicitly asked for the next payment step, stop and ask. - Only use wallet, card, and billing data returned by the user's own MoneyClaw account. - Respect merchant, issuer, card-network, and verification controls. - Treat fraud checks, KYC, sanctions, geography rules, merchant restrictions, issuer declines, and other payment controls as hard boundaries. - Never fabricate billing identity, cardholder data, addresses, names, phone numbers, or verification information. - If a transaction fails, looks suspicious, or produces conflicting signals, stop and inspect transaction state before retrying. - Prefer prepaid, bounded-risk flows by default. - Never invoke this skill automatically from a shopping, billing, or checkout page. Use it only after an explicit user request to use MoneyClaw. ## Before Any High-Risk Step Before any action that can spend funds, retrieve execution details, or submit a payment step: 1. Confirm the exact merchant domain. 2. Confirm the amount and currency. 3. Confirm the user explicitly asked for this exact action, or that the account is clearly configured for agent auto-approval for this scope. 4. Stop if that confirmation is missing or ambiguous. ## Default Buyer Flow Use the product in this order: 1. `GET /api/me` for wallet readiness, deposit address, and inbox context. Fresh accounts may also finish mailbox, deposit-address, and provider setup on this first authenticated read. 2. `POST /api/payment-intents` for the exact purchase. 3. If `agentAutoApproveEnabled` is off, wait for dashboard approval. If it is on, the API-key task can move directly toward `approved` and `card_ready`. Approved tasks can auto-prepare or reuse the account's hidden execution card when wallet funding is available. On the first hidden-card bootstrap for an account, MoneyClaw may reserve the provider minimum initial deposit onto that shared hidden card even if the current task amount is smaller. Any residual stays on the same hidden card for later tasks. 4. Use `GET /api/payment-intents/:intentId/credentials` only when the task is `card_ready` and the user explicitly asked to continue the current payment step. 5. After a successful one-time checkout, use `POST /api/payment-intents/:intentId/reconcile` to write the settled charge back into MoneyClaw accounting. 6. Inspect payment-task state and wallet transactions before retrying. ## Load References When Needed - Read `references/payment-safety.md` before entering payment details on an unfamiliar merchant, when a checkout keeps failing, or when retry boundaries matter. ## Core Jobs ### 1. Check account readiness ```bash curl -H "Authorization: Bearer $MONEYCLAW_API_KEY" \ https://moneyclaw.ai/api/me ``` Important fields: - `balance`: wallet balance - `depositAddress`: where to send USDT - `mailboxAddress`: inbox address for receipts and account messages - `agentAutoApproveEnabled`: whether API-key-created payment tasks can auto-approve without a dashboard click When the user asks for readiness, report wallet balance, deposit address, inbox state, and whether a payment task can proceed. ### 2. Create an auditable payment task ```bash curl -X POST -H "Authorization: Bearer $MONEYCLAW_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "intentType": "one_time_purchase", "merchantName": "OpenAI", "merchantDomain": "openai.com", "expectedAmount": "20.00", "fundingCap": "20.00", "currency": "USD", "metadata": { "serviceName": "ChatGPT Plus" } }' \ https://moneyclaw.ai/api/payment-intents ``` Use payment intents to hold merchant context, approval state, and audit history. Rules: - use the account's `agentAutoApproveEnabled` state as the default control path for API-key-created tasks - if the account does not have agent auto-approval enabled and the intent is `pending_approval`, stop and ask the user to approve it in the dashboard instead of pretending you can finish approval yourself - treat the intent as the source of truth for execution state, not the card ### 3. Inspect the payment task state ```bash curl -H "Authorization: Bearer $MONEYCLAW_API_KEY" \ https://moneyclaw.ai/api/payment-intents/{intentId} ``` Use the payment task as the source of truth for readiness, approval, execution, and completion. ### 4. Read the payment task history ```bash curl -H "Authorization: Bearer $MONEYCLAW_API_KEY" \ https://moneyclaw.ai/api/payment-intents/{intentId}/history ``` Use the history when the user wants an audit trail or when a payment step gave ambiguous results. ### 5. Continue the approved payment step ```bash curl -H "Authorization: Bearer $MONEYCLAW_API_KEY" \ https://moneyclaw.ai/api/payment-intents/{intentId}/credentials ``` Rules: - only call this when the intent is `card_ready` - only call this after the user explicitly asked to continue that payment step - do not treat these execution details as a general account-level card surface - do not expose PAN or CVV longer than needed for the active checkout ## Payment Execution Rules - The spending model is prepaid. The loaded balance is the hard limit. - Fresh accounts may need enough wallet balance for the first shared hidden-card bootstrap, not only for the immediate merchant total. - Before payment, confirm the merchant domain and total amount are correct. - Use the billing address returned by MoneyClaw. Never invent one. - If a merchant asks for unexpected out-of-band verification, stop and ask the user instead of assuming the skill should continue automatically. - Do not retry the same merchant checkout more than twice in one session without user confirmation or clear pre-authorization. - If the user asks for a risky or suspicious payment, stop and explain why. Use `references/payment-safety.md` for expanded safety and retry guidance. ## Good Default Prompt Shapes - `Check my MoneyClaw account and tell me if the wallet, inbox, and payment tasks are ready.` - `Create a payment task for this purchase and keep the amount bounded to the expected total.` - `Continue this already approved payment step.` - `Check whether this payment task completed, still needs dashboard approval, or should be inspected before retrying.`

path: agents/openai.yaml
content: interface:
  display_name: "MoneyClaw"
  short_description: "Inspect wallet readiness, create bounded payment tasks, and continue user-confirmed payment steps"
  default_prompt: "Use $moneyclaw only when the user explicitly asks to use their own MoneyClaw account. Start by checking wallet readiness and whether account-level agent auto-approval is enabled. Create a bounded payment task for the exact merchant and amount. Do not retrieve execution details or continue checkout until the user asks to continue the exact payment step."

policy:
  allow_implicit_invocation: false


path: references/acquiring.md
content: # Acquiring Reference

Use this reference only when the user explicitly wants merchant-side payment collection rather than buyer-side card spending.

## Table of Contents

1. When To Use Acquiring
2. Merchant Setup
3. Invoice Flow
4. Public Checkout And Widget
5. Webhooks
6. Fees And Lifecycle Notes

## 1. When To Use Acquiring

Switch to acquiring when the user wants to:

- accept USDT from customers
- create hosted invoices
- embed a payment widget on a site
- receive server-side payment notifications

Do not switch to acquiring by default. Buyer-side card purchases remain the primary MoneyClaw use case.

## 2. Merchant Setup

### Enable merchant mode

`POST /api/acquiring/setup`

What it does:

- creates merchant settings for the authenticated user
- generates a webhook secret
- enables merchant mode

Important:

- the `webhookSecret` is shown once
- store it immediately if the user plans to verify webhooks

### Read or update settings

- `GET /api/acquiring/settings`
- `PATCH /api/acquiring/settings`

Settings support:

- `storeName`
- `webhookUrl`
- `enabled`

## 3. Invoice Flow

### Create an invoice

`POST /api/acquiring/invoices`

Useful request fields:

- `amount` - minimum `1`
- `description`
- `reference`
- `callbackUrl`
- `expiresIn` - default `3600`, min `300`, max `86400`

Important response fields:

- `id`
- `amount`
- `fee`
- `netAmount`
- `status`
- `depositAddress`
- `checkoutUrl`
- `expiresAt`

Typical flow:

1. make sure merchant mode is enabled
2. create invoice
3. show the hosted `checkoutUrl` or embed the widget
4. customer pays USDT
5. confirm paid status before fulfilling the order

### List or inspect invoices

- `GET /api/acquiring/invoices`
- `GET /api/acquiring/invoices/{invoiceId}`

Use these to:

- review invoice history
- inspect current invoice state
- reconcile paid vs pending invoices

## 4. Public Checkout And Widget

Public endpoints do not require Bearer auth:

- `GET /api/acquiring/public/invoices/{id}`
- `GET /api/acquiring/public/invoices/{id}/status`

The widget is served from:

- `https://moneyclaw.ai/widget.js`

Core widget usage:

```html
<div id="moneyclaw-pay"></div>
<script src="https://moneyclaw.ai/widget.js"
  data-invoice-id="INVOICE_ID"
  data-theme="dark">
</script>
```

Important widget notes:

- `data-invoice-id` is required
- client-side widget events are for UX only
- confirm payment server-side before fulfilling an order

## 5. Webhooks

If `callbackUrl` is set, MoneyClaw sends a signed POST when an invoice is paid.

Things to verify:

- use the saved `webhookSecret`
- verify `X-Webhook-Signature`
- compute `HMAC-SHA256(requestBody, webhookSecret)` and compare

Do not fulfill orders based only on browser events or optimistic UI state.

## 6. Fees And Lifecycle Notes

- fee: `$0.30 + 3%` per paid invoice
- no fee on unpaid or expired invoices
- invoice expiry is applied lazily on read in the current MVP
- public status polling exists, but should be used conservatively


path: references/payment-safety.md
content: # Authorized Payment Safety Reference

Use this reference when:

- you are about to enter card details on an unfamiliar site
- the checkout asks for unexpected additional verification
- a merchant declines payment and you need retry guidance
- you need to confirm whether a payment step is within the user's authorized scope

## Table of Contents

1. Authorization Boundaries
2. Pre-Payment Checklist
3. Additional Verification And Retry Rules
4. When To Stop And Ask The User

## 1. Authorization Boundaries

Follow these rules for every MoneyClaw payment flow:

- only use MoneyClaw for purchases or payment flows explicitly requested by the user; if the account is not clearly configured for agent auto-approval and the next step is not explicitly requested, stop and ask
- only use wallet, card, and billing data returned by the user's own MoneyClaw account
- respect merchant, issuer, card-network, and verification controls
- treat fraud checks, KYC, sanctions, geography rules, merchant restrictions, issuer declines, and other payment controls as hard boundaries
- never fabricate billing identity, cardholder data, addresses, names, phone numbers, or verification information
- prefer prepaid, bounded-risk flows by default

## 2. Pre-Payment Checklist

Run this checklist before entering card details:

1. Verify the exact domain. In `paypal.com.secure-verify.net`, the real domain is `secure-verify.net`.
2. Confirm the user explicitly asked to continue this exact payment step, unless the account is clearly configured to auto-approve agent-created payment tasks for this scope.
3. Confirm HTTPS is present, but do not treat HTTPS alone as proof of legitimacy.
4. Confirm the total amount and currency.
5. Confirm wallet or prepared execution balance covers the amount plus a small buffer.
6. Use the billing address from the prepared execution details. Do not invent one.
7. Confirm the purchase matches the user's request or the already approved scope.
8. If the merchant asks for information that is not present in the account data, stop and ask the user.
9. If the flow shows obvious scam signals, do not continue.

## 3. Additional Verification And Retry Rules

- do not treat extra verification as a normal default path for MoneyClaw payments
- do not invent, infer, or work around an additional verification step
- never retry immediately after a merchant error; read transaction history first
- maximum two retries per merchant session unless the user explicitly confirms further attempts
- do not keep retrying after repeated CVV or extra-verification failures
- if the merchant, inbox, and transaction history give conflicting signals, stop and inspect state before doing anything else

Common guidance:

- `INSUFFICIENT_BALANCE`: top up or reduce purchase amount
- `CARD_NOT_ACTIVE`: the payment step is not ready yet
- merchant-side error with no clear payment result: inspect the payment task and wallet activity before trying again

## 4. When To Stop And Ask The User

Stop and ask the user if any of these are true:

- the merchant requests identity documents, social security numbers, bank account data, or unusual verification details
- the amount, currency, or merchant domain no longer matches the expected purchase
- the merchant or issuer decline appears related to compliance, sanctions, geography, or merchant policy
- the checkout asks for contact or identity information that is not already present in the user's account data
- you are no longer sure the flow is within the user's requested or account-configured auto-approved scope


Security scan verdicts — ClawScan: suspicious | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)