We don't just talk about automation -- we run on it. This is the pipeline that records every
sale our own products make and lets us check live revenue from a phone with one command. We
build what we use.
The problem
"How much did we make today?" usually means logging into a payment dashboard, an analytics
console, and a spreadsheet, then reconciling the three by hand. It does not scale, and nobody
does it at 3am.
Worse is the failure you cannot see: a payment succeeds at the gateway but never gets recorded
in your own ledger. You only find out when a paying customer loses access to the thing they
just bought. A fire-and-forget integration reports "charge succeeded" and moves on -- the
entitlement quietly never gets written.
So we built one pipeline that records the sale durably, reconciles it across sources, and
surfaces the number on demand.
The workflow
[ Payment webhook ] -> [ Verify + record ] -> [ Aggregate 3 sources ] -> [ Phone command ]
signature signed to durable ledger gateway / analytics /revenue + daily push
write-scoped token / ledger, PII-safe
1. A webhook that verifies before it trusts
The payment webhook is registered to the live endpoint and verified by signature, with the
webhook ID configured. Forged or replayed events are rejected, not trusted. Verification is the
difference between "an event arrived" and "an event we can act on."
2. A durable ledger write -- the part that bit us
Completed payments are appended to a server-side ledger. This is exactly where we hit a real
silent-failure bug: the write was using a token without write scope and failing quietly with a
- Nothing crashed, nothing alerted -- the sale just never landed. The fix was a correct write-scoped token threaded across every function that touches the ledger. That class of reliability gap is what separates a demo from a system you can bill on.
3. Three-source reconciliation
Revenue is cross-checked across three independent sources: the payment gateway (an on-demand
24-hour query), product analytics (a daily pull), and the server-side ledger. A figure that
shows up in one source but not the others gets caught immediately instead of weeks later. Owner
test payments are auto-separated from real customer payments, so internal testing never inflates
the number.
4. Phone-native reporting
A /revenue style command in a chat bot returns the live figure in seconds. A scheduled job
also pushes a daily summary unattended. A separate aggregation endpoint returns totals only --
zero customer PII leaves the server -- and is key-protected.
The result
- Revenue answerable from a phone in seconds instead of a multi-dashboard reconciliation.
- Three independent sources cross-checked, so there is no single point of mis-reporting.
- A class of silent ledger-write failure was found and closed before it could corrupt a real customer's entitlement.
- A daily revenue summary is delivered automatically, with no one watching the dashboards.
Stack
Signature-verified payment webhook - serverless functions - a durable ledger write with a
write-scoped token - a daily analytics pull - a chat-bot command plus a scheduled daily push - a
key-protected aggregation endpoint that returns totals only, no PII.
The takeaway
Any business taking online payments needs two things this delivers: a way to know a successful
charge was actually recorded on your side, and a revenue number you can trust without a finance
ritual. The signature verification and the three-source reconciliation are the trust layer that
quick integrations skip. And the bug worth stealing the lesson from: a write that fails quietly
is more dangerous than one that crashes loudly -- the most expensive automation bugs are the
ones that still report success.
We build automation systems like this for businesses drowning in repetitive busywork --
content, reporting, customer replies, lead follow-up. If a daily task is eating your team's
hours, that's usually a one-time build away from running itself.
Top comments (0)