Split Tender Refund Business Rules

Overview

Split tender refunds enable merchants to process refunds for transactions that were originally paid using multiple payment methods. This document outlines the business rules and validation requirements governing split tender refund operations.

Scope

• API Endpoint: v2/refunds
• API Permission: merchant
• Refund Type: Linked Refunds
• Transaction Types: Card + Card, Card + ACH, ACH + ACH
• Supported Payment Methods: Cards and Bank Accounts

Out of Scope

• Refund Type: Unlinked Refunds/Credits

Refund Processing Flow

Refund Validation Rules

Error Codes

Icon	Error Type	Description	Impact
⚠️	INVALID_REQUEST	Request validation failure	Refund is rejected immediately
🚨	NOT_ACCEPTABLE	Business rule violation	Refund is accepted initially but fails during processing

MerchantTransactionId Validation

INVALID REQUEST

• Merchant Transaction ID must be unique across all refund requests
• System will reject duplicate transaction identifiers

---

Payment Validation

INVALID REQUEST

• PAYMENT IDENTIFIERS
  • Parent Transaction ID must exist in the system
  • Child Payment IDs must be associated with the parent transaction

---

• PAYMENT STATUS REQUIREMENTS
  • Parent Transaction status must be COMPLETED
  • Payments in pending, authorized, failed, or canceled status are ineligible for refunds

NOT ACCEPTABLE

• PAYMENT AGE LIMITS:
  • Refund requests must be within the allowed time window (180 days from transaction date)

---

Amount Validation

INVALID REQUEST

• FULL REFUND RULES
  • A full refund is processed when:
    • No amount is specified in the refund request
  • Full refunds apply to both individual payments in the original transaction

---

• PARTIAL REFUND RULES
  • When requesting an amount at parent level:
    • Individual payment ID and required amount must be specified
    • System will not automatically distribute refund amounts across payments
    • Merchants must explicitly indicate which payment receives the refund
  • If any one of the payment has already been refunded, refunds must be requested at the individual payment level

---

• REFUND AMOUNT CONSTRAINTS
  • Minimum amount: One cent per individual payment method
  • Maximum amount: Cannot exceed the original payment amount minus previously refunded amounts
  • Zero-amount refunds are not supported

---

• MULTIPLE REFUNDS
  • Multiple partial refunds are permitted up to the original transaction amount
  • Each payment can be refunded independently
  • Each refund request generates a unique refund identifier
  REFUND ALLOCATION EXAMPLE

  Original Transaction: $100 ($60 on Card, $40 on ACH)

  Scenario 1: Partial refund of $25 to Card

  • Merchant specifies the Card payment for refund
  • Remaining refundable amounts: $35 on Card, $40 on ACH

  Scenario 2: After first refund, additional $20 refund to ACH

  • Merchant specifies the ACH payment for refund
  • Remaining refundable amounts: $35 on Card, $20 on ACH

---

Previously Refunded Payments

NOT ACCEPTABLE

• FULLY REFUNDED PAYMENTS
  • When a refund is requested for an already fully refunded payment:
    • System initially accepts the request
    • Subsequent validation will fail with a conflict error
    • Merchant must verify refund status before submitting new requests
• PARTIALLY REFUNDED PAYMENTS
  • Additional refunds for partially refunded payments:
    • Must not exceed the remaining available balance
    • Will be validated against previous refund history
    • Will be rejected if amount exceeds available balance
• SPLIT TENDER REFUND SCENARIOS
  • When requesting full refund for a transaction where some payments are already refunded:
    • Full refund request will fail during processing
    • Merchants should submit individual refund requests for non-refunded payments only