feat(events): add audit event for payment incremental authorization

[errmakov]

Type of Change

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

Description

Adds an audit event for the incremental authorization operation (POST /payments/{payment_id}/incremental_authorization). Most other payment operations already emit one (create, confirm, update, capture, cancel, approve, reject, status, complete authorize, recurrence).

• crates/router/src/events/audit_events.rs: new variant

  PaymentIncrementalAuthorization {
      authorization_id: Option<String>,
      additional_amount: MinorUnit,
      total_amount: MinorUnit,
      reason: Option<String>,
  }

  with identifier payment_incremental_authorization.

• crates/router/src/core/payments/operations/payments_incremental_authorization.rs: update_trackers now uses req_state and emits the event with payment_data.to_event() (payment intent and attempt). It fires after the authorization record is inserted and authorization_count is updated, so authorization_id is always set. Capture (feat(events): Add payment cancel events #4166) and cancel emit at the same point.

The existing match that writes authorization_id back into incremental_authorization_details is now a let binding, so the event and payment_data use the same value. The error path for missing details is unchanged.

Emitted payload (synthetic values):

{
  "event_type": "PaymentIncrementalAuthorization",
  "authorization_id": "auth_XXXXXXXXXXXXXXXXXXXX_1",
  "additional_amount": 500,
  "total_amount": 1500,
  "reason": "customer added items",
  "created_at": "2026-09-17T12:00:00.000Z"
}

Not in this PR: the issue also mentions error codes and rejection metadata. Those only exist after the connector responds, in PostUpdateTracker (payment_response.rs), and that has no ReqState or event context. The same is true of the capture and cancel audit events, which also record the request, not the connector outcome. Glad to follow up if you'd like the outcome recorded too.

Additional Changes

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

Motivation and Context

Closes #4676. The issue was created from #4525 and asks for an audit event for this operation, similar to PaymentCancel (#4166).

How did you test it?

• cargo clippy -p router --all-targets --features release completes with no warnings. The only warnings are vergen build-script notices about git metadata in a worktree.
• rustfmt +nightly --check passes on both files.
• The module is #[cfg(feature = "v1")]. The new variant only uses types audit_events.rs already imports, so the v2 build is unaffected.
• Two unit tests in audit_events.rs, covering the new event's identifier and its serialized payload:

running 2 tests
test events::audit_events::tests::incremental_authorization_identifier_uses_event_name_and_timestamp ... ok
test events::audit_events::tests::incremental_authorization_serializes_tagged_fields ... ok

test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 71 filtered out

(cargo test -p router --lib --features release audit_events)

• Not run against a live connector or a Kafka sink. Emission from update_trackers needs a full SessionState, so it is covered by the type checker and review only.

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

🤖 Generated with Claude Code

[semanticdiff-com]

Review changes with  

Changed Files

File	Status
crates/router/src/core/payments/operations/payments_incremental_authorization.rs	46% smaller
crates/router/src/events/audit_events.rs	0% smaller