paytrigo-openclawbot_skill

This skill enables OpenClawBots to create and verify PayTrigo Base/USDC invoices by polling status without webhooks.
  • Python

2.5k

GitHub Stars

4

Bundled Files

2 months ago

Catalog Refreshed

4 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill openclaw/skills --skill paytrigo-openclawbot

  • _meta.json307 B
  • package.json130 B
  • README.md3.3 KB
  • SKILL.md4.6 KB

Overview

This skill provides a minimal, bot-friendly PayTrigo payment flow for OpenClawBots using a platform API key and Base/USDC only. It is designed for bots that do not support webhooks and instead poll for invoice status. The helper scripts include an embedded platform key for immediate use and support both human-in-the-loop and direct bot payment flows.

How this skill works

Create an invoice with the platform key (recipientAddress required) and receive invoiceId, payUrl, checkoutToken, and expiresAt. For human flows, send payUrl to the user and poll the invoice until status reaches confirmed, expired, invalid, or refunded. For bot-pay flows, fetch the intent with the checkoutToken to get router steps (approve/pay), submit the on-chain txHash via payment-intents, then poll status until settlement. Polling follows a safe default policy that increases intervals over time and respects 429 backoff.

When to use it

  • You operate an OpenClawBot that cannot receive webhooks and must poll for status.
  • You need a no-setup option using an embedded platform key for quick testing or archived flows.
  • You accept only Base/USDC payments and the platform key is locked to that token/chain.
  • You need both human checkout (payUrl) and programmatic bot-pay flows.
  • You want a minimal flow that enforces router pay steps instead of direct token transfers.

Best practices

  • Always include recipientAddress when using a platform key; missing it makes invoices invalid.
  • Store invoiceId and checkoutToken immediately after creation; checkoutToken is only returned at that time.
  • For bot-pay, use the intent steps.pay from the router; avoid direct token transfers.
  • Follow the polling policy: frequent polls right after submission, then back off, and respect 429 responses.
  • Keep a local encrypted wallet store for recipient/payer keys to avoid external services.

Example use cases

  • A vending OpenClawBot that generates a payUrl for a human user to complete payment in-browser.
  • An automated bot that performs token approvals and on-chain pay transactions using the intent flow.
  • A test or archive environment where the embedded platform key enables immediate end-to-end checks.
  • A headless bot that stores invoiceId/checkoutToken and polls until the invoice is confirmed.
  • A migration or backup scenario where archived flows are replayed without webhook infrastructure.

FAQ

No. The embedded platform key and the helper scripts assume Base/USDC only as configured by the platform fee settings.

What if my poll hits a 429 rate limit?

Back off and retry later. Implement exponential or stepped backoff as described in the polling policy and reduce poll frequency.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational