If you run a subscription-based SaaS business, you usually learn about problems too late. A payment fails, a customer churns, or a dispute appears, and nobody sees it until hours later.
This openclaw agent is built to close that gap. It listens to Creem webhooks in real time, sends clear alerts, analyzes churn risk, and can even execute retention actions when the policy says it is safe.
The Big Picture
Why This Design Is Useful
This architecture solves three practical problems at once:
- Speed: events are processed immediately, not in batches.
- Safety: no webhook is trusted until signature verification passes.
- Control: automation is allowed, but only when policy confidence is high enough.
So you get fast response without turning your billing system into an uncontrolled autopilot.
Step-by-Step: What Happens on Each Webhook
1) Webhook arrives
Creem calls POST /webhook/creem.
The handler checks:
- HTTP method must be
POST - content type must include
application/json - payload must be under size limit
-
creem-signaturemust validate via HMAC-SHA256
If any check fails, the request is rejected with a clear error.
2) Duplicate protection
Every event ID is tracked in memory. If the same event arrives again, it is acknowledged but not reprocessed.
This prevents repeated alerts and repeated side effects.
3) Event classification
The agent splits events into two lanes:
- Standard events (sales, refunds, disputes, payment state changes)
-
Churn events (
subscription.canceled,subscription.scheduled_cancel)
Standard events are formatted and broadcast directly.
4) Churn intelligence lane
For churn events, the agent builds context first:
- customer email
- product and price
- subscription tenure
- historical revenue
- cancel reason
Then it asks the LLM for a recommendation:
- offer a retention discount
- suggest pausing the subscription
- take no retention action
5) Policy guardrail
The LLM output is not used blindly.
A deterministic policy layer scores retention potential using revenue, tenure, event type, and cancel-reason signals. The policy can strengthen, downgrade, or keep the recommendation.
Then it chooses one route:
- automatic execution
- human approval
- monitor only
6) Action and notification
If action is executed (auto or approved manually), the result is posted back to channels.
If manual review is needed, Telegram inline buttons are sent so an operator can approve in one tap.
Multi-Channel Delivery
Telegram is the primary channel. Slack and Discord webhooks are optional.
Delivery is parallelized. If one channel fails, others still receive messages.
This design avoids single-channel outages becoming blind spots.
Built-In Store Analytics for Humans
The agent keeps a bounded in-memory ledger of recent events and payment records.
That powers natural-language questions through Telegram, such as:
- "revenue this week"
- "how many active subscribers"
- "refunds this month"
- "show recent transactions"
If the LLM fails, the agent falls back to deterministic text summaries, so operators still get an answer.
Reliability Features
- Retry/backoff protection around Creem API calls
- Circuit-style pause when upstream API errors repeat
- Heartbeat warning when no webhooks arrive for too long
- Graceful shutdown cleanup for timers and Telegram polling
Security Model in Plain English
- A webhook is processed only if its signature proves it came from a trusted sender.
- Comparisons use timing-safe checks to reduce side-channel risk.
- Duplicate events are ignored to avoid repeated financial actions.
- Optional external webhooks (Slack/Discord) must be
https://URLs.
What Readers Should Take Away
This is not just a notifier. It is a small operations system:
- Ingest trusted billing events
- Understand customer risk
- Decide with policy constraints
- Act when appropriate
- Report clearly to humans
That combination is what turns webhook traffic into operational leverage. The plugin is opensource and can be found at this Github repo.
Top comments (0)