💳 PaymentDetail Resource Advanced

Direct payment method management for specialized scenarios

PaymentDetail records store bank account information for receiving distributions and redemption proceeds. Most payment management occurs through BizEntity operations. Direct PaymentDetail endpoints support bulk imports, cross-entity updates, and payment validation.

4
Endpoints
1
Core DTO
Multiple
Payment Types
Secure
Storage

Usage Notes

When

  • Manage payment details independently of BizEntity for bulk imports
  • Query payment methods for distribution and redemption processing
  • Update bank accounts for existing entities

Requirements

  • Valid Bearer token with payment detail permissions

Notes

  • Payment details typically created via BizEntity operations; use direct endpoints for specialized scenarios
  • Each payment detail belongs to exactly ONE BizEntity (not Person or Organisation)
  • Required fields per validator: CurrencyID, PaymentTypeID, and AccountNumber. BSB is optional but format-validated when supplied (XXX-XXX with dash or XXXXXX without).
  • SWIFT and IBAN fields are accepted for international payment routing; format is not validator-enforced — supply correct values per your bank's requirements.

Available Endpoints

Core Operations

GET Get PaymentDetails Query payment details by entity or payment type
POST Create PaymentDetail Create payment detail with banking information
PUT Update PaymentDetail Update payment details and banking information
DELETE Delete PaymentDetail Remove with transaction validation

Core Data Transfer Objects

PaymentDetailDTO All PaymentDetail endpoints Payment method structure (26 properties) with Australian banking (BSB, account number), international payments (SWIFT, IBAN, intermediary bank details), transaction routing flags (deposit, distribution, redemption), and entity ownership via dual IDs 
public class PaymentDetailDTO
{
    public int? PaymentDetailID { get; set; }
    public string? ExternalPaymentDetailId { get; set; }
    public int PaymentTypeID { get; set; }
    public int? BizEntityID { get; set; }
    public string? ExternalBizEntityId { get; set; }
    public string? BSB { get; set; }
    public string? AccountNumber { get; set; }
    public string? AccountName { get; set; }
    public string? Address { get; set; }
    public string? Comments { get; set; }
    public int? CurrencyID { get; set; }
    public string? IBAN { get; set; }
    public string? IntermediaryBankAccountName { get; set; }
    public string? IntermediaryBankAccountNumber { get; set; }
    public string? IntermediaryBankAddress { get; set; }
    public string? IntermediaryBankName { get; set; }
    public string? IntermediaryBankSWIFT { get; set; }
    public bool IsForDeposit { get; set; }
    public bool IsForDistribution { get; set; }
    public bool IsForOther { get; set; }
    public bool IsForRedemption { get; set; }
    public bool IsDefault { get; set; }
    public string? Message { get; set; }
    public string? PersonalName { get; set; }
    public string? Reference { get; set; }
    public string? SWIFT { get; set; }
}

Use Cases & Scenarios

Most payment management occurs through BizEntity operations. Use direct PaymentDetail endpoints for bulk payment imports, cross-entity banking updates, or financial system migration scenarios.

→ See BizEntity Overview for standard entity operations

Business Rules & Constraints

BizEntity Integration & Data Integrity

  • Exclusive ownership: PaymentDetail records belong to BizEntity for centralized payment method management
  • Payment prioritization: Primary/default payment method designation for automated processing workflows
  • Transaction integration: Integration with deposit, redemption, and distribution payment processing
  • BizEntity context: Payment method creation and management primarily occur through BizEntity operations for relationship integrity

Payment Information & Validation

  • Secure storage: Payment information stored securely within the platform infrastructure.
  • BSB format: Australian BSB is optional. When supplied, the validator accepts XXX-XXX (with dash) or XXXXXX (six digits, no dash).
  • International support: SWIFT and IBAN fields are accepted for international payment routing. Format is not enforced by the validator at the time of writing.
  • Payment type validation: PaymentTypeID must be greater than 0 and reference a valid payment type lookup. Required.
  • Currency: CurrencyID must be greater than 0. Required.
  • Account number: AccountNumber is required (NotEmpty).

Referential Integrity & Management

  • Referential integrity: Cannot delete payment methods if referenced by active transaction workflows
  • Dual ID system: Native IDs for performance, External IDs for third-party system integration
  • External integration: ExternalPaymentDetailId supports third-party system integration and idempotency