Payment webhook

A signed callback from the processor records the payment even if the customer closed the tab or the payment cleared hours later.

What it is

A public endpoint that verifies the payload's signature before trusting anything in it, then records the payment against the invoice named in the session metadata. It handles both immediate checkout completion and asynchronous methods that settle later.

Also called: stripe webhook · async payments · bank payment cleared · customer closed the tab

See it
Payment webhook
Area
Integrations
Group
Payments
System
Payments
Solves
2 named problems
01The raw request body is used for HMAC verification — it is never parsed as JSON first.
02The signing secret can come from the environment or from a per-business setting; every candidate is tried until one verifies.
03Verification, event interpretation and refund/dispute logging live in the payments adapter; the route only maps the verdict to HTTP.
Diagram rather than screenshot: customer → hosted checkout → signed webhook → invoice_payments → invoice marked paid, with the return-trip path drawn as the parallel primary route. Sample data — no customer information appears here.
How it works
  1. 1The raw request body is used for HMAC verification — it is never parsed as JSON first.
  2. 2The signing secret can come from the environment or from a per-business setting; every candidate is tried until one verifies.
  3. 3Verification, event interpretation and refund/dispute logging live in the payments adapter; the route only maps the verdict to HTTP.
  4. 4A transient database failure returns 500 so the processor retries; a session with no usable metadata returns 200 because a retry cannot fix it.
Why we built it

A customer who pays and closes the tab, or a bank debit that clears three days later, never makes the return trip that confirms a payment. The payment processor sends its own notification for those, and it settles the invoice whether or not anyone is looking. It is verified against the processor's signature on the untouched message, because an endpoint that marks invoices paid on request is an endpoint anybody can use.

The problem
  • Payments lost because the customer never returned to the invoice page.
  • Asynchronous payment methods settling after the browser session ended.
Sound familiar?
What you get
Payment is recorded regardless of what the customer's browser did.
Forged payment notifications are rejected.

See it on your own jobs

Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.

or keep browsing features →