Playbook
Underpayment and overpayment handling
Tolerance policies, exception classes, customer resolution paths, and finance posting boundaries.
01
Objective
Resolve amount mismatches with explicit tolerance policy—routing to exception queues instead of silent acceptance or rejection.
02
Prerequisites
- Amount tolerances defined per asset and rail.
- Customer communication policy for partial payments.
- Finance rules for posting under/over amounts.
03
Operational signals
- Matcher failures on amount dimension only.
- Support tickets about partial wallet sends.
- Treasury holds on aggregate micro-differences.
04
Decision points
- Auto-accept within tolerance versus always review.
- Recreate payment versus manual allocation.
- Refund excess or credit merchant balance.
05
Escalation paths
- Support → treasury for material overpayment.
- Finance → policy owner for tolerance changes.
06
Failure modes
- Accepting any positive amount without reference check.
- Writing off differences without resolution metadata.
07
Recovery patterns
- Classify as amount mismatch exception.
- Document observed vs expected with rail context.
- Execute customer resolution per playbook policy.
- Retries are normal. Webhook delivery is at-least-once. Design consumers to tolerate duplicates and out-of-order arrivals where possible.
- Asynchronous by design. Payers, chains, and your servers operate on different clocks. UI and finance should not assume synchronous finality.
- Eventual consistency. API reads, webhooks, and portal views may briefly diverge during transitions. Reconciliation jobs exist to converge truth.
Walkthroughs: /operations