Split Payments & Refund Logic

Overview

The existing checkout system supported split payments across multiple tenders (e.g., credit card + cash), but refund flows were inconsistent, error-prone, and lacked clear validation guardrails.

Techs needed to process partial and full refunds quickly while ensuring financial accuracy across payment methods. The experience did not clearly communicate how refund amounts were distributed across tenders, creating confusion and risk.

The problem

Refund workflows for split payments introduced complexity:

• Limited visibility into original tender breakdown

• Confusion when refunding partial amounts

• Unclear rules for credit card–only refund scenarios

• Risk of refunding incorrect tender amounts

• Inconsistent confirmation states

• Lack of clear error messaging when refund limits were exceeded

My role

• Audited existing refund logic and edge cases

• Mapped tender state behavior across full and partial refunds

• Designed split payment breakdown visibility

• Structured validation and limit enforcement states

• Designed error handling for over-refund and invalid tender scenarios

Solution

• Displayed original payment breakdown before refund execution

• Enforced refund limits per tender method

• Designed conditional logic for credit-card-only refund scenarios

• Introduced validation messaging before confirmation

• Standardized confirmation and receipt generation

• Ensured consistency across full and partial refund flows

Results

• Standardized refund logic across split-payment scenarios

• Reduced process ambiguity in partial refund flows

• Implemented clear tender-level validation guardrails