feat(connector): [payload] add support to split payments

[AkshayaFoiger]

Type of Change

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

Description

Blocked on payload

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/hyperswitch_connectors/src/connectors/payload/requests.rs	25% smaller
crates/hyperswitch_connectors/src/connectors/stripe/transformers.rs	22% smaller
crates/hyperswitch_connectors/src/connectors/payload/transformers.rs	1% smaller
crates/common_types/src/payments.rs	0% smaller
crates/router/src/core/payments/helpers.rs	0% smaller
crates/router/src/core/unified_connector_service/transformers.rs	0% smaller

[XyneSpaces]

test

[XyneSpaces]

test

[XyneSpaces]

⚠️ Missing Secret<T> wrapper for sensitive receiver_id

In PayloadLedgerItem, the receiver_id field holds a processing identifier that could be sensitive. Consider wrapping it in Secret<String>:

pub struct PayloadLedgerItem {
    pub amount: MinorUnit,
    pub receiver_id: String,  // <-- Should this be Secret<String>?
}

Fix: If receiver_id is a credential/token that shouldn't appear in logs, change to pub receiver_id: Secret<String>.

[XyneSpaces]

🚨 Potential correctness issue in response type mapping

The ConnectorChargeResponseData::PayloadSplitPayment variant stores PayloadSplitPaymentRequest (the request type) in the response data. This is semantically incorrect - responses should use a dedicated response type, not the request type.

// Line ~460 in common_types/src/payments.rs
pub enum ConnectorChargeResponseData {
    // ... other variants
    #[smithy(value_type = "PayloadSplitPaymentRequest")]  // <-- Request type in response enum
    PayloadSplitPayment(PayloadSplitPaymentRequest),
}

Fix: Define a PayloadChargeResponseData struct that captures the actual response fields from Payload's API (transaction IDs, processing status, ledger confirmation, etc.), or rename if this is intentional pass-through behavior and add a clarifying comment.

[XyneSpaces]

📝 Review Summary

Found 1 issue requiring attention:

[should-fix] Split payments validation allows positive amounts

In crates/router/src/core/payments/helpers.rs around line 9120+, the validation for PayloadSplitPayment checks:

if split_item.amount.get_amount_as_i64() > 0 {
    return Err(errors::ApiErrorResponse::InvalidDataValue {
        field_name: "split_payments.payload_split_payment.ledger.amount",
    });
}

Issue: The validation only rejects positive amounts, but the comment says "negative = debit from the payment". However, a zero amount would pass validation, which doesn't make sense for a split payment ledger entry.

Suggestion: Consider validating amount != 0 or clarify if zero amounts are semantically valid for this use case.

---

This is an automated review. Please verify the findings before making changes.

[XyneSpaces]

[should-fix] In payments.rs (common_types), the new PayloadSplitPaymentRequest struct and related types are well-documented with docstrings. However, there's a potential validation gap.

The PayloadLedgerItem has an amount field as MinorUnit with a comment "Signed amount in minor units (negative = debit from the payment)".

In helpers.rs, validation checks that amount > 0 returns an error, but negative amounts are allowed. Please confirm this is intentional - typically split payments should have specific validation for:

1. Sum of all ledger amounts equals the total payment amount
2. No single receiver gets more than the total payment
3. At least one negative entry (the debit) exists

Without these validations, malformed requests could cause reconciliation issues.

[XyneSpaces]

⚠️ Ledger amount validation logic

In the validation for PayloadSplitPaymentRequest, the PR adds a check that ledger amounts must be ≤ 0. Please verify this is the correct direction for the constraint:

// From diff: validation in helpers.rs
if item.amount > 0 {  // This check implies amounts must be <= 0
    return Err(...);
}

Question: If this represents money being transferred out (debit), negative or zero makes sense. But if this represents received funds (credit), the constraint may be inverted. Confirm the sign convention matches Payload's API specification.

Also ensure receiver_id non-empty check handles the case where the connector might accept null/empty for certain split types (e.g., marketplace fees vs. direct splits).