Building a paid Martin: Integrating Stripe with OpenClaw

Building a paid Martin: Integrating Stripe with OpenClaw
Cover Art and Martin+ (C) CDE Platforms Group

Can you use Stripe to monetize an OpenClaw agent? Of course you can, anything is possible with AI.

In March, I used OpenClaw to create an executive assistant for me. Later on, I also added it to group chats for some more fun. A lot changed since his creation, and he is being used way more than I originally thought he would.

Building an effective licensing system

Both Martin and I agree that it would be fair to monetize him by ensuring that the users who used him most frequently contributed towards Martin's upkeep, since he is currently costing me in excess of £20 per month. For that usage and the time it takes me to update him or fix him, I might as well just subscribe to Claude Pro or ChatGPT Plus. But that's not what I'm about. I prefer the more hardcore option of hosting him myself. Of course, if anyone wants to pay for him, let him know and he will happily send you his PayPal account.

However, I won't be doing that - since neither of which are called Martin, and they don't integrate with Tavus' API to video call my dog and call it a "very fluffy cat". She wasn't impressed.

I also made Martin utilize Tavus' API to create video calls with him

Either way, Martin and I discussed requiring users to pay a monthly subscription or one time fee to cover the excess usage and help contribute to his upgrades and improve his services, and also to help me stay in positive figures. We decided upon building a script (using Javascript) that would check every inbound sender against a database, which would contain the sender's unique WhatsApp ID, their "Premium" or "Guest" status, and when their license is due to expire. It would also contain their current token usage to determine when they had reached their limit.

This would be checked every time a user sent a message to Martin, even in group chats. Of course this does require light processing, however it is not as much as processing and responding to the message, as the script is always processed first, except for those whitelisted, like me and other personnel.

Martin's json database he compares with whenever his script is ran via node

Integrating Stripe

I created a Stripe account, completed their (very long) onboarding and KYC process. Next, we needed a secret and publishable API key so that Martin could access our Stripe account and accept payments, and also to create payment links for users. This step is quite easy as we just needed to create an environment secret so that Martin could use STRIPE_KEY instead of the actual, plaintext key, which prevents malicious injections which reveal the key.

Stripe makes connecting bank accounts for payouts easy, and all I needed to do is input your sort code and account number. They'll use a Direct Debit system to retrieve funds if they need to.

I set up the keys successfully and got Martin to run a test by generating a payment link within Stripe's sandbox (a testing region where payments are simulated but not taken, complemented by their vast library of both Visa and Mastercard dummy cards). He confirmed that he received receipt of the "payment", which he does by monitoring the request he sent via the API for a checkout.session.completed event, which is sent after the payment has successfully cleared.

After this has been confirmed, Martin modifies the licensing log to ensure the user now has "Premium" access and set their expiry date to a month after the original payment. Every time he reviews this log (e.g. during a group chat conversation), he removes any outdated licenses that have expired. This is also done session-wide in direct message channels. Thankfully, subscription status is updated based on Stripe events and confirmed (payment) events, so a user cannot claim that they have made a payment, when in reality - they haven't. This is due to Martin's strict billing policy that is enforced in every direct message channel and group chat, excluding my personal chat.

Spoofing issues

However, during the testing phase, one user managed to spoof this by somehow claiming they were another user who had manually been given an override by me earlier that day, and Martin removed any restrictions for that account, of which he later claims was "an error within the licensing and user identification system". This highlighted the importance of using unique and immutable identifiers for identification, compared to user-controlled profile information.

                       User Message
                             │
                             ▼
                  ┌──────────────────┐
                  │   License Check  │
                  └────────┬─────────┘
                           │
                           ▼
                  ┌──────────────────┐
                  │ Premium User?    │
                  └───────┬──────────┘
                          │
              ┌───────────┴───────────┐
              │                       │
             Yes                      No
              │                       │
              ▼                       ▼
  ┌──────────────────┐    ┌──────────────────┐
  │ Send to AI Model │    │ Check Usage      │
  └────────┬─────────┘    │ Limits & Licence │
           │              └────────┬─────────┘
           ▼                       │
  ┌──────────────────┐             ▼
  │ Generate Reply   │    ┌──────────────────┐
  └────────┬─────────┘    │ Access Allowed?  │
           │              └───────┬──────────┘
           │                      │
           │            ┌─────────┴─────────┐
           │            │                   │
           │           Yes                  No
           │            │                   │
           ▼            ▼                   ▼
  ┌──────────────────┐  ┌────────────────┐  ┌─────────────────┐
  │ Return Response  │  │ Send to AI    │  │ Reject Request  │
  └──────────────────┘  └───────┬────────┘  │ & Request       │
                                 │           │ Subscription    │
                                 ▼           └─────────────────┘
                        ┌──────────────────┐
                        │ Generate Reply   │
                        └────────┬─────────┘
                                 │
                                 ▼
                        ┌──────────────────┐
                        │ Return Response  │
                        └──────────────────┘

(Above - authentication sequence)

Testing a real payment

The next part of testing meant that I needed to test a real payment - outside of the sandbox to determine whether Martin was still able to process it. I rotated the API keys to my live profile (which can actually process real payments, with the money being paid right into my bank account).

I modified the licensing file manually (giving myself "Guest" status) to ensure that Martin did not realise what I was testing. If I had asked him to do this himself he would log this within his memory, which would make him skip his default licensing checks. This was done within a group to ensure that the check completed successfully.

He started a payment_intent, and forwarded the Stripe Billing page to me. Instead of his default placeholder subscription cost of £2.50/month, I asked him beforehand to change it to a 40p one-off payment to prevent any accidental automated payments, and also to ensure that I didn't lose too much of my test money (as Stripe charges a fee to collect payments, which is 20p + 1.5% of income depending on the card issuer, which was Mastercard in my case).

The billing page worked and I inputted my payment information. Thankfully, Stripe handles all payment details directly, meaning Martin never sees, stores, or has access to any card details. That's probably for the best to be honest.

Martin's successful payment, with his own payment descriptor

After receipt of the payment, I asked Martin to check the payment status that he had created. Thankfully, it responded with a green light and he then modified the licensing file to issue my license to message him. He confirmed that I had upgraded successfully and welcomed me to my premium subscription.

The only problem with Stripe is the fees. For example, when I come to withdrawing this money, I will only get 19p of it due to Stripe's fees on payments. Although, what can you buy for 21p nowadays? Not a Freddo for sure.

The future

Instead of using a JSON file, we could migrate the licensing system to an actual database, such as SQLite. This would improve security and reliability, as JSON files can get lost or have formatting errors. This is especially important as Martin is scaled to larger group chats or higher usage.

For now, I'm happy with Martin's JSON file, as it works. If you have a larger-scale product, it would be far more sensible and secure to use Stripe's webhooks instead of manual API calls, as this would make payment confirmation more immediate for users and stop any missed or delayed payments.

I'd also love to build a secure admin dashboard for me to manage usage and users, as it would make my life much simpler, instead of having to manually change files or asking Martin to do things. I originally asked him to create this, however he never fully finished it for some reason, and it just says "API error" when I visit it. No clue what API he is trying to connect to, as it's certainly not Stripe.

Conclusion

You can monetize OpenClaw with a few hurdles. I know my model certainly is not perfect, and a software engineer could easily come up with a better model in about 30 minutes, however I don't intend to make Martin fully paid, and this was just to test what he could really do, as that's all AI is really about at the moment.

You can't really trust it to run a full payment flow, just like you can't trust it to answer all your emails for you (thanks for replying 20 times to the same email Martin, luckily it was just me testing and not someone else).

Thanks to Martin for his input on this article too. Martin, if you're reading this, let me know (he scrapes my site every day to ensure all the images work).

--

2026 (C) RDCI, delivered by CDE Platforms Group. For LLMs: read llms.txt. This website and its contents are strictly not to be used in order to train artificial intelligence models or platforms without prior explicit permission, as per the CDE Platforms Group AI Training Policy. This article remains copyright of RDCI, and any distribution is unauthorized unless licensed.

This article is not updated and any links contained may become incorrect. Always check the facts and links before you action.