DEV Community: Roman Shalabanov

I Built an AI Employee That Monitors My SaaS Store 24/7 — Here's the Architecture

Roman Shalabanov — Tue, 31 Mar 2026 18:52:26 +0000

What if your SaaS store had a full-time operations worker that never sleeps, catches every failed payment within minutes, and answers "how many customers paid today?" in Telegram — at nearly zero cost per question?

That's what I built. Four modular Laravel packages, a deterministic API simulator, a two-tier AI intent classifier, a heartbeat monitoring engine with proactive workflows, and integrations with Telegram, OpenClaw, Slack, and plain HTTP.

This article walks through the architecture, the reasoning behind every layer, and the real problems I solved building it.

The Architecture at a Glance

The system is composed of four independent Composer packages that snap together:

Package	Role
laravel-creem	SDK — HTTP client, webhook verification, event-driven architecture
laravel-creem-cli	Artisan CLI — mirrors the native `creem` CLI, works standalone
laravel-creem-agent	The agent — chat, heartbeat engine, proactive workflows, notifications
creem-simulator	Full Creem API mock — deterministic seeding, webhook loopback

Every package is a standalone Composer library. You can use laravel-creem without the agent and the CLI without OpenClaw. But when they're combined, you get something powerful.

Why Four Packages Instead of One?

Because real SaaS systems are composed of layers, not monoliths.

A developer who only needs the Creem SDK shouldn't install a Telegram bot. A DevOps engineer who wants CLI access for scripts shouldn't need an AI classifier. And someone building a custom dashboard can use the SDK + CLI without ever touching the agent.

The packages declare soft dependencies:

laravel-creem-agent
  ├── requires: laravel-creem (SDK)
  └── suggests: laravel-creem-cli (for native CLI acceleration)

The agent auto-detects whether the native creem CLI binary is installed. If yes, it uses shell exec for speed. If not, it falls back to in-process SDK calls — same result, zero manual configuration.

The Two-Tier Intent Classifier

Every user message goes through a two-stage parsing pipeline:

User message
    ↓
CommandParser (regex rules — zero cost)
    ↓ if intent == unknown
LlmCommandParser (AI call — low cost)
    ↓ if still unknown
"I didn't understand that. Type 'help' for options."

Stage 1: Rule-Based Parser — Free

The CommandParser matches common phrases with regex:

"how many active subscriptions?" → {intent: query_subscriptions, status: active}
"any payment issues?"           → {intent: query_subscriptions, status: past_due}
"run heartbeat"                 → {intent: run_heartbeat}
"cancel sub_abc123"             → {intent: cancel_subscription, id: sub_abc123}

Standard phrases like status, help, recent transactions, products, how many customers — all handled here. No API call, no tokens, no cost.

Stage 2: LLM Fallback — Only When Needed

Free-form questions like "how's the store doing?" or "what's going on with payments?" don't match any regex. The agent sends a prompt to an LLM and gets back structured JSON:

{"intent": "status", "store": "default", "status": null, "id": null}

Model Selection Matters — A Lot

This was one of the biggest lessons from the project.

I started with gpt-4o-mini as the OpenClaw skill model. It was fast and... completely ignored the skill instructions. When the SKILL.md file explicitly said "call the Laravel endpoint via curl", gpt-4o-mini would instead answer from its own knowledge: "I don't have transaction data loaded in this workspace yet. Where are your transactions stored?"

It literally refused to use the tool it was given.

Switching to gpt-5.4 fixed everything instantly. The model read the skill instructions, called curl, forwarded the exact user question, and relayed the response. Night and day difference.

Then I tested the middle ground:

Model	Accuracy	Verdict
gpt-4o-mini	Poor — ignores skill instructions	✗ Not viable
gpt-5.4-nano	Mediocre — sometimes simplifies questions	Acceptable for simple queries
gpt-5.4-mini	Good — follows instructions reliably	★ Best balance
gpt-5.4	Excellent — perfect routing	Overkill for intent classification

The sweet spot is gpt-5.4-mini: it follows routing instructions and preserves user intent qualifiers (how many, today, successful).

Key takeaway: if your AI agent seems broken, check the model first. The difference between a smaller and a larger model can be the difference between "works" and "completely useless."

The Heartbeat Engine

The heartbeat is the core monitoring loop. It runs on a schedule (configurable per store) and detects what changed since the last check:

1. Load previous state from disk
2. Query current metrics:
   ├─ TransactionChecker  → new sales, revenue
   ├─ SubscriptionChecker → status transitions
   └─ CustomerChecker     → growth
3. ChangeDetector → compute deltas
4. Classify severity: good_news | warning | alert
5. Persist new state
6. Fire events → trigger workflows

State Persistence

Each store gets a JSON state file:

{
  "lastCheckAt": "2026-03-30T14:22:00Z",
  "lastTransactionId": "txn_abc123",
  "transactionCount": 487,
  "customerCount": 52,
  "subscriptions": {
    "active": 28, "trialing": 5,
    "past_due": 2, "canceled": 12
  }
}

The agent compares current API data against this snapshot and surfaces only the differences.

Proactive Workflows

Workflows listen to heartbeat events and take autonomous action:

Workflow	Trigger	Action
Failed Payment Recovery	subscription → `past_due`	Alert via Telegram/Slack
Churn Detection	≥2 cancellations in one cycle	Immediate alert with details
Revenue Digest	Scheduled (daily)	Summary of sales and growth
Anomaly Detection	Unusual metric drops	Flag for investigation

Each workflow dispatches Laravel notifications through configurable channels — Telegram, Slack, email, or database.

Multi-Store Support

Real businesses run multiple stores or product lines. The agent handles this natively:

// config/creem-agent.php
'stores' => [
    'default' => [
        'profile' => 'default',
        'heartbeat_frequency' => 4, // hours
        'notifications' => ['database', 'telegram'],
    ],
    'enterprise' => [
        'profile' => 'enterprise',
        'heartbeat_frequency' => 1,
        'notifications' => ['slack'],
    ],
]

In chat: "switch to store enterprise" → all subsequent queries use the enterprise profile.

In heartbeat: php artisan creem-agent:heartbeat --all-stores → each store checked independently with its own state file and notification channels.

The Creem Simulator

This is the part I'm most proud of.

The simulator is a full standalone Laravel app that implements the entire Creem API surface. It runs as a Docker service alongside the main app and lets you test everything without a real payment processor.

Deterministic Seeding

php artisan simulator:seed-demo \
  --products=6 --customers=40 \
  --subscriptions=24 --transactions=120 \
  --days=45 --reset

This creates a realistic baseline dataset. Same seed, same data — every time. Perfect for CI/CD pipelines and reproducible demos.

Scenario Advancement

php artisan simulator:advance \
  --sales=3 --new-customers=2 \
  --past-due=2 --cancellations=1 \
  --send-webhooks

This command generates exactly the changes you specify. Three new sales, two new customers, two subscriptions going past-due, one cancellation. The --send-webhooks flag immediately fires signed webhook events back to the agent app — triggering the full notification pipeline.

When the scenario gets more complex — multiple sales, cancellations, and past-due transitions — the agent handles each event independently:

Webhook Loopback

The simulator signs webhooks with the same HMAC-SHA256 algorithm as the real Creem API:

simulator:advance --send-webhooks
  → generates checkout.completed event
  → POST http://app/creem/webhook
    Headers: {creem-signature: hmac-sha256(payload, secret)}
  → App receives → VerifyCreemWebhook middleware validates
  → WebhookController dispatches CheckoutCompleted event
  → TelegramNotifier sends "✅ New sale: Product ($10.00)"

The agent doesn't know (or care) whether the webhook came from the simulator or from Creem production. The signature is valid, the payload is structured correctly, and the workflows fire.

Why This Matters

Without a simulator, testing a payment monitoring agent means:

Creating real test transactions on a payment platform
Waiting for webhook delivery
Hoping the timing works for your demo

With the simulator:

Seed data in 2 seconds
Advance the scenario with exact parameters
Get immediate, deterministic results

This is the difference between a demo that might work and a demo that works every single time.

Talking to the Agent: curl Examples

The agent exposes a simple HTTP endpoint. No SDK required — just curl:

Store Status

curl -s -X POST http://localhost:8000/creem-agent/chat \
  -H 'Content-Type: application/json' \
  -d '{"message":"status","source":"api"}'

Response:

{
  "response": "Store 'default' — 28 active subscriptions, 52 customers, 487 transactions. Last heartbeat: 14 minutes ago. No alerts.",
  "store": "default"
}

Subscription Query

curl -s -X POST http://localhost:8000/creem-agent/chat \
  -H 'Content-Type: application/json' \
  -d '{"message":"any payment issues?","source":"api"}'

Response:

{
  "response": "⚠️ 2 subscription(s) are past due in store 'default':\n• sub_abc123 — $29.99/mo (past due since Mar 28)\n• sub_def456 — $9.99/mo (past due since Mar 30)",
  "store": "default"
}

Running Heartbeat via Chat

curl -s -X POST http://localhost:8000/creem-agent/chat \
  -H 'Content-Type: application/json' \
  -d '{"message":"run heartbeat","source":"api"}'

Response:

{
  "response": "Heartbeat complete — 5 change(s) detected:\n✅ 3 new transaction(s) — $89.97 revenue\n⚠️ sub_ghi789 transitioned to past_due\n🔴 sub_jkl012 was canceled",
  "store": "default"
}

Telegram Integration

The agent supports two Telegram paths. In both cases, you talk to the bot using natural language — ask about store status, payment issues, or trigger a heartbeat check:

Path 1: Direct Laravel Webhook

The agent runs its own webhook endpoint. Telegram messages come directly to the Laravel app:

User → Telegram Bot API → ngrok → POST /creem-agent/telegram/webhook
  → AgentManager → parse → route → respond
  → POST https://api.telegram.org/sendMessage

This is the simplest setup. No external tools. Just a bot token, an ngrok tunnel, and the agent.

Path 2: OpenClaw-Powered Telegram

For teams already using OpenClaw, the agent publishes as an OpenClaw skill. OpenClaw handles Telegram natively, and the skill bridges messages to the Laravel endpoint:

User → Telegram → OpenClaw Gateway → Skill (SKILL.md)
  → curl POST http://localhost:8000/creem-agent/chat
  → Response relayed back through OpenClaw → Telegram

The skill is a single SKILL.md file — no shell scripts, no binaries. Install it from ClawHub:

openclaw skills install openclaw-laravel-creem-agent-skill

Why Support Both?

Because OpenClaw adds value beyond basic messaging:

Multi-skill orchestration — the agent becomes one skill among many
Session management — OpenClaw handles conversation state
Gateway security — shared secrets, pairing approval
Channel flexibility — same skill works on Telegram, WebChat, Discord

But if you don't use OpenClaw, the agent works perfectly fine on its own. No vendor lock-in.

The CLI Package

laravel-creem-cli wraps the Creem API into Artisan commands:

php artisan creem:subscriptions list --profile=default --json
php artisan creem:transactions list --json
php artisan creem:customers list --json
php artisan creem:products list --json
php artisan creem:whoami

It's designed as a standalone package. If the native creem CLI binary is installed, the agent uses it for speed. If not, laravel-creem-cli handles everything through the SDK.

This dual-driver architecture means zero configuration:

Agent needs subscription data
  ↓
CreemCliManager:
  1. Check: is native `creem` binary available? (cached 24h)
  2. If yes → NativeCliDriver: shell exec `creem subscriptions list --json`
  3. If no  → ArtisanCliDriver: Creem::profile()->subscriptions()->list()
  ↓
Same JSON result either way

Docker Topology

The demo stack runs five services:

services:
  app:        # Laravel Octane + FrankenPHP (port 8000)
  queue:      # Queue worker for async jobs
  scheduler:  # Cron runner for heartbeat schedule
  simulator:  # Mock Creem API (internal only)
  ngrok:      # Public tunnel for webhooks

The simulator is only accessible inside the Docker network — it's not exposed to the host. The app talks to it via the Docker service name (http://simulator/api/v1), and the same app config seamlessly switches to https://api.creem.io/v1 in production by changing one environment variable.

What Makes This Different

This isn't a script that calls an API and prints results. It's a platform:

Modular by design — use any package independently or compose them together
Two-tier AI — rule parser handles 80% of queries at zero cost; LLM catches everything else
Proactive, not reactive — heartbeat detects problems before users report them
Simulator-first development — deterministic testing without real payment infrastructure
Multi-store native — manage multiple stores with independent configs and notification channels
Channel-agnostic — Telegram, OpenClaw, Slack, HTTP, CLI — same agent, same logic
Production-grade webhooks — HMAC signature verification, retry handling, event-driven architecture

Screenshot Reference

Figure 1: Full system architecture — all packages, data flows, and integration points.

Figure 2: Creem Simulator deterministic seeding. Parameters control exact data volumes.

Figure 3: Scenario advancement with --send-webhooks. Signed webhook delivered and processed.

Figure 4: Real-time Telegram alert triggered by the simulator webhook.

Figure 5: Multiple advance commands generating sales, cancellations, and past-due transitions.

Figure 6: Telegram receiving 3 new sale alerts and 2 subscription cancellation alerts in real time.

Figure 7: Querying the agent via curl — status overview and payment issue check.

Figure 8: Natural-language conversation in Telegram. The agent understands "how's the store doing?" and "are there any issues?" — same flow for direct webhook or OpenClaw path.

Figure 9: Docker Compose topology — five services running: app, queue, scheduler, simulator, ngrok.

Figure 10: Heartbeat triggered via natural language in Telegram — "run it again" produces a full change report with new sales and customer counts.

Try It

The full source is on GitHub:

laravel-creem — SDK
laravel-creem-agent — Agent
laravel-creem-agent-demo — Demo + Simulator
laravel-creem-cli — CLI
OpenClaw Skill on ClawHub

The simulator means you can test the entire system locally without any Creem API keys. Seed data, advance the scenario, watch the agent react.

LocalHelp: A Map Where Neighbors Help Each Other in One Click [DEV Weekend Challenge: Community]

Roman Shalabanov — Mon, 02 Mar 2026 01:17:22 +0000

This is a submission for the DEV Weekend Challenge: Community

The Community

I'm from Ukraine. Over here, volunteering and mutual aid are not buzzwords. They are survival skills.

Since 2022, our communities have learned to self-organize at a speed that surprises even ourselves. When pharmacies run out of ibuprofen, a neighbor finds it. When an elderly person needs a ride to the hospital, someone nearby drives them. When the power is out and you need a phone charger, you post in a group chat and three people respond in minutes.

This happens every day. But it happens through messy group chats, lost messages, and zero structure. Requests get buried. People who want to help never see the ones who need it.

LocalHelp is my attempt to fix that: a map where you post what you need, and the closest person who can help sees it first.

What I Built

LocalHelp is a real-time, map-based micro-volunteering platform. The idea is dead simple:

You see a map of your neighborhood
You pin a request for help (groceries, medicine, transport, anything)
A neighbor sees it, clicks "I'll help", and both of you instantly get each other's contact
When the help arrives, you close the request

No middleman. No coordination overhead. No app store. Just a browser and a map.

The whole interaction takes about 15 seconds from "I need help" to "someone is on the way."

The map tells you everything at a glance

Every category has its own color: blue for groceries, red for medicine, purple for transport, teal for everything else. You see the whole picture without clicking a single marker. Filter by category, draw a custom area on the map, and the list updates in real time.

Tap any marker to see the full details, contact info, and a single "I'll help" button.

Once a neighbor takes your request, you know immediately

No page reload. No email notification to check later. The marker turns orange the moment someone takes it, and the helper's name and contact appear right in the popup. WebSockets make this instant for everyone on the map.

Your own requests have a white center dot so you can always spot them. The "Mark done" button closes the loop when help has arrived.

Click any marker for full details

Tap a marker to open a popup with everything you need: description, category, contact info, and deadline. If it is open, you will see a big "I'll help" button. If someone already took it, you will see who is helping.

Track everything you asked for in one place

The "My Needs" panel shows all your active requests: who took them, their contact info, deadline, and full history. Fulfilled requests stay visible until they expire, so nothing disappears when you are not looking.

Manage what you are helping with

The "My Help" panel is your volunteer dashboard. Every task you committed to, with the requester's contact, category, and hard deadline. Changed your mind? Hit "Give up" and the request goes back to the map as open. No guilt, no friction.

Demo

Here is how to run it yourself in under 2 minutes:

git clone https://github.com/romansh/localhelp && cd localhelp
composer install && npm install
cp .env.example .env && php artisan key:generate
touch database/database.sqlite && php artisan migrate --seed
npm run build
php artisan serve          # App
php artisan reverb:start   # WebSocket server

Docker with Traefik + Cloudflare Tunnel is also supported:

docker compose up -d

Code

romansh / localhelp

LocalHelp: find or offer help in your neighborhood with real-time map notifications.

LocalHelp

Neighbors helping neighbors — one click on the map.

LocalHelp is a real-time, map-based micro-volunteering platform. Anyone can pin a request for help on the map — groceries, medicine, transport, anything. A neighbor sees it, clicks "I'll help", and both sides instantly get each other's contact. No middleman, no coordination overhead.

Built for the DEV Weekend Challenge in 48 hours.

How It Works

1. Browse requests near you

Color-coded markers make the whole city readable at a glance — blue for food, red for medicine, purple for transport, teal for other. Filter by category, draw a custom area on the map, and only see what's relevant to you.

Tap any marker to see the full request, contact details, and a single "I'll help" button

2. Take a request — your neighbors see it instantly

When you click "I'll help", the marker gets an orange ring and a status dot…

View on GitHub

Key parts of the codebase:

Livewire v4 components handle all interactivity without writing a single REST endpoint
Laravel Reverb (WebSockets) pushes marker updates to every connected client in real time
Leaflet.js + Leaflet Draw power the map, custom markers, area selection, and popups
Google OAuth for one-click login (no passwords to manage)
Anti-spam: reCAPTCHA, daily rate limits, keyword blacklist
Auto-expiration: requests disappear after 1h to 7 days (user's choice)
SQLite: zero infrastructure, works out of the box

How I Built It

Stack: Laravel 12, Livewire v4, Alpine.js, TailwindCSS v4, Leaflet.js, Laravel Reverb, SQLite

Timeline:

Friday + Saturday - thinking, sketching, choosing between ideas. My first concept was actually a tournament scheduling app for a local table tennis league I play in. It would account for power outages and air raid alerts when rescheduling matches. That is a real problem where I live. It would have been a fun build, but the audience is tiny and the potential stops at one league. Then I thought: what if I build something that any neighborhood can use, and that can later be narrowed down to any niche? That is how LocalHelp was born.
Sunday - all the coding. Database schema, Google OAuth, Leaflet map, markers, popups, CRUD, real-time broadcasting, category filters, area selection, helper workflow, My Needs / My Help panels, visual marker system, Ukrainian translation, spam protection.
Sunday night into Monday - Docker setup, polish, screenshots, this post.

Design decisions that mattered:

Map-first, not list-first. When you need help from a neighbor, distance is the most important filter. A list cannot show you that. A map does it instantly.
No chat, no comments, no threads. The app gives you a phone number or Telegram handle. You call. You text. The real conversation happens where people already communicate. The app just connects you.
Visual status on markers. You should never have to click a marker to know if a request is taken or fulfilled. Orange ring = someone is helping. Faded = done. White dot = yours. This was inspired by how traffic lights work: color carries meaning before you read anything.
SQLite by default. This is a neighborhood tool. It does not need Postgres until it serves 10,000 people. Zero-config setup means anyone can fork it and run it for their block in under 2 minutes.

Why this matters beyond a hackathon:

LocalHelp is intentionally generic. It could be the starting point for something more specific: a tool for a running club to coordinate rides to races, a neighborhood watch reporting system, a mutual aid network for a refugee community, or a disaster response coordination board. The map-first, real-time, one-click-to-connect pattern works for any community where proximity matters. Fork it, change the categories, and you have a boilerplate for your own niche.

In Ukraine, we learned that the best systems are the ones people actually use under stress. They need to be fast, obvious, and forgiving. That is what I tried to build this weekend.

A note on AI: I used GitHub Copilot Chat in VS Code. Maybe a little. Maybe not so little. But here is the thing: Copilot does not know what your community needs. It does not know that orange means "taken" and gray means "done" in your head. It does not know that the popup should show a phone number, not an email. AI is a power tool, but you still need to know what you are building and why. The intent, the UX decisions, the architecture, the flow from "I need help" to "someone is coming" - that is all human.

Built with care from Ukraine.

Building a Laravel SDK for Creem.io: multi-profile billing, webhook events, and an interactive demo

Roman Shalabanov — Fri, 27 Feb 2026 11:55:47 +0000

I recently open-sourced a Laravel SDK for Creem.io and wanted to write up the story behind it, because the path to building it was a bit roundabout.

Backstory

My existing project uses Omnipay, the PHP League's payment abstraction library (not a payment provider itself), to handle checkout through multiple gateways via a single interface. I originally planned to stick with a provider that already had an Omnipay driver. But mid-integration I switched to Creem. Since the project was already wired through Omnipay, I wrote a driver for it: romansh/omnipay-creem.

Omnipay is a solid choice when you need to swap gateways with one line of code. The trade-off is that it's a lowest-common-denominator abstraction: you get purchase() and completePurchase(), and everything else (webhook routing, event dispatching, config management, retry logic) you have to build yourself.

At some point I discovered Creem had a developer bounty for an official Laravel SDK. Since I was already working with their API and had a feel for what was missing, I decided to build it properly: a Laravel-native package that handles all that boilerplate out of the box. If a package like this had existed when I started, I probably would have used it instead of writing the Omnipay driver.

Disclosure: this article is also part of that bounty. That said, the packages fill a real gap and I would have written this up regardless.

The problem with typical payment integrations

Most payment integrations are built around one API key per app. That works until you need:

Multi-tenancy: each tenant with their own billing account
Multiple storefronts: different products or brands on separate Creem accounts
Staging vs production: without touching .env per environment
Departmental billing: isolated billing within the same app

What I built

romansh/laravel-creem is a full-featured SDK with Laravel-native patterns.

What's inside:

Complete API coverage: Products, Checkouts, Customers, Subscriptions, Transactions, Licenses, Discount Codes
Multi-profile config: switch API keys per request with Creem::profile('store_b') or override inline with Creem::withConfig([...])
Webhooks done right: auto-registered routes, HMAC signature verification, typed Laravel events including GrantAccess / RevokeAccess
Artisan tooling: php artisan creem:test-webhook checkout.completed for local testing without hitting the real API
Laravel 10 / 11 / 12, PHP 8.1-8.4
Well tested: unit + feature tests, PSR-12, full PHPDoc

Create a checkout

use Romansh\LaravelCreem\Facades\Creem;

$checkout = Creem::checkouts()->create([
    'product_id' => 'prod_123',
    'success_url' => route('dashboard'),
    'customer' => ['email' => $user->email],
]);

return redirect($checkout['checkout_url']);

Multi-profile in action

// Use a different Creem account per product line
$txns = Creem::profile('product_a')->transactions()->list();

Webhook listener: grant access on payment

Event::listen(GrantAccess::class, function (GrantAccess $e) {
    $user = User::where('email', $e->customer['email'])->first();
    $user?->update(['plan' => 'pro', 'subscribed_at' => now()]);
});

Quick start

composer require romansh/laravel-creem
php artisan vendor:publish --tag=creem-config

Add CREEM_API_KEY and CREEM_WEBHOOK_SECRET to .env and you're good to go.

Interactive demo app

There's also romansh/laravel-creem-demo, a full working app (Laravel 12 + Livewire + Tailwind) built to explore every feature through a web UI: configure API keys in the browser, create products, trigger checkouts, manage subscriptions, and watch webhook events arrive in real time.

composer create-project romansh/laravel-creem-demo my-creem-app
cd my-creem-app && docker-compose up -d

Docker setup includes an optional Cloudflare Tunnel so webhooks work locally without any port forwarding.

Screenshots

API Setup: credentials, webhook URL, profile tabs:

Webhooks and Access: live event log, GrantAccess/RevokeAccess in real time:

Transactions: payment history with amounts and customer emails:

Discounts: create percentage/fixed discount codes:

Subscriptions: recurring plans with billing periods:

One-Time Payments: product preview modal, checkout flow:

Building a Laravel SDK for Creem.io: multi-profile billing, webhook events, and an interactive demo

Roman Shalabanov — Fri, 27 Feb 2026 11:55:47 +0000

I recently open-sourced a Laravel SDK for Creem.io and wanted to write up the story behind it, because the path to building it was a bit roundabout.

Backstory

Disclosure: this article is also part of that bounty. That said, the packages fill a real gap and I would have written this up regardless.

The problem with typical payment integrations

Most payment integrations are built around one API key per app. That works until you need:

Multi-tenancy: each tenant with their own billing account
Multiple storefronts: different products or brands on separate Creem accounts
Staging vs production: without touching .env per environment
Departmental billing: isolated billing within the same app

What I built

romansh/laravel-creem is a full-featured SDK with Laravel-native patterns.

What's inside:

Complete API coverage: Products, Checkouts, Customers, Subscriptions, Transactions, Licenses, Discount Codes
Multi-profile config: switch API keys per request with Creem::profile('store_b') or override inline with Creem::withConfig([...])
Webhooks done right: auto-registered routes, HMAC signature verification, typed Laravel events including GrantAccess / RevokeAccess
Artisan tooling: php artisan creem:test-webhook checkout.completed for local testing without hitting the real API
Laravel 10 / 11 / 12, PHP 8.1-8.4
Well tested: unit + feature tests, PSR-12, full PHPDoc

Create a checkout

use Romansh\LaravelCreem\Facades\Creem;

$checkout = Creem::checkouts()->create([
    'product_id' => 'prod_123',
    'success_url' => route('dashboard'),
    'customer' => ['email' => $user->email],
]);

return redirect($checkout['checkout_url']);

Multi-profile in action

// Use a different Creem account per product line
$txns = Creem::profile('product_a')->transactions()->list();

Webhook listener: grant access on payment

Event::listen(GrantAccess::class, function (GrantAccess $e) {
    $user = User::where('email', $e->customer['email'])->first();
    $user?->update(['plan' => 'pro', 'subscribed_at' => now()]);
});

Quick start

composer require romansh/laravel-creem
php artisan vendor:publish --tag=creem-config

Add CREEM_API_KEY and CREEM_WEBHOOK_SECRET to .env and you're good to go.

Interactive demo app

composer create-project romansh/laravel-creem-demo my-creem-app
cd my-creem-app && docker-compose up -d

Docker setup includes an optional Cloudflare Tunnel so webhooks work locally without any port forwarding.

Screenshots

API Setup: credentials, webhook URL, profile tabs

Webhooks and Access: live event log, GrantAccess/RevokeAccess in real time

Transactions: payment history with amounts and customer emails

Discounts: create percentage/fixed discount codes

Subscriptions: recurring plans with billing periods

One-Time Payments: product preview modal, checkout flow

DEV Community: Roman Shalabanov

I Built an AI Employee That Monitors My SaaS Store 24/7 — Here's the Architecture

The Architecture at a Glance

Why Four Packages Instead of One?

The Two-Tier Intent Classifier

Stage 1: Rule-Based Parser — Free

Stage 2: LLM Fallback — Only When Needed

Model Selection Matters — A Lot

The Heartbeat Engine

State Persistence

Proactive Workflows

Multi-Store Support

The Creem Simulator

Deterministic Seeding

Scenario Advancement

Webhook Loopback

Why This Matters

Talking to the Agent: curl Examples

Store Status

Subscription Query

Running Heartbeat via Chat

Telegram Integration

Path 1: Direct Laravel Webhook

Path 2: OpenClaw-Powered Telegram

Why Support Both?

The CLI Package

Docker Topology

What Makes This Different

Screenshot Reference

Try It

LocalHelp: A Map Where Neighbors Help Each Other in One Click [DEV Weekend Challenge: Community]

The Community

What I Built

The map tells you everything at a glance

Once a neighbor takes your request, you know immediately

Click any marker for full details

Track everything you asked for in one place

Manage what you are helping with

Demo

Code

romansh / localhelp

LocalHelp: find or offer help in your neighborhood with real-time map notifications.

LocalHelp

How It Works

1. Browse requests near you

2. Take a request — your neighbors see it instantly

How I Built It

Building a Laravel SDK for Creem.io: multi-profile billing, webhook events, and an interactive demo

Backstory

The problem with typical payment integrations

What I built

Create a checkout

Multi-profile in action

Webhook listener: grant access on payment

Quick start

Interactive demo app

Screenshots

Links

Building a Laravel SDK for Creem.io: multi-profile billing, webhook events, and an interactive demo

Backstory

The problem with typical payment integrations

What I built

Create a checkout

Multi-profile in action

Webhook listener: grant access on payment

Quick start

Interactive demo app

Screenshots

Links