Callback URL validation is financial-infrastructure security

What the public implementation shows

The gateway includes CallbackUrlValidator and options that require HTTPS and reject localhost or private-network targets by default.

Validation occurs when a subscription is created and again when the dispatcher is about to connect. This is the implementation fact behind the note; the architectural reading begins from that visible boundary rather than from an assumed production story.

Operating principleA callback destination is untrusted input even when the subscriber is a known institution.

The decision behind the mechanism

Revalidation accounts for DNS and configuration changes between registration and delivery.

A stored callback URL can target metadata services, local administration ports, or an address that later resolves into a private network. The mechanism matters because it gives that failure a named boundary, durable evidence, and a controlled response instead of leaving the outcome to timing or operator guesswork.

• Require HTTPS outside isolated development.
• Reject loopback, link-local, and private ranges.
• Resolve and validate every address before connection.
• Apply the same policy again at dispatch time.

How the control should be operated

Rejected targets, resolution results, policy version, and delivery-time rechecks should be observable without logging secrets.

Partner extensibility remains available without giving subscribers an uncontrolled network path from the gateway. The reusable lesson is not to copy a class or endpoint in isolation, but to preserve the relationship between identity, state, authority, evidence, and operational ownership.