Developer & Event Infrastructure | Real-time payment events for your platform

Webhooks built around what they receive.

Each webhook endpoint subscribes to the events that matter. Transaction events for payment execution. Checkout events for conversion monitoring. Batch events for matching. Each family has its own trigger catalog and its own payload configuration. One endpoint can cover all three, or a merchant splits them, the choice is theirs.

Every trigger. Grouped by what it covers.

Transaction, Checkout, and Batch triggers are organized by event family. A merchant selects the ones that match their operational needs, individual triggers, a full family, or everything at once. Each selection determines both what fires the delivery and what fields are available in the payload configurator. Nothing arrives that wasn't explicitly subscribed to.

Draft to Active. With a successful test in between.

Every webhook endpoint starts in Draft. Activation requires a successful test: NORBr sends a real request to the configured URL and validates the HTTP 2xx response. The endpoint goes live only when it proves it can receive. Once Active, it can be tested again at any time, without interrupting live deliveries.

Templates that give your merchants a head start.

As an operator, you define webhook templates at Program Manager level: pre-configured endpoint structures, trigger selections, payload fields. Your merchants inherit a working configuration from the moment they set up their first endpoint. They adjust what they need. They don't start from scratch.

Payment Events: every delivery, on record.

Every webhook delivery is logged. The trigger that fired, the merchant account, the result code, the timestamp. When a delivery fails, your merchants don't wait for the next event to bring the data. They resend from the table, one event or a batch, using the original payload, the original signature. The receiving system gets exactly what it missed.

Inspectable from the first attempt.

Each row in the Payment Events table is a delivery: what was sent, what came back, how many attempts were made. Click through to see the full payload and the full response. When an integration behaves unexpectedly, this is where your merchants find what actually happened, not what they assumed.

Resend without re-triggering.

A manual resend replays the original event to the configured endpoint. The payment logic behind it stays untouched. A refund that failed to notify a downstream system gets resent. The refund itself is not reprocessed. Exactly the right scope of action.

API keys: right access, right level.

API keys on your platform are scoped by design. Program Manager keys serve workspace-level integrations. Merchant Account keys serve payment operations for each merchant. Each level is managed separately. What your team controls and what your merchants access stays clearly separated, with permission-based visibility, rotation, and revocation at every step.

One Secret Key per Merchant Account.

Every Merchant Account has a Secret Key used to sign webhook deliveries. Your merchants verify incoming payloads against it, proof that the event genuinely came from NORBr. Same key, same signing logic, consistent across every endpoint they configure.

Security policies you define. Platform-wide.

As an operator, you set the rules: maximum key lifetime, rotation requirements, IP allowlisting for API access. Your merchants operate within the constraints you configured. The security posture of your platform reflects your standards, applied automatically to every merchant under your scope.

Every event reaches

every system.

Payment Events: every delivery, on record.

Every event. Every system. In sync.