Connector registration after Prism - Is static registration in hyperswitch here to stay?

[aykutaras]

Hello,

We are experimenting to self-host Hyperswitch (chart 0.2.26, router v1.126.0) right now. We are planning to integrate a number of acquirers we hold direct agreements with. None of them exist upstream. We checked all 150 names in common_enums::Connector and all 119 connectors in Prism.

So we have to add them ourselves, and we are trying to decide where to invest before writing any code. We would rather build in the direction the project is going than pick the path that is about to change.

Every new connector integration merged recently is UCS-only while the classic connector PRs in the same window are maintenance on existing connectors. So we assume new integration work goes to Prism.

But a UCS-only connector still requires substantial registration in hyperswitch. Citigate's PR was 1091 lines across 29 files, including:

• crates/common_enums/src/connector_enums.rs, crates/euclid/src/enums.rs
• all three crates/connector_configs/toml/{development,sandbox,production}.toml
• crates/hyperswitch_connectors/src/connectors/citigate.rs and citigate/transformers.rs
• default_implementations.rs / default_implementations_v2.rs

And Prism has a Connector enum of its own in the wire contract (crates/types-traits/grpc-api-types/proto/payment.proto), so a new connector is registered statically in both places.

For many connectors that means maintaining a hyperswitch fork indefinitely just for re-applying those registration points on every upgrade so the router will accept the names.

So our question is, in the Q3 2026 roadmap says the connector integrations layer "will be decoupled into a stateless, embeddable payment integration library with multi-language SDK support", which matches what Prism is. What we cannot tell from the outside is whether registration is also expected to change:

1. Is static registration in hyperswitch (Connector enum + connector_configs TOMLs + a connector scaffold) the intended long-term shape, or a transitional state while Prism matures?
2. Is there any plan for connectors that are known to Prism but not compiled into hyperswitch?
3. Is forking hyperswitch for the registration points the expected workflow today for self-hosters adding processors that will never be upstreamed (private acquirer agreements)?

We are not asking anyone to prioritise this. An answer of "static registration is here to stay" is genuinely useful, because it tells us to build the fork tooling now rather than wait.

[aykutaras]

anybody here?