Live
Live API-to-CRM integration showpiece
The showpiece pulls public feeds into a small CRM through four timed stages. It has recorded 200+ pulls, with a median total of 0.40 s for the four stages combined.
A test payment that marks the order paid exactly once.
For owners whose payments and records drift apart: a Stripe checkout in test mode, wired to mark the matching record Paid exactly once.
Stripe test checkout Book a live run-through Checked
The check every Stripe message must pass before the demo reads it
const signed = Buffer.concat([Buffer.from(`${parsed.t}.`), body]);
let match = false;
for (const secret of [].concat(secrets).filter(Boolean)) {
const expected = crypto.createHmac('sha256', secret).update(signed).digest();
for (const candidate of parsed.v1) {
// no early exit: keep the work independent of which value matched
if (crypto.timingSafeEqual(expected, Buffer.from(candidate, 'hex'))) match = true;
}
}
if (!match) return done({ ok: false, reason: 'signature_mismatch' });
Real lines of the demo server: an HMAC-SHA256 over the timestamp and the exact raw bytes, compared in constant time; an edited body fails as signature_mismatch.
How checkout works
Today someone on your team sees a payment email and retypes it into the CRM, the tool where you keep leads and customers. We replace that with a signed message that updates the record. The build shows it with a Stripe test card, against a small records table.
Test cards the demo accepts (Stripe's published test numbers)
4242 4242 4242 4242Pays. The record changes.4000 0000 0000 0002Declined. No paid message, the record stays at Lead.4000 0000 0000 3220Extra bank check (3-D Secure), then pays.
CRM contacts (a small demo table on the demo server)
- Contact
- –
- Stage
- –
Checked Runs in Stripe test mode.
A Stripe test-mode checkout wired to a small records table: forged events are rejected, and a replayed delivery changes nothing.
- A test checkout starts. Stripe's own page takes the card, so card details go to Stripe and never touch this server.
- A Stripe test card pays, and the matching record moves to Paid once.
- Declined cards and cards that ask for an extra identity check are covered too. [3-D Secure]
The timeline arrives over a live event stream from this server, visible in the browser's network tab. [Server-Sent Events]
Safety
When the payment clears, Stripe sends a signed message. The server checks the signature on the exact bytes before it trusts a word of the message, then moves the matching record to Paid. A forged event is rejected, and a replayed delivery changes nothing.
Stripe retries failed deliveries and sometimes sends duplicates, so the server stores each event ID, and a repeat changes nothing. A copied or edited message fails the check. An edited body no longer matches its signature, and a copy older than five minutes is refused.
Before, someone reads an email and retypes it. A message sent twice can mean two entries, and a faked "paid" note can slip through. After, the record updates when the message arrives. The second copy changes nothing, and a forged note fails the check.
In the message-handling code, each message is saved before it is processed. A unique index on the source and event identifier applies a repeat once, and a failure is reported so the sender retries. A sender that retries can deliver the same message twice, so a repeat has to apply once. [unique index]
- paid message, signature validLead -> Paid, once
- same message delivered againignored (its event id is already stored)
- declined cardno paid message; stays at Lead
- forged event, signature invalidrefused; the record is untouched
Billing in a dashboard
Each tool has one job. Stripe Checkout is a hosted payment page. A message is accepted only with a valid signature, and a forged message is rejected. The CRM is the record that changes; here it is a small table, so every change shows. [Stripe Checkout, signed webhook]
The client dashboard's billing is built in Stripe test mode: Checkout, Payment Links, a customer portal and a message inbox that applies a repeat once. [Stripe Checkout, Payment Links]
That dashboard grew from an MIT-licensed open-source starter. We build a custom dashboard around your payment processor and the records you need to update, with the features on show.
See signed messages live now
Watch signed messages now on the live integration showpiece. The panel runs live: it accepts a correctly signed event, refuses a forged signature and ignores a repeated event identifier. Its personal receiving address lasts 30 minutes.
Browse the demo collection for more examples, or see integration work for connections to discuss.
Sandbox
n8n lead capture to CRM sandbox ("Leadflow")
A sandbox lead webhook cleans leads and scores them by fixed rules. It routes them hot, warm or cold in six visible steps and calls no outside service.
Tell us what you would change
Send two lines about your CRM and how you take payments. We answer with one small first step.