From a signature to steady supportFrom a signature to steady support

Why it works this way

• One petition = one landing page. The ad leads straight to the petition.
• Campaign links are built in the admin panel only from registered UTM keys.
• A gclid doesn't reveal which account the click came from, so conversions are routed to the Grants or the paid account by campaign tags — each account has its own actions: SIGNATURE, DONATION, UPSELL.
• For Grants the report shows cost per signature in credit, not ROAS.

Why it works this way

• A server form: POST → 303 → GET. Script only adds comfort — some paid mobile traffic has JavaScript blocked.
• Calm errors: nothing shouts while typing. After submitting — a summary linking to the fields; an error vanishes the moment the field is valid.
• The button instantly says “Sending…”.
• The same validation in the browser and on the server, on zod/mini.

Why it works this way

• No menu or footer: a funnel step has counted exits, and the only one is “Back”.
• Under the heading, the same progress bar with a green “+1” — the counter already includes your signature.
• We ask for e-mail consent only if it wasn't given when signing — checked in the database, not in a cookie.
• The donation card in ATTENTIO orange has dark text (5.56:1); white would give only 3.16:1.
• Six amounts (200 · 150 · 100 · 70 · 55 · 35 zł) — each tile opens the form with that amount and the monthly cycle preselected.

Why it works this way

• 11 amounts plus “Other” make two full rows of six. 800 instead of 700, because 700 would sit right above 70 zł.
• 100 zł is preselected and “Recommended” sits inside the label, so screen readers announce it. On mobile six amounts first, the rest behind “Show more”.
• “Monthly” is the default, but “One-time” sits next to it at the same size.
• The button always says what will happen: “I'm giving 100 zł monthly” — even without JavaScript, thanks to CSS :has().
• Details of someone who just signed are prefilled — from an encrypted cookie, never the URL. Consent isn't asked twice if it was given when signing.

Why it works this way

• Row first, money second: the donation (and subscription) exists in the database before the first call to the operator.
• Idempotency: a deterministic key from session, amount and channel, sent as the Idempotency-Key. A 5-minute window tells a double click from a new, deliberate donation.
• A webhook without an SDK: HMAC-SHA256 signature checked by hand, 300 s tolerance, constant-time comparison. An inbox keyed by event ID — a duplicate is skipped only if the original succeeded.
• The operator's amount must equal the reserved amount, otherwise the event is rejected and retried.
• The list of ten handled events is read from the route's code and frozen by a test — an event that's handled but not enabled at the operator simply never arrives.

Why it works this way

• Before every step the system excludes people who already donated, have a monthly gift (active, pending or paused), lack consent, or got an ask in the last 24 hours.
• Copy rules: one message = one action = one button.
• +1 h: “the most effective moment of the cadence: the person still remembers why they came”. SMS only 9:00–20:00, e-mails 6:00–22:00.
• The last message really is the last. Unsubscribing is one click, no questions, with List-Unsubscribe One-Click (RFC 8058).

Why it works this way

• Day 21 after a booked gift: “earlier is too early (…the ask sounds ungrateful), later the gift is no longer remembered”.
• Anyone with a monthly gift — paused included — and anyone without e-mail consent is skipped.
• The link opens the form with the monthly cycle, and the resulting conversion goes back to the campaign that brought the first gift.
• A monthly gift reaches ad platforms as a separate event valued at 12 × the monthly amount — a recurring donor is a commitment, not one payment. They also drop out of acquisition campaigns.

Why it works this way

• The MCP server never charges a card: it returns the donation page with the amount filled in. A chat window has no payment instrument, so a charge needs a credential only a person brings.
• The tool accepts no personal data — the person types their e-mail on the page.
• If the database is down the tool still returns the URL: losing the row loses attribution, losing the URL loses the donation.
• A plain GET to the server returns a readable description instead of a 405 — an assistant that looks with a browser won't give up.