Skip to main content
Ingo delivers real-time updates to your configured webhook endpoint as events occur — recipient engagement, identity screening, payment outcomes, and session activity. The connection is one-way: Ingo posts to you. Your endpoint acknowledges receipt with a 2xx response, and the event payload is the authoritative record for everything that follows. Every Ingo product fires webhooks. Event types, payload schemas, and correlation fields differ per product — the setup and verification requirements below apply to all of them.

​
Endpoint Requirements

Register a static HTTPS endpoint with your Ingo integration manager before onboarding. Ingo posts webhook payloads as JSON to that URL on every qualifying event.
If your endpoint does not return a 2xx response within the timeout window, Ingo will retry delivery. Design your handler to be idempotent — the same event may arrive more than once.

​
TLS Requirements

Your endpoint must support at least one cipher suite from the lists below. TLS 1.3 TLS 1.2

​
IP Allowlist

Add the following Ingo IP addresses to your allowlist so webhook traffic can reach your endpoint.

Sandbox

Production

​
Handling Events

Acknowledge first, process second. Return a 2xx response immediately, then process the payload asynchronously. Handlers that hold the connection open risk timeout retries and duplicate delivery. Design for idempotency. Ingo retries unacknowledged deliveries. Use the metadata.id in the payload to detect and discard duplicates before they affect your system state. The API response is the source of truth. Webhooks are an optional subscription layer for real-time status updates — they do not supersede the synchronous response. All transaction statuses, regardless of payment type, are always reflected in your daily SFTP reporting.

​
Testing During Development

Webhook endpoints are registered by your Ingo integration manager — there is no self-service portal to update the URL your program is configured to call. Before beginning sandbox development, confirm your endpoint URL with your integration manager so it can be registered as part of your program setup. If you need to receive webhooks on a local development machine, use a tunnel tool that provides a persistent, stable URL — a fixed subdomain or custom domain that does not change between sessions. Register that stable URL with your integration manager once. Ephemeral tunnels that generate a new URL on every restart require a configuration change with your integration manager each time, which is not practical for active development.
Contact your Ingo integration manager to update your registered webhook URL. Plan for this lead time when coordinating environment changes or moving from sandbox to production.

​
Webhook References

Event types, payload schemas, retry behavior, and signature details are documented per product.

IngoPay Webhooks

Transaction outcomes for verify, process, and debit calls across all payment types.

Notify — Classic Webhooks

Recipient engagement events from notification sent through funded.

Notify — Managed Parties Webhooks

Full party lifecycle events including approvals, role delegation, and multi-party flows.

Embedded Account Capture Webhooks

Session events for the hosted iFrame enrollment and payment selection experience.