MDH GROUP · BLOG

On-Prem Payment Webhooks: Real-time Synchronization of Incoming Payments with Internal Systems

An invoice is overdue, reminders are sent, then the payment arrives — but it lands in a clerk's email inbox and is only assigned days later. In many small and medium B2B companies this causes duplicate work, delayed liquidity visibility and manual corrections in ERP or cash dashboards.

← All posts

On-Prem Payment Webhooks: Real-time Synchronization of Incoming Payments with Internal Systems

When the invoice is paid — and nobody notices in time

An invoice is overdue, reminders are sent, then the payment arrives — but it lands in a clerk's email inbox and is only assigned days later. In many small and medium B2B companies this leads to duplicated work, delayed visibility of liquidity and manual corrections in ERP or cash dashboards. Managing open items means recognizing, matching and documenting payments quickly — ideally automatically and in real time.

What webhooks deliver for incoming payments

Webhooks are simple, event-driven HTTP notifications: as soon as a payment arrives in your accounts receivable system, a package with details about the payment is sent to a configured receiving address (endpoint). For on-prem environments this means: your internal systems — ERP, cash tools, BI dashboards — receive the information immediately and can automatically reconcile accounts, create partial payment entries or trigger notifications in the finance team.

Concrete benefits

  • Immediate synchronization: no more manual reconciliations between banking, accounting and accounts receivable systems.
  • Reduced administrative effort: fewer posting errors and faster approvals of incoming payments.

How Debentra uses webhooks in on-prem setups

Debentra is a self-hosted solution for accounts receivable and claims management that supports webhooks as part of its standard workflow: take over invoice → detect open items → follow-up → detect incoming payment → document. For incoming payments Debentra generates a webhook event that you can send to an endpoint you operate. This keeps full data ownership with you — both the payment data and the infrastructure that processes it.

Typical integration scenarios

  • ERP: automatic account reconciliation and closing of open items.
  • Cash management tools: updating liquidity forecasts in real time.
  • Dashboards/BI: live visualization of incoming payments and aging analyses.

Security principles for on-prem webhooks

On-prem means your endpoint is located within your network — often behind firewalls, in a DMZ or reachable via VPN/reverse proxy. The following measures are proven in practice to operate webhook integrations securely and reliably:

1. Authentication and integrity verification

  • HMAC signatures: Debentra signs every webhook payload with a secret key. Your endpoint verifies the signature before processing so that only legitimate events are accepted.
  • Timestamps and nonces: a short time window and one-time nonces protect against replay attacks.

2. TLS and network segmentation

  • TLS: Endpoint URLs must use HTTPS. The recommended minimum version is TLS 1.2 or higher.
  • Network segmentation: Webhooks should land in a clearly delineated network zone (e.g., DMZ or a dedicated application subnet), with restricted access only to the systems that need the data.

3. Access protection and firewall rules

  • IP allowlist: If possible, restrict incoming connections to Debentra hosts or IP ranges of your operations.
  • Reverse proxy & WAF: A reverse proxy with rate limiting and a Web Application Firewall helps to fend off unwanted traffic.

4. Queueing, retries and idempotence

Network disruptions happen. Debentra supports retries when an endpoint is temporarily unavailable. On your side, the processing code should be idempotent — that is, identical events may arrive multiple times without causing duplicate bookings. A simple idempotency key logic prevents duplicate entries.

5. Monitoring and audit logs

  • Logging: Every received message, its signature verification and processing results should be logged in an auditable way.
  • Alerting: In case of repeated failures or unusual payloads, automated alerts should be sent to the operations team.

Network configuration: examples for on‑prem architectures

Depending on security requirements, the recommendations differ:

Variant A — Direct, protected endpoint (simple)

  • Endpoint in a secured subnet, HTTPS with HMAC signature verification.
  • Firewall allows only connections from known Debentra IPs.
  • Pro: simple setup; Con: dependency on IP allowlist.

Variant B — Reverse proxy in DMZ (recommended for production environments)

  • Reverse proxy in the DMZ handles TLS and WAF controls, forwarding verified requests to the internal service.
  • Internal service processes events in a private subnet and communicates with ERP/cash tools via an internal API.
  • Pro: better control, smaller direct attack surface.

Variant C — VPN/private peering (highest isolation)

  • Webhook delivery takes place over a VPN or private peering between the Debentra host and your network.
  • Pro: maximum isolation; Con: increased operational effort.

Practical implementation steps (checklist)

  • Define endpoint: Create an API route that can receive webhook payloads.
  • Choose a security concept: Exchange an HMAC key, configure TLS, implement IP filtering.
  • Implement idempotency: Use event IDs or idempotency keys.
  • Retry strategy: Exponential backoff and a dead‑letter queue for failed events.
  • Monitoring: Configure log levels, audit logs and alerts.
  • End‑to‑end test: Trigger a payment, receive the webhook, verify the ERP entry.

Typical mistakes and how to avoid them

  • Missing signature verification: Allows arbitrary events — always verify HMAC.
  • No idempotency: Duplicate events lead to double bookings — implement ID checks.
  • Blocking processing: Long synchronous processes in the endpoint block retries — make processing asynchronous.
  • Incomplete monitoring: Failures go unnoticed — define alerts.

Control remains with the user

Important: Automation does not replace control. Debentra sends the event; your internal rules decide whether a payment is posted automatically in the financial software or whether an employee must approve the allocation. Especially for partial payments or installment plans, a manual approval level is recommended. This way you retain authority over bookings while repetitive tasks are reliably automated.

Conclusion: Real‑time insights without data sharing

On‑Prem webhooks provide the benefit of true real‑time synchronization of incoming payments into your ERP and cash tools without customer data flowing to external services. Debentra delivers the webhook events as part of the self‑hosted stack: you operate the receiving and processing infrastructure, configure security and network connections according to your requirements, and retain control over approvals and documentation.

If you manage open items and want to improve your liquidity overview, a well secured webhook workflow is an effective lever: less manual allocation, faster reporting, centralized tracking.

Recommended action: Test the webhook integration in an isolated environment, verify HMAC signatures and idempotency, and then roll it out gradually into production. More information and the editions overview can be found at https://debentra.de — choose an edition and configure On‑Prem webhooks.

Next step

Try Debentra yourself

Central overview and process control for open items and payments with complete data sovereignty; reduces manual allocation work (PRO) and enables integrated accounting (PREMIUM); selectable installation and licensing models.

Choose edition