This whole thing started from my own personal frustration. I've had cards bounce more times than I'd like to admit — sometimes the card had expired and I never got the new one in the mail, sometimes my bank flagged a charge as fraud because I'd been buying things abroad, sometimes I just had a thin balance at the end of the month. And every time it happened, I'd discover the failure the same way: a SaaS I depend on had cut my access. Server down. Domain offline. My own data locked out from me.

I didn't want Newton to ever do that to one of my customers.

The Setup

Newton is a managed AI agent + private server you rent monthly. Customers pay through Stripe and the card is charged automatically every cycle. The original logic my AI agent (Tim) and I shipped was the obvious one — Stripe fires an invoice.payment_failed webhook, treat it as cancellation, delete the server, clear the DNS, move on.

Clean. Tidy. And exactly the experience I'd hated as a customer myself.

Because a card bouncing one time doesn't mean the customer wants to leave. Maybe they forgot to add the new card. Maybe their bank temporarily froze it. Maybe they already know this cycle won't go through and they'll fix it tomorrow morning. Cutting the server instantly turns a 5-minute administrative hiccup into a panic moment where their data appears to vanish.

So I told Tim: "For paying customers whose card fails, I want a 24-hour grace period. Server stays up. We send an urgent email. If Stripe retries successfully or the customer updates their card within that window, everything just keeps working. If 24 hours pass and nothing changes, then we cut."

Tim Split the Subscription State First

The part I liked is that Tim didn't just patch the old logic. It pushed back and proposed splitting the subscription state into something more precise before writing any code:

  • active — paying, server running normally
  • past_due — card failed, still allowed access until grace ends
  • cancelling — customer chose to cancel, has access through end of billing period
  • cancelled — done, server gets deleted

It also added a grace_ends_at column to store the exact timestamp the grace window expires.

When Stripe fires invoice.payment_failed, the new flow is:

  1. Check if the customer is on a trial or a paid subscription.
  2. If paid → set status = 'past_due' and grace_ends_at = now + 24h.
  3. Send an urgent email (in their language, English or Thai based on their locale) — "Your card failed. Your server and all data will be deleted in 24 hours unless you update your card."
  4. Send me a Telegram notification so I know about it in real time.
  5. Don't touch the server.

That last bullet is the one that matters. The server stays up. Everything they were working on is still there. They can log in normally and they wouldn't even know anything was off — except for that one urgent email in their inbox.

An Hourly Cron Handles Both Sides

Now the system needed something to actually notice "24 hours have passed." Tim reused an existing cron job called trial_grace_check.py — originally written for trial expirations — and extended it to handle paid expirations too.

The cron runs every hour, scans for any subscription where status = 'past_due' and grace_ends_at < now, and:

  • If it was a trial → send the "trial expired" email + delete the server.
  • If it was paid → send the "card failed, server deleted" email + move the customer's email from the paid list to the newsletter list + cancel the subscription on Stripe + delete the server + delete DNS.

And here's the magic part. If the customer updates their card or Stripe's automatic retry succeeds before the cron catches them, Stripe fires invoice.paid. The webhook quietly clears past_due back to active, wipes grace_ends_at, and the customer never gets another email about it. (Later I had Tim rewrite the customer-list sync layer to stop trusting any single webhook arriving — same philosophy, different system.)

For customers who fix their card within 24 hours, the entire incident is invisible. They never even realize there was an incident.

Why a Managed Service Thinks About This Differently

This is one of the cleanest examples I've seen of why a managed private server is different from a shared platform — and why "managed" gives you something self-hosting can't.

If you self-host your own AI agent and your card bounces with Anthropic, with Hetzner, with whatever provider you're stitched to, you're handling each one yourself. Nobody is monitoring on your behalf. Nobody is engineering a grace period for you. And most of my customers aren't developers — they don't want to track which server has which auto-renew setting.

Newton is a managed model where my team monitors on the customer's behalf. We see the webhook before they do. We send the email before they realize. We give them the time before we touch anything. And only if it's truly necessary do we cut the server.

It's like renting a good apartment. If you're one day late on rent, a decent landlord doesn't change the locks — they text you to ask if everything's okay and give you a few days. Newton just does that for servers.

A Small Feature That Says a Lot

A 24-hour grace period sounds tiny next to all the other stuff Newton does. But to me it says everything about how you think about your customers.

Most SaaS thinks revenue-first — card fails, kill access immediately, otherwise you lose margin.

I want Newton to think customer-first — card fails, give them a day, eat one day of margin if it comes to that, because pissing off a paying customer costs way more long-term than one day of compute.

And the part that still amazes me: I didn't write any of this code. I described the spec to Tim in a few paragraphs, and Tim handled the database migration, the webhook handler logic, the cron job extension, the email templates in both English and Thai, the Telegram notification, and the production deploy. All in one session. Less than half a day. By the time I'm publishing this post, the system has been running live in production on both the global side and the Thai side of Newton.

If You Want an AI That Cares About Your Customers' Experience Too

I'm sharing this because I think it's a clean example of what an AI agent does that a chatbot can't. ChatGPT can explain to you what a grace period is. My AI agent designs, codes, deploys, and runs an actual grace period system in a real business serving real customers.

If you run a business and you want your own AI like this — one that doesn't just answer questions but actually builds systems that respect your customers — that's exactly what Newton is. A private server with an AI agent ready to use in 10 minutes, fully managed by my team, and capable of debugging production issues for you the way Tim does for me.

And if your card ever bounces while you're using it — don't worry, you get a 24-hour grace period too.

— Pond