LUD-09 successAction field not visible on the transaction detail

[yanascz]

Related to #2660. Once the payment success screen is dismissed, the content of the successAction field may no longer be displayed.

From the LUD-09 docs:

WALLET should also store successAction data on the transaction record.

It's quite annoying if you dismiss the screen by accident or thinking that you'll be able to access the content again from the transaction detail.

[pretyflaco]

Success messages are not persisted for the time being. Agree it would be useful to have them persistent.

cc @dolcalmi

[al-munazzim]

Implementation Plan for #3463

Summary

Persist LNURL successAction data with transaction records and display it in the transaction detail screen, per LUD-09 specification.

Root Cause

The successAction data from LNURL-pay flows is currently only passed through navigation params to the payment success screen. It is never persisted to the transaction record, so users cannot access it after dismissing the success screen.

The LUD-09 spec states: "WALLET should also store successAction data on the transaction record."

Proposed Approach

Complexity: Medium (cross-stack: backend + frontend)

This fix requires coordinated changes across the backend and mobile app.

Part 1: Backend Changes (blinkbitcoin/blink repo)

Changes required:

• Database schema: Add success_action field to Lightning transaction records
• GraphQL schema: Add successAction field to Transaction type with sub-fields for tag, message, url, description
• Transaction processing: Capture successAction from LNURL-pay callback and persist it

Note: This part requires a separate PR to the backend repo.

Part 2: Frontend Changes (this repo)

Changes required:

• app/graphql/fragments.ts: Add successAction field to Transaction fragment

  settlementVia {
    ... on SettlementViaLn {
      preImage
      successAction {  # NEW
        tag
        message
        url
        description
      }
    }
  }

• app/screens/transaction-detail-screen/transaction-detail-screen.tsx:

  • Import and conditionally render SuccessActionComponent when successAction data exists
  • Only show for Lightning transactions with successAction

Files to modify:

1. app/graphql/fragments.ts - Add successAction to Transaction fragment
2. app/screens/transaction-detail-screen/transaction-detail-screen.tsx - Display successAction

Reuse existing components:

• app/components/success-action/success-action.tsx - Already handles MESSAGE, URL, and AES types
• app/components/success-action/field-with-copy.tsx - Copy-to-clipboard functionality

Testing Plan

• Unit tests: Add test cases for transaction detail with successAction
• Manual testing:
  1. Make LNURL-pay payment with successAction (MESSAGE type)
  2. Make LNURL-pay payment with successAction (URL type)
  3. Make LNURL-pay payment with successAction (AES type)
  4. Verify successAction displays on success screen
  5. Dismiss success screen
  6. Navigate to transaction detail
  7. Verify successAction is visible and interactive (copy, open URL)

Risks & Considerations

• Backend dependency: Frontend PR cannot be merged until backend support is deployed
• Data migration: Existing transactions won't have successAction (acceptable - only new transactions)
• Preimage handling: AES-encrypted successAction requires preimage for decryption - ensure preImage is available in transaction detail context

[k9ert]

I think that seems a good analysis. Can you:

• Create an issue on the blink-repo referencing this one and copy the relevant content there?
• Also add the relevant parts of the implementation plan to this new ticket
• Think again about the implementation
• Create a PR based on that plan

We can then take it from there. Thanks

[al-munazzim]

Hi! I've analyzed this issue and created the backend portion as a separate issue since this requires cross-stack changes:

→ Backend issue: blinkbitcoin/blink#397

The backend needs to persist the successAction data first, then the mobile app can display it in the transaction detail screen. I've included the relevant parts of the implementation plan in the backend issue.

Once the backend changes are deployed, the frontend changes can follow!