fix(recovery): Populate connector request reference id in revenue recovery record attempt flow.

[srujanchikke]

Type of Change

• Bugfix
• New feature
• Enhancement
• Refactoring
• Dependency updates
• Documentation
• CI/CD

Description

Previously there was no restriction in confirmData to connector request reference id to be mandatory. Recovery internally uses proxy flow, which internally uses confirmData where connector request reference id was hardcoded to none. This Pr adds supports to generate connector request reference to merchant reference id.

This Pr also has changes of adding support for jwt auth to payment get for dashboard use case. Previously payment sync was used in dashboard to retrieve payment details, but this would fail now in v2 because if there are no attempts created payment get would return 4xx since active attempt is mandotory. To solve this now dashboard is relying on payment get and payment get attempt list api's .

Additional Changes

• This PR modifies the API contract
• This PR modifies the database schema
• This PR modifies application configuration/environment variables

Motivation and Context

How did you test it?

Test case 1 :
step 1 : create a profile in hyperswitch and wait for 8 mins to move it from monitering to cascading , this would only get updated when webhooks are triggered .
step 2 : create payment mca

curl --location 'http://localhost:8080/v2/connector-accounts' \
--header 'Content-Type: application/json' \
--header 'Accept: application/json' \
--header 'x-merchant-id: test_seller_AGZCJiHwUNV1seyoepOE' \
--header 'x-profile-id: pro_kYmv4lQjIZFbAqoOVY4M' \
--header 'Authorization: admin-api-key=test_admin' \
--data '{
  "connector_type": "payment_processor",
  "connector_name": "stripe",
  "connector_account_details": {
        "auth_type": "HeaderKey",
        "api_key": "stripe-api-key"
    },
  "profile_id": "pro_kYmv4lQjIZFbAqoOVY4M"
}'

**step 4 : ** configure stripe billing connector.

curl --location 'http://localhost:8080/v2/connector-accounts' \
--header 'Content-Type: application/json' \
--header 'Accept: application/json' \
--header 'x-merchant-id: test_seller_AGZCJiHwUNV1seyoepOE' \
--header 'x-profile-id: pro_kYmv4lQjIZFbAqoOVY4M' \
--header 'Authorization: admin-api-key=test_admin' \
--data '{
    "connector_type": "billing_processor",
    "connector_name": "stripebilling",
    "connector_account_details": {
        "auth_type": "HeaderKey",
        "api_key": "{{stripe-api-key}}"
    },
    "connector_webhook_details": {
        "merchant_secret": "{{stripe-webhook-key}}",
        "additional_secret": "password"
    },
    "feature_metadata": {
        "revenue_recovery": {
            "max_retry_count": 7,
            "billing_connector_retry_threshold": 2,
            "billing_account_reference": {
                "{{payment_connector_mca_created_in_last_step}}": "stripebilling"
            }
        }
    },
    "profile_id": "pro_kYmv4lQjIZFbAqoOVY4M"
}'

step 5 : Trigger failed invoice from stripe billing by creating new subscription and move the test clock to 1 week.
This would trigger few external payments. once it exhausts retry threshold it will create process tracker entry. Follwed by 2 mins it would create all retries by hyperswitch as shown below.

Checklist

• I formatted the code cargo +nightly fmt --all
• I addressed lints thrown by cargo clippy
• I reviewed the submitted code
• I added unit tests for my changes where possible

[semanticdiff-com]

Review changes with  

Changed Files

File	Status
crates/router/src/core/payments/operations/proxy_payments_intent.rs	1% smaller
crates/hyperswitch_domain_models/src/payments/payment_attempt.rs	0% smaller
crates/router/src/core/payments.rs	0% smaller
crates/router/src/routes/payments.rs	0% smaller
crates/router/src/services/authentication.rs	0% smaller

[hrithikesh026]

nit: "api-key=" can be a const.

[tsdk02]

Are you giving the highest priority to api-key?
What if both JWT and api-key headers are present in the request body? Which authentication type should be considered in that case?

Or is it the same header used for all authentications in v2?

[hrithikesh026]

This can never happen right.
Value for Authorization header cannot start with Both Bearer_ and api-key=

[tsdk02]

Got it, so unlike v1, where there are different headers for different authentication types, in v2 there is just one Authorization header with different values for different types of authentication, correct?