fix: harden Paykit request handling

[ben-kaufman]

This PR hardens incoming Paykit contact-payment handling after QA on the cross-platform payment-request flow.

Description

1. Keeps one contact's malformed private receiver marker from blocking endpoint publication for otherwise valid contacts, while continuing to reject the malformed marker itself.
2. Validates incoming request amounts during initial invoice routing, so unaffordable requests show the standard insufficient Spending or Savings balance message instead of reaching coin selection with a generic error.

No Paykit SDK or binding change is required. Companion Android fix: synonymdev/bitkit-android#1172

Linked Issues/Tasks

• feat: add private payment requests bitkit-android#1172

Screenshot / Video

N/A — this corrects error handling in the existing payment-request flow.

QA Notes

Manual Tests

• 1. Saved contacts include one malformed remote Paykit marker → enable Contact Payments: valid contacts publish their private payment details and the malformed marker remains unusable.
• 2a. Incoming LN payment request exceeds Spending balance → open request: the insufficient Spending message appears instead of coin selection.
  • 2b. Incoming on-chain payment request exceeds Savings balance → open request: the insufficient Savings message appears instead of coin selection.

Automated Checks

• PrivatePaykitServiceTests: 15 tests passed on an iPhone 16 simulator.
• The Debug simulator test build, SwiftFormat lint, and git diff --check passed.

[greptile-apps]

Greptile Summary

This PR hardens incoming Paykit contact-payment handling by isolating malformed receiver markers and validating request amounts against the balance before entering the send flow.

• Allows valid contacts’ private endpoints to publish when another contact has a malformed receiver marker.
• Uses the incoming Paykit request amount for Lightning and on-chain preflight balance checks.
• Adds a changelog entry describing the corrected behavior.

Confidence Score: 5/5

The PR appears safe to merge, with the changed preflight checks aligned to the amount ultimately paid and malformed markers safely isolated from valid contacts.

Private Paykit endpoints are intentionally amountless, the incoming request amount is injected into payment execution and checked again during confirmation, and valid receiver paths continue through publication while malformed paths remain rejected and logged.

Important Files Changed

Filename	Overview
Bitkit/Services/PrivatePaykitService+Contacts.swift	Stops a malformed receiver marker from becoming the aggregate publication error while retaining logging and processing valid receiver paths.
Bitkit/ViewModels/AppViewModel.swift	Uses the incoming request amount for initial Lightning and on-chain affordability checks, matching the amount later injected into payment execution.
changelog.d/next/paykit-request-qa.fixed.md	Accurately documents the malformed-marker isolation and insufficient-balance handling fixes.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Incoming Paykit request] --> B[Resolve private amountless endpoint]
  B --> C[Decode Lightning, on-chain, or unified target]
  C --> D[Read amount from incoming request]
  D --> E{Preferred route has sufficient balance?}
  E -->|Yes| F[Open shared send flow]
  E -->|No, unified request| G{On-chain balance sufficient?}
  G -->|Yes| F
  G -->|No| H[Show insufficient balance message]
  E -->|No, single route| H
  F --> I[Inject request amount]
  I --> J[Confirm exact request amount]
  J --> K[Pay]

Loading

_{Reviews (1): Last reviewed commit: "fix: harden Paykit contact payments" | Re-trigger Greptile}