Audit moved connector metadata fields in ConnectorSpecificConfig

[maverox]

Summary

As part of PR #627 (feat(domain): unify ConnectorSpecificAuth → ConnectorSpecificConfig), we moved several connector-scoped integration fields out of merchant_account_metadata and into typed ConnectorSpecificConfig variants.

This issue is to document and resolve the remaining audit questions around naming validity and parity:

• which moved fields are confirmed against current Hyperswitch connector metadata config
• which moved fields are implementation-valid but not yet confirmed from upstream metadata naming
• whether our typed config fields are expected to match upstream metadata naming exactly, PSP API naming exactly, or integration-facing naming where justified

PR reference:

• feat(domain): unify ConnectorSpecificAuth → ConnectorSpecificConfig #627

Fields moved into typed ConnectorSpecificConfig

• Braintree
  • merchant_account_id
  • merchant_config_currency
• Cybersource
  • disable_avs
  • disable_cvn
• Jpmorgan
  • company_name
  • product_name
  • merchant_purchase_description
  • statement_descriptor
• Worldpay
  • merchant_name
• Fiserv
  • terminal_id
• Worldpayvantiv
  • report_group
  • merchant_config_currency
• Paysafe
  • account_id as a typed nested structure

Confirmed against current Hyperswitch connector config metadata naming

Cross-checked against:
https://raw.githubusercontent.com/juspay/hyperswitch/main/crates/connector_configs/toml/development.toml

Confirmed matches:

• Braintree
  • merchant_account_id
  • merchant_config_currency
• Cybersource
  • disable_avs
  • disable_cvn
• Jpmorgan
  • company_name
  • product_name
• Worldpay
  • merchant_name
• Fiserv
  • terminal_id
• Worldpayvantiv
  • report_group
  • merchant_config_currency
• Paysafe
  • account_id hierarchy

Partially confirmed / needs explicit decision

Jpmorgan

• merchant_purchase_description
• statement_descriptor

These fields are present in our typed config and are actively consumed in the transformer flow, but they were not found as matching metadata keys in the current upstream development.toml.

So they are implementation-valid in our codebase, but not yet confirmed as upstream metadata-parity names.

Important caveat

Not every moved field is a literal PSP API field name.

Some of these are integration-facing config names that map into connector request behavior or internal selection logic:

• Cybersource.disable_avs / disable_cvn
• Worldpay.merchant_name
• Braintree.merchant_config_currency
• Worldpayvantiv.merchant_config_currency

This means the current shape is mostly aligned with Hyperswitch metadata naming, but not uniformly “exactly the same as the PSP API spec”.

Paysafe note

Paysafe was originally left as a JSON wrapper field, but was later corrected to a typed nested account_id structure.

That is the right direction because upstream metadata is also modeled under paysafe.metadata.account_id..., and the typed representation is now stronger and closer to the real config shape.

Out of scope for this issue

URL overrides were added in the same broad refactor window, but they are a separate concern from metadata absorption:

• base_url
• secondary_base_url
• third_base_url
• dispute_base_url
• base_url_bank_redirects

Those should be tracked separately if needed.

Follow-up actions

1. Confirm whether Jpmorgan.merchant_purchase_description and Jpmorgan.statement_descriptor should remain in typed connector config as-is, or be renamed/documented differently.
2. Decide whether we want strict upstream metadata naming parity, or whether integration-facing aliases like merchant_config_currency are acceptable.
3. Document connector-by-connector which typed fields are:
   • upstream metadata parity fields
   • connector API semantic fields
   • internal integration convenience fields

Acceptance criteria

• The moved field list is documented and agreed.
• The non-confirmed Jpmorgan fields are explicitly resolved.
• We have a clear policy on whether typed connector config fields must match:
  • upstream Hyperswitch metadata naming
  • PSP API field naming
  • or internal integration-facing naming where justified.