feat: send paykit payment proofs

[ben-kaufman]

This PR sends a Paykit payment proof back to the requester after Bitkit successfully pays an incoming private payment request.

Description

1. Persists the payer identity, request, and selected endpoint before request acceptance, then associates the Lightning payment hash before sending so restart recovery keeps the correct correlation.
2. Persists successful on-chain transaction IDs and validated Lightning preimages before submitting them against the original one-time request and exact endpoint.
3. Uses Paykit's durable private outbox, retries incomplete submissions during normal request refresh, and suppresses duplicate proofs already recorded by the SDK.
4. Preserves earlier in-flight correlations across retries, clears the request after one proof is queued, and reads the secure store directly so wallet wipes cannot resurrect cached proof state.
5. Attempts immediate SDK delivery if persisting a completed proof fails, without adding any user-facing UI.

This PR is stacked on #676. Companion Android PR: synonymdev/bitkit-android#1178

Linked Issues/Tasks

N/A

Screenshot / Video

N/A — there are no UI changes.

QA Notes

Manual Tests

• 1. iOS → create a private request for Android → Android receives and pays on regtest: iOS records the proof against the exact request, endpoint, and transaction ID.
• 2. Android → create a private request for iOS → iOS receives and pays on regtest: Android records the proof against the exact request, endpoint, and transaction ID.

Automated Checks

• PaykitPaymentProofServiceTests.swift: 8 tests cover restart retry, duplicate suppression, invalid Lightning preimage rejection, failed-payment cleanup, exact on-chain proof submission, overlapping retries, wallet-store clearing, and completed-proof persistence failure.
• Focused iOS proof tests passed: 8 tests, 0 failures.
• Final iOS simulator Debug test build passed.
• SwiftFormat and git diff --check passed.

[ovitrif]

On-chain payment proofs cannot recover after a store-load failure, so a successful send can still leave the requester without proof.

[ovitrif]

QA Notes

Ran on iPhone 17 Pro simulator and Pixel_9a emulator on regtest.

• iOS created a private request for Android, Android paid, and iOS recorded the proof against that request.
• Android created a private request for iOS, iOS paid, and Android recorded the proof against that request.

Approve.

[ben-kaufman]

Added the cross-platform proof-state hardening in c3f2d8c: corrupt persisted proof state is discarded instead of permanently blocking reconciliation, empty state removes the Keychain entry, and the frequent refresh path returns before calling Paykit when there is nothing to reconcile. The full payment-proof suite passes 22/22 on the restacked subscriptions head.

[ben-kaufman]

Follow-up after the final cleanup: the hardening commit is now 281b8654 (signed). I removed the unnecessary decoder-only test hook while keeping the meaningful regression that proves empty reconciliation skips the Paykit SDK. PaykitPaymentProofServiceTests: 21/21 passing.

[ben-kaufman]

CI note: the remaining pubky_paykit red check is test-harness instability rather than a proof-code failure. Its three internal attempts failed at Appium session creation, waiting for the generic send slider, and teardown/profile cleanup respectively; the final attempt had already dragged the send slider successfully. The same Paykit staging scenario passes on stacked PR #685 with this exact proof implementation. GitHub currently refuses an isolated rerun because this workflow’s unrelated local E2E job is still queued; I will rerun the failed job once the workflow finishes.

[ovitrif]

utACK

[jvsena42]

Found some points that worth a double check

[ben-kaufman]

@jvsena42 Fixed in e66771b. The Payment Request card now uses the shared expanded CustomButton layout in this PR, so the Figma button sizing fix is no longer deferred to #685. The proof delivery comments are also addressed in this head and replied to inline.

[ben-kaufman]

The requested proof lifecycle and Payment Request button fixes are now on the signed e66771b head, all inline threads are resolved, and the focused proof tests pass. @jvsena42 and @ovitrif please re-review when the current E2E run finishes.

[piotr-iohk]

Retested latest revision, iPhone 17 sim ↔ Pixel emu (same session as android #1178).

Amount edit on pay (iOS only)
Paying an incoming request opens the amount pad on iOS. Android goes straight to Confirm and the amount is locked. I changed 1000 → 1009 and swipe failed with Payment failed: amountMismatch (SendConfirmationView.performPayment). Confirm already blocks the amount tap when incomingPaymentRequest is set; looks like the first route still lands on .amount when the opened LN invoice amount is 0.

Recording:

Screen.Recording.2026-09-01.at.16.08.22.mov

Request lists don’t match
Same session, both on TODAY:

• iOS: 3× 1000 + 26 000 (no 25 000)
• Android: 2× 1000 + 26 000 + 25 000

Not amount-keyed overwrite in the app list — IDs are paymentRequestId + counterparty + path. The 25k did land: Android sent it on-chain, iOS activity shows +25 000 (81eaa51b…). It’s missing as an iOS request-history row. Extra 1k on iOS / missing 1k on Android looks like the same thing. Hypothesis: after fulfill, one side drops the row when localRole is missing/unknown (history mapping skips those). Avatars A vs I are just the contact names.

Screenshot (Payment Requests list):

Logs:
bitkit_logs_2026-09-01_14-14-42.zip

Proofs still queued on the successful pays (LN + on-chain both ways). Amount pad / list drift look like follow-ups, not a proofs blocker.

[ben-kaufman]

This PR sends a Paykit payment proof back to the requester after Bitkit successfully pays an incoming private payment request.

Description

1. Persists the payer identity, request, and selected endpoint before request acceptance, then associates the Lightning payment hash before sending so restart recovery keeps the correct correlation.
2. Persists successful on-chain transaction IDs and validated Lightning preimages before submitting them against the original one-time request and exact endpoint.
3. Uses Paykit's durable private outbox, retries incomplete submissions during normal request refresh, and suppresses duplicate proofs already recorded by the SDK.
4. Preserves earlier in-flight correlations across retries, clears the request after one proof is queued, and reads the secure store directly so wallet wipes cannot resurrect cached proof state.
5. Attempts immediate SDK delivery if persisting a completed proof fails, without adding any user-facing UI.

This PR is stacked on #676. Companion Android PR: synonymdev/bitkit-android#1178

Linked Issues/Tasks

N/A

Screenshot / Video

N/A — there are no UI changes.

QA Notes

Manual Tests

• 1. iOS → create a private request for Android → Android receives and pays on regtest: iOS records the proof against the exact request, endpoint, and transaction ID.
• 2. Android → create a private request for iOS → iOS receives and pays on regtest: Android records the proof against the exact request, endpoint, and transaction ID.

Automated Checks

• PaykitPaymentProofServiceTests.swift: 8 tests cover restart retry, duplicate suppression, invalid Lightning preimage rejection, failed-payment cleanup, exact on-chain proof submission, overlapping retries, wallet-store clearing, and completed-proof persistence failure.
• Focused iOS proof tests passed: 8 tests, 0 failures.
• Final iOS simulator Debug test build passed.
• SwiftFormat and git diff --check passed.

[ovitrif]

On-chain payment proofs cannot recover after a store-load failure, so a successful send can still leave the requester without proof.

[ovitrif]

QA Notes

Ran on iPhone 17 Pro simulator and Pixel_9a emulator on regtest.

• iOS created a private request for Android, Android paid, and iOS recorded the proof against that request.
• Android created a private request for iOS, iOS paid, and Android recorded the proof against that request.

Approve.

[ben-kaufman]

Added the cross-platform proof-state hardening in c3f2d8c: corrupt persisted proof state is discarded instead of permanently blocking reconciliation, empty state removes the Keychain entry, and the frequent refresh path returns before calling Paykit when there is nothing to reconcile. The full payment-proof suite passes 22/22 on the restacked subscriptions head.

[ben-kaufman]

Follow-up after the final cleanup: the hardening commit is now 281b8654 (signed). I removed the unnecessary decoder-only test hook while keeping the meaningful regression that proves empty reconciliation skips the Paykit SDK. PaykitPaymentProofServiceTests: 21/21 passing.

[ben-kaufman]

CI note: the remaining pubky_paykit red check is test-harness instability rather than a proof-code failure. Its three internal attempts failed at Appium session creation, waiting for the generic send slider, and teardown/profile cleanup respectively; the final attempt had already dragged the send slider successfully. The same Paykit staging scenario passes on stacked PR #685 with this exact proof implementation. GitHub currently refuses an isolated rerun because this workflow’s unrelated local E2E job is still queued; I will rerun the failed job once the workflow finishes.

[ovitrif]

utACK

[jvsena42]

Found some points that worth a double check

[ben-kaufman]

@jvsena42 Fixed in e66771b. The Payment Request card now uses the shared expanded CustomButton layout in this PR, so the Figma button sizing fix is no longer deferred to #685. The proof delivery comments are also addressed in this head and replied to inline.

[ben-kaufman]

The requested proof lifecycle and Payment Request button fixes are now on the signed e66771b head, all inline threads are resolved, and the focused proof tests pass. @jvsena42 and @ovitrif please re-review when the current E2E run finishes.

[piotr-iohk]

Retested latest revision, iPhone 17 sim ↔ Pixel emu (same session as android #1178).

Amount edit on pay (iOS only)
Paying an incoming request opens the amount pad on iOS. Android goes straight to Confirm and the amount is locked. I changed 1000 → 1009 and swipe failed with Payment failed: amountMismatch (SendConfirmationView.performPayment). Confirm already blocks the amount tap when incomingPaymentRequest is set; looks like the first route still lands on .amount when the opened LN invoice amount is 0.

Recording:

Screen.Recording.2026-09-01.at.16.08.22.mov

Request lists don’t match
Same session, both on TODAY:

• iOS: 3× 1000 + 26 000 (no 25 000)
• Android: 2× 1000 + 26 000 + 25 000

Not amount-keyed overwrite in the app list — IDs are paymentRequestId + counterparty + path. The 25k did land: Android sent it on-chain, iOS activity shows +25 000 (81eaa51b…). It’s missing as an iOS request-history row. Extra 1k on iOS / missing 1k on Android looks like the same thing. Hypothesis: after fulfill, one side drops the row when localRole is missing/unknown (history mapping skips those). Avatars A vs I are just the contact names.

Screenshot (Payment Requests list):

Logs:
bitkit_logs_2026-09-01_14-14-42.zip

Proofs still queued on the successful pays (LN + on-chain both ways). Amount pad / list drift look like follow-ups, not a proofs blocker.

[ben-kaufman]

This PR sends a Paykit payment proof back to the requester after Bitkit successfully pays an incoming private payment request.

Description

1. Persists the payer identity, request, and selected endpoint before request acceptance, then associates the Lightning payment hash before sending so restart recovery keeps the correct correlation.
2. Persists successful on-chain transaction IDs and validated Lightning preimages before submitting them against the original one-time request and exact endpoint.
3. Uses Paykit's durable private outbox, retries incomplete submissions during normal request refresh, and suppresses duplicate proofs already recorded by the SDK.
4. Preserves earlier in-flight correlations across retries, clears the request after one proof is queued, and reads the secure store directly so wallet wipes cannot resurrect cached proof state.
5. Attempts immediate SDK delivery if persisting a completed proof fails, without adding any user-facing UI.

This PR is stacked on #676. Companion Android PR: synonymdev/bitkit-android#1178

Linked Issues/Tasks

N/A

Screenshot / Video

N/A — there are no UI changes.

QA Notes

Manual Tests

• 1. iOS → create a private request for Android → Android receives and pays on regtest: iOS records the proof against the exact request, endpoint, and transaction ID.
• 2. Android → create a private request for iOS → iOS receives and pays on regtest: Android records the proof against the exact request, endpoint, and transaction ID.

Automated Checks

• PaykitPaymentProofServiceTests.swift: 8 tests cover restart retry, duplicate suppression, invalid Lightning preimage rejection, failed-payment cleanup, exact on-chain proof submission, overlapping retries, wallet-store clearing, and completed-proof persistence failure.
• Focused iOS proof tests passed: 8 tests, 0 failures.
• Final iOS simulator Debug test build passed.
• SwiftFormat and git diff --check passed.

[ovitrif]

On-chain payment proofs cannot recover after a store-load failure, so a successful send can still leave the requester without proof.

[ovitrif]

QA Notes

Ran on iPhone 17 Pro simulator and Pixel_9a emulator on regtest.

• iOS created a private request for Android, Android paid, and iOS recorded the proof against that request.
• Android created a private request for iOS, iOS paid, and Android recorded the proof against that request.

Approve.

[ben-kaufman]

Added the cross-platform proof-state hardening in c3f2d8c: corrupt persisted proof state is discarded instead of permanently blocking reconciliation, empty state removes the Keychain entry, and the frequent refresh path returns before calling Paykit when there is nothing to reconcile. The full payment-proof suite passes 22/22 on the restacked subscriptions head.

[ben-kaufman]

Follow-up after the final cleanup: the hardening commit is now 281b8654 (signed). I removed the unnecessary decoder-only test hook while keeping the meaningful regression that proves empty reconciliation skips the Paykit SDK. PaykitPaymentProofServiceTests: 21/21 passing.

[ben-kaufman]

CI note: the remaining pubky_paykit red check is test-harness instability rather than a proof-code failure. Its three internal attempts failed at Appium session creation, waiting for the generic send slider, and teardown/profile cleanup respectively; the final attempt had already dragged the send slider successfully. The same Paykit staging scenario passes on stacked PR #685 with this exact proof implementation. GitHub currently refuses an isolated rerun because this workflow’s unrelated local E2E job is still queued; I will rerun the failed job once the workflow finishes.

[ovitrif]

utACK

[jvsena42]

Found some points that worth a double check

[ben-kaufman]

@jvsena42 Fixed in e66771b. The Payment Request card now uses the shared expanded CustomButton layout in this PR, so the Figma button sizing fix is no longer deferred to #685. The proof delivery comments are also addressed in this head and replied to inline.

[ben-kaufman]

The requested proof lifecycle and Payment Request button fixes are now on the signed e66771b head, all inline threads are resolved, and the focused proof tests pass. @jvsena42 and @ovitrif please re-review when the current E2E run finishes.

[piotr-iohk]

Retested latest revision, iPhone 17 sim ↔ Pixel emu (same session as android #1178).

Amount edit on pay (iOS only)
Paying an incoming request opens the amount pad on iOS. Android goes straight to Confirm and the amount is locked. I changed 1000 → 1009 and swipe failed with Payment failed: amountMismatch (SendConfirmationView.performPayment). Confirm already blocks the amount tap when incomingPaymentRequest is set; looks like the first route still lands on .amount when the opened LN invoice amount is 0.

Recording:

Screen.Recording.2026-09-01.at.16.08.22.mov

Request lists don’t match
Same session, both on TODAY:

• iOS: 3× 1000 + 26 000 (no 25 000)
• Android: 2× 1000 + 26 000 + 25 000

Not amount-keyed overwrite in the app list — IDs are paymentRequestId + counterparty + path. The 25k did land: Android sent it on-chain, iOS activity shows +25 000 (81eaa51b…). It’s missing as an iOS request-history row. Extra 1k on iOS / missing 1k on Android looks like the same thing. Hypothesis: after fulfill, one side drops the row when localRole is missing/unknown (history mapping skips those). Avatars A vs I are just the contact names.

Screenshot (Payment Requests list):

Logs:
bitkit_logs_2026-09-01_14-14-42.zip

Proofs still queued on the successful pays (LN + on-chain both ways). Amount pad / list drift look like follow-ups, not a proofs blocker.

[ben-kaufman]

This PR sends a Paykit payment proof back to the requester after Bitkit successfully pays an incoming private payment request.

Description

1. Persists the payer identity, request, and selected endpoint before request acceptance, then associates the Lightning payment hash before sending so restart recovery keeps the correct correlation.
2. Persists successful on-chain transaction IDs and validated Lightning preimages before submitting them against the original one-time request and exact endpoint.
3. Uses Paykit's durable private outbox, retries incomplete submissions during normal request refresh, and suppresses duplicate proofs already recorded by the SDK.
4. Preserves earlier in-flight correlations across retries, clears the request after one proof is queued, and reads the secure store directly so wallet wipes cannot resurrect cached proof state.
5. Attempts immediate SDK delivery if persisting a completed proof fails, without adding any user-facing UI.

This PR is stacked on #676. Companion Android PR: synonymdev/bitkit-android#1178

Linked Issues/Tasks

N/A

Screenshot / Video

N/A — there are no UI changes.

QA Notes

Manual Tests

• 1. iOS → create a private request for Android → Android receives and pays on regtest: iOS records the proof against the exact request, endpoint, and transaction ID.
• 2. Android → create a private request for iOS → iOS receives and pays on regtest: Android records the proof against the exact request, endpoint, and transaction ID.

Automated Checks

• PaykitPaymentProofServiceTests.swift: 8 tests cover restart retry, duplicate suppression, invalid Lightning preimage rejection, failed-payment cleanup, exact on-chain proof submission, overlapping retries, wallet-store clearing, and completed-proof persistence failure.
• Focused iOS proof tests passed: 8 tests, 0 failures.
• Final iOS simulator Debug test build passed.
• SwiftFormat and git diff --check passed.

[ovitrif]

On-chain payment proofs cannot recover after a store-load failure, so a successful send can still leave the requester without proof.

[ovitrif]

QA Notes

Ran on iPhone 17 Pro simulator and Pixel_9a emulator on regtest.

• iOS created a private request for Android, Android paid, and iOS recorded the proof against that request.
• Android created a private request for iOS, iOS paid, and Android recorded the proof against that request.

Approve.

[ben-kaufman]

Added the cross-platform proof-state hardening in c3f2d8c: corrupt persisted proof state is discarded instead of permanently blocking reconciliation, empty state removes the Keychain entry, and the frequent refresh path returns before calling Paykit when there is nothing to reconcile. The full payment-proof suite passes 22/22 on the restacked subscriptions head.

[ben-kaufman]

Follow-up after the final cleanup: the hardening commit is now 281b8654 (signed). I removed the unnecessary decoder-only test hook while keeping the meaningful regression that proves empty reconciliation skips the Paykit SDK. PaykitPaymentProofServiceTests: 21/21 passing.

[ben-kaufman]

CI note: the remaining pubky_paykit red check is test-harness instability rather than a proof-code failure. Its three internal attempts failed at Appium session creation, waiting for the generic send slider, and teardown/profile cleanup respectively; the final attempt had already dragged the send slider successfully. The same Paykit staging scenario passes on stacked PR #685 with this exact proof implementation. GitHub currently refuses an isolated rerun because this workflow’s unrelated local E2E job is still queued; I will rerun the failed job once the workflow finishes.

[ovitrif]

utACK

[jvsena42]

Found some points that worth a double check

[ben-kaufman]

@jvsena42 Fixed in e66771b. The Payment Request card now uses the shared expanded CustomButton layout in this PR, so the Figma button sizing fix is no longer deferred to #685. The proof delivery comments are also addressed in this head and replied to inline.

[ben-kaufman]

The requested proof lifecycle and Payment Request button fixes are now on the signed e66771b head, all inline threads are resolved, and the focused proof tests pass. @jvsena42 and @ovitrif please re-review when the current E2E run finishes.

[piotr-iohk]

Retested latest revision, iPhone 17 sim ↔ Pixel emu (same session as android #1178).

Amount edit on pay (iOS only)
Paying an incoming request opens the amount pad on iOS. Android goes straight to Confirm and the amount is locked. I changed 1000 → 1009 and swipe failed with Payment failed: amountMismatch (SendConfirmationView.performPayment). Confirm already blocks the amount tap when incomingPaymentRequest is set; looks like the first route still lands on .amount when the opened LN invoice amount is 0.

Recording:

Screen.Recording.2026-09-01.at.16.08.22.mov

Request lists don’t match
Same session, both on TODAY:

• iOS: 3× 1000 + 26 000 (no 25 000)
• Android: 2× 1000 + 26 000 + 25 000

Not amount-keyed overwrite in the app list — IDs are paymentRequestId + counterparty + path. The 25k did land: Android sent it on-chain, iOS activity shows +25 000 (81eaa51b…). It’s missing as an iOS request-history row. Extra 1k on iOS / missing 1k on Android looks like the same thing. Hypothesis: after fulfill, one side drops the row when localRole is missing/unknown (history mapping skips those). Avatars A vs I are just the contact names.

Screenshot (Payment Requests list):

Logs:
bitkit_logs_2026-09-01_14-14-42.zip

Proofs still queued on the successful pays (LN + on-chain both ways). Amount pad / list drift look like follow-ups, not a proofs blocker.

[ben-kaufman]

This PR sends a Paykit payment proof back to the requester after Bitkit successfully pays an incoming private payment request.

Description

1. Persists the payer identity, request, and selected endpoint before request acceptance, then associates the Lightning payment hash before sending so restart recovery keeps the correct correlation.
2. Persists successful on-chain transaction IDs and validated Lightning preimages before submitting them against the original one-time request and exact endpoint.
3. Uses Paykit's durable private outbox, retries incomplete submissions during normal request refresh, and suppresses duplicate proofs already recorded by the SDK.
4. Preserves earlier in-flight correlations across retries, clears the request after one proof is queued, and reads the secure store directly so wallet wipes cannot resurrect cached proof state.
5. Attempts immediate SDK delivery if persisting a completed proof fails, without adding any user-facing UI.

This PR is stacked on #676. Companion Android PR: synonymdev/bitkit-android#1178

Linked Issues/Tasks

N/A

Screenshot / Video

N/A — there are no UI changes.

QA Notes

Manual Tests

• 1. iOS → create a private request for Android → Android receives and pays on regtest: iOS records the proof against the exact request, endpoint, and transaction ID.
• 2. Android → create a private request for iOS → iOS receives and pays on regtest: Android records the proof against the exact request, endpoint, and transaction ID.

Automated Checks

• PaykitPaymentProofServiceTests.swift: 8 tests cover restart retry, duplicate suppression, invalid Lightning preimage rejection, failed-payment cleanup, exact on-chain proof submission, overlapping retries, wallet-store clearing, and completed-proof persistence failure.
• Focused iOS proof tests passed: 8 tests, 0 failures.
• Final iOS simulator Debug test build passed.
• SwiftFormat and git diff --check passed.

[ovitrif]

On-chain payment proofs cannot recover after a store-load failure, so a successful send can still leave the requester without proof.

[ovitrif]

QA Notes

Ran on iPhone 17 Pro simulator and Pixel_9a emulator on regtest.

• iOS created a private request for Android, Android paid, and iOS recorded the proof against that request.
• Android created a private request for iOS, iOS paid, and Android recorded the proof against that request.

Approve.

[ben-kaufman]

Added the cross-platform proof-state hardening in c3f2d8c: corrupt persisted proof state is discarded instead of permanently blocking reconciliation, empty state removes the Keychain entry, and the frequent refresh path returns before calling Paykit when there is nothing to reconcile. The full payment-proof suite passes 22/22 on the restacked subscriptions head.

[ben-kaufman]

Follow-up after the final cleanup: the hardening commit is now 281b8654 (signed). I removed the unnecessary decoder-only test hook while keeping the meaningful regression that proves empty reconciliation skips the Paykit SDK. PaykitPaymentProofServiceTests: 21/21 passing.

[ben-kaufman]

CI note: the remaining pubky_paykit red check is test-harness instability rather than a proof-code failure. Its three internal attempts failed at Appium session creation, waiting for the generic send slider, and teardown/profile cleanup respectively; the final attempt had already dragged the send slider successfully. The same Paykit staging scenario passes on stacked PR #685 with this exact proof implementation. GitHub currently refuses an isolated rerun because this workflow’s unrelated local E2E job is still queued; I will rerun the failed job once the workflow finishes.

[ovitrif]

utACK

[jvsena42]

Found some points that worth a double check

[ben-kaufman]

@jvsena42 Fixed in e66771b. The Payment Request card now uses the shared expanded CustomButton layout in this PR, so the Figma button sizing fix is no longer deferred to #685. The proof delivery comments are also addressed in this head and replied to inline.

[ben-kaufman]

The requested proof lifecycle and Payment Request button fixes are now on the signed e66771b head, all inline threads are resolved, and the focused proof tests pass. @jvsena42 and @ovitrif please re-review when the current E2E run finishes.

[piotr-iohk]

Retested latest revision, iPhone 17 sim ↔ Pixel emu (same session as android #1178).

Amount edit on pay (iOS only)
Paying an incoming request opens the amount pad on iOS. Android goes straight to Confirm and the amount is locked. I changed 1000 → 1009 and swipe failed with Payment failed: amountMismatch (SendConfirmationView.performPayment). Confirm already blocks the amount tap when incomingPaymentRequest is set; looks like the first route still lands on .amount when the opened LN invoice amount is 0.

Recording:

Screen.Recording.2026-09-01.at.16.08.22.mov

Request lists don’t match
Same session, both on TODAY:

• iOS: 3× 1000 + 26 000 (no 25 000)
• Android: 2× 1000 + 26 000 + 25 000

Not amount-keyed overwrite in the app list — IDs are paymentRequestId + counterparty + path. The 25k did land: Android sent it on-chain, iOS activity shows +25 000 (81eaa51b…). It’s missing as an iOS request-history row. Extra 1k on iOS / missing 1k on Android looks like the same thing. Hypothesis: after fulfill, one side drops the row when localRole is missing/unknown (history mapping skips those). Avatars A vs I are just the contact names.

Screenshot (Payment Requests list):

Logs:
bitkit_logs_2026-09-01_14-14-42.zip

Proofs still queued on the successful pays (LN + on-chain both ways). Amount pad / list drift look like follow-ups, not a proofs blocker.

[ben-kaufman]

This PR sends a Paykit payment proof back to the requester after Bitkit successfully pays an incoming private payment request.

Description

1. Persists the payer identity, request, and selected endpoint before request acceptance, then associates the Lightning payment hash before sending so restart recovery keeps the correct correlation.
2. Persists successful on-chain transaction IDs and validated Lightning preimages before submitting them against the original one-time request and exact endpoint.
3. Uses Paykit's durable private outbox, retries incomplete submissions during normal request refresh, and suppresses duplicate proofs already recorded by the SDK.
4. Preserves earlier in-flight correlations across retries, clears the request after one proof is queued, and reads the secure store directly so wallet wipes cannot resurrect cached proof state.
5. Attempts immediate SDK delivery if persisting a completed proof fails, without adding any user-facing UI.

This PR is stacked on #676. Companion Android PR: synonymdev/bitkit-android#1178

Linked Issues/Tasks

N/A

Screenshot / Video

N/A — there are no UI changes.

QA Notes

Manual Tests

• 1. iOS → create a private request for Android → Android receives and pays on regtest: iOS records the proof against the exact request, endpoint, and transaction ID.
• 2. Android → create a private request for iOS → iOS receives and pays on regtest: Android records the proof against the exact request, endpoint, and transaction ID.

Automated Checks

• PaykitPaymentProofServiceTests.swift: 8 tests cover restart retry, duplicate suppression, invalid Lightning preimage rejection, failed-payment cleanup, exact on-chain proof submission, overlapping retries, wallet-store clearing, and completed-proof persistence failure.
• Focused iOS proof tests passed: 8 tests, 0 failures.
• Final iOS simulator Debug test build passed.
• SwiftFormat and git diff --check passed.

[ovitrif]

On-chain payment proofs cannot recover after a store-load failure, so a successful send can still leave the requester without proof.

[ovitrif]

QA Notes

Ran on iPhone 17 Pro simulator and Pixel_9a emulator on regtest.

• iOS created a private request for Android, Android paid, and iOS recorded the proof against that request.
• Android created a private request for iOS, iOS paid, and Android recorded the proof against that request.

Approve.

[ben-kaufman]

Added the cross-platform proof-state hardening in c3f2d8c: corrupt persisted proof state is discarded instead of permanently blocking reconciliation, empty state removes the Keychain entry, and the frequent refresh path returns before calling Paykit when there is nothing to reconcile. The full payment-proof suite passes 22/22 on the restacked subscriptions head.

[ben-kaufman]

Follow-up after the final cleanup: the hardening commit is now 281b8654 (signed). I removed the unnecessary decoder-only test hook while keeping the meaningful regression that proves empty reconciliation skips the Paykit SDK. PaykitPaymentProofServiceTests: 21/21 passing.

[ben-kaufman]

CI note: the remaining pubky_paykit red check is test-harness instability rather than a proof-code failure. Its three internal attempts failed at Appium session creation, waiting for the generic send slider, and teardown/profile cleanup respectively; the final attempt had already dragged the send slider successfully. The same Paykit staging scenario passes on stacked PR #685 with this exact proof implementation. GitHub currently refuses an isolated rerun because this workflow’s unrelated local E2E job is still queued; I will rerun the failed job once the workflow finishes.

[ovitrif]

utACK

[jvsena42]

Found some points that worth a double check

[ben-kaufman]

@jvsena42 Fixed in e66771b. The Payment Request card now uses the shared expanded CustomButton layout in this PR, so the Figma button sizing fix is no longer deferred to #685. The proof delivery comments are also addressed in this head and replied to inline.

[ben-kaufman]

The requested proof lifecycle and Payment Request button fixes are now on the signed e66771b head, all inline threads are resolved, and the focused proof tests pass. @jvsena42 and @ovitrif please re-review when the current E2E run finishes.

[piotr-iohk]

Retested latest revision, iPhone 17 sim ↔ Pixel emu (same session as android #1178).

Amount edit on pay (iOS only)
Paying an incoming request opens the amount pad on iOS. Android goes straight to Confirm and the amount is locked. I changed 1000 → 1009 and swipe failed with Payment failed: amountMismatch (SendConfirmationView.performPayment). Confirm already blocks the amount tap when incomingPaymentRequest is set; looks like the first route still lands on .amount when the opened LN invoice amount is 0.

Recording:

Screen.Recording.2026-09-01.at.16.08.22.mov

Request lists don’t match
Same session, both on TODAY:

• iOS: 3× 1000 + 26 000 (no 25 000)
• Android: 2× 1000 + 26 000 + 25 000

Not amount-keyed overwrite in the app list — IDs are paymentRequestId + counterparty + path. The 25k did land: Android sent it on-chain, iOS activity shows +25 000 (81eaa51b…). It’s missing as an iOS request-history row. Extra 1k on iOS / missing 1k on Android looks like the same thing. Hypothesis: after fulfill, one side drops the row when localRole is missing/unknown (history mapping skips those). Avatars A vs I are just the contact names.

Screenshot (Payment Requests list):

Logs:
bitkit_logs_2026-09-01_14-14-42.zip

Proofs still queued on the successful pays (LN + on-chain both ways). Amount pad / list drift look like follow-ups, not a proofs blocker.

[ben-kaufman]

This PR sends a Paykit payment proof back to the requester after Bitkit successfully pays an incoming private payment request.

Description

1. Persists the payer identity, request, and selected endpoint before request acceptance, then associates the Lightning payment hash before sending so restart recovery keeps the correct correlation.
2. Persists successful on-chain transaction IDs and validated Lightning preimages before submitting them against the original one-time request and exact endpoint.
3. Uses Paykit's durable private outbox, retries incomplete submissions during normal request refresh, and suppresses duplicate proofs already recorded by the SDK.
4. Preserves earlier in-flight correlations across retries, clears the request after one proof is queued, and reads the secure store directly so wallet wipes cannot resurrect cached proof state.
5. Attempts immediate SDK delivery if persisting a completed proof fails, without adding any user-facing UI.

This PR is stacked on #676. Companion Android PR: synonymdev/bitkit-android#1178

Linked Issues/Tasks

N/A

Screenshot / Video

N/A — there are no UI changes.

QA Notes

Manual Tests

• 1. iOS → create a private request for Android → Android receives and pays on regtest: iOS records the proof against the exact request, endpoint, and transaction ID.
• 2. Android → create a private request for iOS → iOS receives and pays on regtest: Android records the proof against the exact request, endpoint, and transaction ID.

Automated Checks

• PaykitPaymentProofServiceTests.swift: 8 tests cover restart retry, duplicate suppression, invalid Lightning preimage rejection, failed-payment cleanup, exact on-chain proof submission, overlapping retries, wallet-store clearing, and completed-proof persistence failure.
• Focused iOS proof tests passed: 8 tests, 0 failures.
• Final iOS simulator Debug test build passed.
• SwiftFormat and git diff --check passed.

[ovitrif]

On-chain payment proofs cannot recover after a store-load failure, so a successful send can still leave the requester without proof.

[ovitrif]

QA Notes

Ran on iPhone 17 Pro simulator and Pixel_9a emulator on regtest.

• iOS created a private request for Android, Android paid, and iOS recorded the proof against that request.
• Android created a private request for iOS, iOS paid, and Android recorded the proof against that request.

Approve.

[ben-kaufman]

Added the cross-platform proof-state hardening in c3f2d8c: corrupt persisted proof state is discarded instead of permanently blocking reconciliation, empty state removes the Keychain entry, and the frequent refresh path returns before calling Paykit when there is nothing to reconcile. The full payment-proof suite passes 22/22 on the restacked subscriptions head.

[ben-kaufman]

Follow-up after the final cleanup: the hardening commit is now 281b8654 (signed). I removed the unnecessary decoder-only test hook while keeping the meaningful regression that proves empty reconciliation skips the Paykit SDK. PaykitPaymentProofServiceTests: 21/21 passing.

[ben-kaufman]

CI note: the remaining pubky_paykit red check is test-harness instability rather than a proof-code failure. Its three internal attempts failed at Appium session creation, waiting for the generic send slider, and teardown/profile cleanup respectively; the final attempt had already dragged the send slider successfully. The same Paykit staging scenario passes on stacked PR #685 with this exact proof implementation. GitHub currently refuses an isolated rerun because this workflow’s unrelated local E2E job is still queued; I will rerun the failed job once the workflow finishes.

[ovitrif]

utACK

[jvsena42]

Found some points that worth a double check

[ben-kaufman]

@jvsena42 Fixed in e66771b. The Payment Request card now uses the shared expanded CustomButton layout in this PR, so the Figma button sizing fix is no longer deferred to #685. The proof delivery comments are also addressed in this head and replied to inline.

[ben-kaufman]

The requested proof lifecycle and Payment Request button fixes are now on the signed e66771b head, all inline threads are resolved, and the focused proof tests pass. @jvsena42 and @ovitrif please re-review when the current E2E run finishes.

[piotr-iohk]

Retested latest revision, iPhone 17 sim ↔ Pixel emu (same session as android #1178).

Amount edit on pay (iOS only)
Paying an incoming request opens the amount pad on iOS. Android goes straight to Confirm and the amount is locked. I changed 1000 → 1009 and swipe failed with Payment failed: amountMismatch (SendConfirmationView.performPayment). Confirm already blocks the amount tap when incomingPaymentRequest is set; looks like the first route still lands on .amount when the opened LN invoice amount is 0.

Recording:

Screen.Recording.2026-09-01.at.16.08.22.mov

Request lists don’t match
Same session, both on TODAY:

• iOS: 3× 1000 + 26 000 (no 25 000)
• Android: 2× 1000 + 26 000 + 25 000

Not amount-keyed overwrite in the app list — IDs are paymentRequestId + counterparty + path. The 25k did land: Android sent it on-chain, iOS activity shows +25 000 (81eaa51b…). It’s missing as an iOS request-history row. Extra 1k on iOS / missing 1k on Android looks like the same thing. Hypothesis: after fulfill, one side drops the row when localRole is missing/unknown (history mapping skips those). Avatars A vs I are just the contact names.

Screenshot (Payment Requests list):

Logs:
bitkit_logs_2026-09-01_14-14-42.zip

Proofs still queued on the successful pays (LN + on-chain both ways). Amount pad / list drift look like follow-ups, not a proofs blocker.

[ben-kaufman]

This PR sends a Paykit payment proof back to the requester after Bitkit successfully pays an incoming private payment request.

Description

1. Persists the payer identity, request, and selected endpoint before request acceptance, then associates the Lightning payment hash before sending so restart recovery keeps the correct correlation.
2. Persists successful on-chain transaction IDs and validated Lightning preimages before submitting them against the original one-time request and exact endpoint.
3. Uses Paykit's durable private outbox, retries incomplete submissions during normal request refresh, and suppresses duplicate proofs already recorded by the SDK.
4. Preserves earlier in-flight correlations across retries, clears the request after one proof is queued, and reads the secure store directly so wallet wipes cannot resurrect cached proof state.
5. Attempts immediate SDK delivery if persisting a completed proof fails, without adding any user-facing UI.

This PR is stacked on #676. Companion Android PR: synonymdev/bitkit-android#1178

Linked Issues/Tasks

N/A

Screenshot / Video

N/A — there are no UI changes.

QA Notes

Manual Tests

• 1. iOS → create a private request for Android → Android receives and pays on regtest: iOS records the proof against the exact request, endpoint, and transaction ID.
• 2. Android → create a private request for iOS → iOS receives and pays on regtest: Android records the proof against the exact request, endpoint, and transaction ID.

Automated Checks

• PaykitPaymentProofServiceTests.swift: 8 tests cover restart retry, duplicate suppression, invalid Lightning preimage rejection, failed-payment cleanup, exact on-chain proof submission, overlapping retries, wallet-store clearing, and completed-proof persistence failure.
• Focused iOS proof tests passed: 8 tests, 0 failures.
• Final iOS simulator Debug test build passed.
• SwiftFormat and git diff --check passed.

[ovitrif]

On-chain payment proofs cannot recover after a store-load failure, so a successful send can still leave the requester without proof.

[ovitrif]

QA Notes

Ran on iPhone 17 Pro simulator and Pixel_9a emulator on regtest.

• iOS created a private request for Android, Android paid, and iOS recorded the proof against that request.
• Android created a private request for iOS, iOS paid, and Android recorded the proof against that request.

Approve.

[ben-kaufman]

Added the cross-platform proof-state hardening in c3f2d8c: corrupt persisted proof state is discarded instead of permanently blocking reconciliation, empty state removes the Keychain entry, and the frequent refresh path returns before calling Paykit when there is nothing to reconcile. The full payment-proof suite passes 22/22 on the restacked subscriptions head.

[ben-kaufman]

Follow-up after the final cleanup: the hardening commit is now 281b8654 (signed). I removed the unnecessary decoder-only test hook while keeping the meaningful regression that proves empty reconciliation skips the Paykit SDK. PaykitPaymentProofServiceTests: 21/21 passing.

[ben-kaufman]

CI note: the remaining pubky_paykit red check is test-harness instability rather than a proof-code failure. Its three internal attempts failed at Appium session creation, waiting for the generic send slider, and teardown/profile cleanup respectively; the final attempt had already dragged the send slider successfully. The same Paykit staging scenario passes on stacked PR #685 with this exact proof implementation. GitHub currently refuses an isolated rerun because this workflow’s unrelated local E2E job is still queued; I will rerun the failed job once the workflow finishes.

[ovitrif]

utACK

[jvsena42]

Found some points that worth a double check

[ben-kaufman]

@jvsena42 Fixed in e66771b. The Payment Request card now uses the shared expanded CustomButton layout in this PR, so the Figma button sizing fix is no longer deferred to #685. The proof delivery comments are also addressed in this head and replied to inline.

[ben-kaufman]

The requested proof lifecycle and Payment Request button fixes are now on the signed e66771b head, all inline threads are resolved, and the focused proof tests pass. @jvsena42 and @ovitrif please re-review when the current E2E run finishes.

[piotr-iohk]

Retested latest revision, iPhone 17 sim ↔ Pixel emu (same session as android #1178).

Amount edit on pay (iOS only)
Paying an incoming request opens the amount pad on iOS. Android goes straight to Confirm and the amount is locked. I changed 1000 → 1009 and swipe failed with Payment failed: amountMismatch (SendConfirmationView.performPayment). Confirm already blocks the amount tap when incomingPaymentRequest is set; looks like the first route still lands on .amount when the opened LN invoice amount is 0.

Recording:

Screen.Recording.2026-09-01.at.16.08.22.mov

Request lists don’t match
Same session, both on TODAY:

• iOS: 3× 1000 + 26 000 (no 25 000)
• Android: 2× 1000 + 26 000 + 25 000

Not amount-keyed overwrite in the app list — IDs are paymentRequestId + counterparty + path. The 25k did land: Android sent it on-chain, iOS activity shows +25 000 (81eaa51b…). It’s missing as an iOS request-history row. Extra 1k on iOS / missing 1k on Android looks like the same thing. Hypothesis: after fulfill, one side drops the row when localRole is missing/unknown (history mapping skips those). Avatars A vs I are just the contact names.

Screenshot (Payment Requests list):

Logs:
bitkit_logs_2026-09-01_14-14-42.zip

Proofs still queued on the successful pays (LN + on-chain both ways). Amount pad / list drift look like follow-ups, not a proofs blocker.