fix(hooks): normalizePayment handles Soroban and account_merge payments

[Nathanpvd]

Overview

This PR fixes normalizePayment so it stops fabricating blank 0 XLM rows for Soroban transfers and account merges. invoke_host_function records are now parsed from Horizon's asset_balance_changes, producing one normalized row per asset balance change that involves the queried address. account_merge now uses the real merged amount from the operation effects instead of hardcoding "0". The silent fall-through is replaced with an explicit throw, so no unrecognized payment record can ever be returned as an empty zero-amount row again.

Related Issue

Closes #[issue number]

Changes

🔧 Payment Normalization Fix

• [MODIFY] packages/core/src/hooks/usePayments.ts

  • Added an explicit invoke_host_function branch that extracts entries from asset_balance_changes; each change involving the queried address is emitted as a NormalizedPayment row with real from, to, amount, and asset.
  • Reworked account_merge so the hook fetches the operation's effects and passes the account_credited / account_debited amount into normalizePayment, replacing the hardcoded "0".
  • Replaced the fall-through if chain with an else that throws on any unsupported PaymentRecord type, making the old fabricated blank row unreachable.

• [MODIFY] packages/core/src/hooks/usePayments.test.tsx

  • Added fixture-based tests for all six members of the PaymentRecord union.
  • Added assertions that Soroban transfers contain non-empty from/to, non-zero amount, and the correct asset; that account_merge returns the real merged amount; and that unsupported types throw instead of returning zeroed rows.

• [ADD] packages/core/src/__tests__/fixtures/horizon-payments.ts

  • Committed real testnet Horizon /payments responses for payment, create_account, account_merge, path_payment_strict_receive, path_payment_strict_send, and invoke_host_function.
  • Included the corresponding account_merge effects fixture so the test verifies the real merged amount.
  • All addresses and assets are testnet only.

• [MODIFY] CHANGELOG.md

  • Documented the normalization fix and the new throw-on-unsupported behavior.

Verification Results

pnpm test
✅ 6/6 fixture-based payment normalization tests passed

pnpm lint
✅ no lint errors

pnpm typecheck
✅ no type errors

pnpm build
✅ build completed successfully

Manual acceptance check:
✅ invoke_host_function rows show real from/to/amount/asset
✅ account_merge amount is the actual merged balance from effects
✅ Unsupported records throw instead of rendering 0 XLM rows

Acceptance Criteria	Status
invoke_host_function records produce real from / to / amount / asset	✅ One row per asset_balance_changes entry involving the queried address
account_merge reports the actual merged amount, or an explicitly documented null	✅ Actual amount is read from operation effects; no fabricated "0"
No code path returns a fabricated zero-amount row	✅ Fall-through else throws on unsupported types
Unhandled record types are discriminated or filtered, never silently zeroed	✅ Unsupported PaymentRecord types now throw instead of returning initialized rows
A fixture-based test for each of the six members of the PaymentRecord union	✅ 6 tests using horizon-payments.ts fixtures
Fixtures are real recorded Horizon responses, committed under src/__tests__/fixtures/	✅ All fixtures are real testnet /payments responses
Type changes reflected in docs/reference/types.md and CHANGELOG.md	✅ No NormalizedPayment type changes needed; CHANGELOG.md documents the fix
pnpm test, pnpm lint, pnpm typecheck, and pnpm build all pass locally	✅ Verified locally
No file outside "Where this lives" is touched	✅ Only files listed in the PR are modified
Every example and test uses testnet only — no mainnet addresses	✅ All fixture addresses/assets are testnet
PR description includes Closes #[issue number]	✅ See Related Issue

Closes #226

[drips-wave]

@Nathanpvd Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits