Event Notification — Preview
Connect Your Systems to Payment Events
Payment applications often need to know the moment something changes — not five minutes later, and not only when someone happens to check. The traditional way to get that is to poll: call an API on a schedule and compare the response to what you saw last time.
Polling works, but it has real costs. Every poll is an API request whether or not anything changed, which means wasted calls, added infrastructure load, and a detection delay bounded by however often you're willing to poll. Poll too rarely and your system lags behind reality; poll too often and you're generating traffic for no reason.
A payment webhook API takes a different approach: instead of your application asking "has anything changed?" on a loop, the platform tells your application when something has changed, by sending an event notification to an endpoint you control.
This is the core of event-driven architecture — your system responds to events as they're delivered, rather than continuously checking for them. It doesn't replace the API; you'll still use APIs to fetch full transaction detail, but webhooks tell you when to look, so you're not guessing.
For enterprise payment operations — settlement, reconciliation, merchant lifecycle management — that shift matters. It's the difference between systems that stay in sync automatically and systems that depend on someone or something remembering to check.
How Payment Webhooks Work
At a high level, a webhook notification moves through a consistent lifecycle from the moment an event occurs to the moment your application has processed it.
In practice: an event occurs on the platform; the platform generates and prepares the corresponding event notification; the notification is delivered over HTTPS to the endpoint you've configured; your receiving system validates the request; your application processes the event; and your application acknowledges receipt so the platform knows delivery succeeded.
A note on delivery behavior: This page describes the general shape of webhook delivery. Specific delivery timing, retry attempts, and acknowledgment requirements are defined in the technical documentation — confirm those details there before building delivery-dependent logic.
Payment Events
Payment-related events reflect the lifecycle of a transaction, from initiation through to a final state.
A note on event availability: The event names above describe common categories of payment activity. The exact set of event types exposed to your integration should be confirmed in the technical documentation, since availability can vary by product configuration.
Merchant Events
Merchant lifecycle events reflect changes to a merchant's onboarding status, profile, or configuration.
A note on event availability: As with payment events, confirm the specific merchant lifecycle events available to your integration in the technical documentation.
Settlement & Financial Events
Settlement-related notifications help connect payment operations with downstream finance and reconciliation systems.
Settlement Initiated
A settlement batch has been started.
Settlement Completed
A settlement batch has completed.
Settlement Failed
A settlement batch did not complete successfully.
Settlement Status Updated
A settlement batch's status has changed.
Reconciliation Completed
A reconciliation process against settlement or transaction data has completed.
Financial Adjustment
A financial adjustment has been recorded against a merchant or transaction.
Refund & Dispute Events
Post-transaction activity — refunds, chargebacks, and disputes — can also generate event notifications, so downstream systems learn about them without a manual check.
Refund
Notification that a refund has been initiated or completed against a transaction.
Chargeback
Notification that a chargeback has been raised against a transaction.
Dispute
Notification that a transaction has entered a disputed state.
Representment
Notification that a merchant response to a dispute has been submitted.
Dispute Resolution
Notification that a dispute has reached a final outcome.
Scope note: These are event notifications — they tell a system that a refund or dispute event occurred. They are not, by themselves, dispute-management functionality. Case handling, evidence submission, and dispute workflow tools are separate capabilities; confirm what's available as part of your platform configuration.
Webhook Delivery
How reliably and how quickly an event notification reaches your endpoint is one of the most important technical questions in a webhook integration.
A note on delivery guarantees: This page describes delivery behavior in general terms and does not claim exactly-once delivery. Because a notification can, in some circumstances, be delivered more than once, applications should be built to process events idempotently — see the section below.
Webhook Security
Because a webhook endpoint is a public-facing entry point into your systems, security is a first-class part of the design.
HTTPS
All webhook delivery takes place over encrypted HTTPS connections.
Endpoint Authentication
Your endpoint can be configured to verify that incoming requests genuinely originate from DigiPay.Guru.
Request Signing
Where supported, outbound requests can be signed so the receiving application can verify authenticity.
Signature Verification
Your application verifies the signature on an incoming request before trusting its contents.
Secret Management
Signing secrets and credentials are managed separately from application code.
Replay Protection
Applications should validate event freshness as part of processing, in line with the guidance in the technical documentation.
A note on security mechanisms: This page describes the general security model at a conceptual level. Specific mechanisms — signing algorithms, header formats, and IP allowlisting availability — are defined in the technical documentation. Implement against that documentation rather than assumptions made from this page.
Idempotent Event Processing
In any distributed system, a message can occasionally be delivered more than once. For enterprise payment systems, that makes idempotent processing a requirement, not an optimization: receiving the same event twice should never trigger the same business action twice.
Event IDs. Each event notification carries an identifier your application can use to recognize it. Idempotency. Designing your event handler so that processing the same event ID twice produces the same result as processing it once.
Duplicate detection. Comparing an incoming event's ID against previously processed events before taking action.
Event persistence. Recording that an event was received and processed, so later duplicates can be checked against that record. Processing status. Tracking whether a given event has been received, is being processed, or has completed.
Safe retry handling. Because delivery retries are possible, your event handler should be safe to invoke more than once for the same event.
Step 1
Webhook Received
Step 2
Validate Signature
Step 3
Check Event ID
Step 4
Duplicate → Ignore + New → Process
Step 5
Store Event Status
A note on delivery semantics: DigiPay.Guru does not claim exactly-once delivery for webhook events. Building idempotent event handling, as described above, is the recommended way to handle occasional duplicate delivery safely.
Event-Driven Payment Architecture
Webhooks complement the API layer — they don't replace it. Events tell your systems when something happened; the API remains how you retrieve full detail about it.
Event-Driven Enterprise Architecture
Payment webhook architecture connecting DigiPay.Guru payment events with enterprise applications through secure event notifications.
Webhooks vs. API Polling
Both approaches have a place; the right choice depends on how quickly your system needs to know about a change, and how much request volume you're willing to generate finding out.
| Capability | API Polling | Webhooks |
|---|---|---|
| Event detection | Periodic requests | Event-driven |
| Response timing | Depends on polling interval | Near real time, subject to delivery |
| API requests | Potentially high | Event-triggered |
| Infrastructure | Polling logic required | Webhook endpoint required |
| Event handling | Application checks status | Application reacts to event |
| Best use | On-demand retrieval | Event notification |
Integrate Webhooks with Enterprise Systems
Developer Workflow
Setting up a webhook integration follows a consistent path from account access to production monitoring.
Delivery log — every event, every attempt
Monitoring & Observability
Enterprise teams need to know not just that webhooks exist, but whether they're actually working.
A note on observability features: Exact monitoring and observability capabilities available to your account should be confirmed in the technical documentation or Developer Portal, as feature availability can vary.
Business Benefits
Reduce API Polling
Fewer unnecessary requests spent asking whether something has changed.
Improve Event Responsiveness
Systems react to events as they're delivered, instead of on a fixed polling schedule.
Simplify Integrations
Event-driven logic replaces custom polling and diffing code in application systems.
Automate Downstream Workflows
Settlement, reconciliation, and merchant updates can trigger automatically rather than manually.
Improve Operational Visibility
Delivery logs and event status give teams insight into whether integrations are healthy.
Build Event-Driven Applications
Webhooks support architectures where systems respond to change rather than continuously checking for it.
Scale Enterprise Integrations
Event-driven patterns tend to scale more predictably than polling as transaction volume grows.
Example Use Cases
Payment Status Synchronization
Keep an internal order or ledger system aligned with actual payment status.
Merchant Onboarding Synchronization
Reflect merchant approval and status changes in internal merchant records.
Settlement Notifications
Notify finance systems when a settlement batch completes.
Refund Notifications
Alert downstream systems when a refund is processed.
Reconciliation Workflows
Trigger reconciliation processes as relevant events arrive.
ERP Integration
Drive financial workflows in ERP systems from payment and settlement events.
E-Commerce Order Updates
Update order status as payment events are received.
Internal Transaction Processing
Trigger internal business logic tied to specific transaction events.
Why DigiPay.Guru Webhooks
API-First Architecture
Webhooks are built as a companion to the same APIs that power the platform, not a bolt-on notification layer.
Event-Driven Integration
Designed to help enterprise systems react to payment activity as it happens, rather than poll for it.
Configurable Event Notifications
Endpoints and event selection are configured to match what your integration actually needs.
Developer Experience
Webhooks are supported by the same sandbox, documentation, and Developer Portal used across the platform.
Frequently asked questions
Build Event-Driven Payment Integrations
Configure a webhook endpoint, select the events your systems need, and test delivery in the sandbox before going live.
Look through your eyes of insight to our insightful thoughts
DigiPay.Guru is born to simplify financial transactions. We love discussing the latest finTech solutions. We write regular blogs where we cover insightful topics with our insightful thoughts to cater you with imperative informations.
Let's Talk! Have Questions? We’re Here to Help....
Fill all your details in the form and one of our business consultant will get in touch you within 24 hours.
2019
Founded in
120+
In-house Tech experts
15+
Country served
100k+
Customers Achieved by our clients
10+
Paytech leader partnerships
8+
Fintech Platforms Introduced