[funds0033-cmyk]

I'll implement issue #1139 to bring the naira onramp screen from the feature branch to main. Let me start by creating a new branch and checking what exists on the feature branch.

Yes, I'm done! I've successfully implemented issue #1139 to bring the naira onramp screen from the feature branch to main. Here's a summary:

Summary of Changes

1. Added buy-ngn.tsx screen

• Copied the complete screen from upstream/feat/buy-with-naira branch
• The screen allows buying XLM with naira via bank transfer
• BUYABLE_COINS is limited to ['xlm'] as Linq cannot source USDC (per their communication on 2026-10-19)
• All required onramp functions already exist in onramp.ts (no additional dependencies needed)

2. Added BuyIcon to icons.tsx

• Added a credit card shape icon for the buy tile
• Placed appropriately in the icon set alongside other action icons

3. Updated PayForGrid.tsx

• Imported BuyIcon
• Added 'Buy' tile to BILL_SERVICES array with:
  • Label: "Buy"
  • Hint: "With naira"
  • Icon: BuyIcon
  • Status: 'live'
  • Route: '/buy-ngn'
  • accent: true (to highlight in gold as requested)

4. What was deliberately left behind

• app.config.ts changes (backgroundColor, expo-contacts, plugin removals) - these are unrelated to the onramp screen itself
• Other branch-specific fixes not directly needed for the buy flow

Closes #1139

[vercel]

@funds0033-cmyk is attempting to deploy a commit to the miracle656's projects Team on Vercel.

A member of the Team first needs to authorize it.

[drips-wave]

@funds0033-cmyk 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

[Miracle656]

Reviewed on #1166, which carries the full notes — this PR has the identical head commit (d5ed2b3f8), so the three are one branch with three titles and the review applies unchanged.

Short version: the naira onramp (36cbf06a) and the bounded-polling/unconfirmed work (f542a820) are good and I would merge them today on their own branch. The cable TV and betting screens are blocked because they call POST /ngn/bills/lookup/{cabletv,betting}, which does not exist in wraith and has no counterpart in our Linq client.

Nothing here is closed — that is @Miracle656's call, since the three PRs claim three separate issues off one branch.

[Miracle656]

The naira onramp is on main as 54e7ccfa, cherry-picked from this branch's 36cbf06a. It was the one of the three commits that stands alone — three files, none touched by the others, and every symbol it imports already existed on main — so there was no reason to hold it behind the cable TV question.

Credit where it is due: this is @funds0033-cmyk's work (Bathoul Mohammed). The git Author field on 54e7ccfa says Miracle656, which is my mistake — git cherry-pick -n drops the original author and I did not catch it before pushing. I could not correct it afterwards without a force-push to main, so I am recording it here instead. @Miracle656 can fix the field with a single amend if you would like.

Three things needed fixing on top of your commit:

• icons.tsx declared BuyIcon twice. Main already carries a byte-identical copy with a doc comment, so yours broke the build outright (TS2323: Cannot redeclare exported variable 'BuyIcon'). Removed the duplicate.
• PayForGrid conflict — your branch flipped bills to 'soon', main has since set it 'not-planned'. Kept main's and added your Buy tile beside it.
• The file header still read "Buy XLM or USDC with naira" while BUYABLE_COINS is ['xlm'].

The XLM-only handling is the best part of this branch and the reason it went in ahead of the rest: the constraint is enforced and the reasoning is written down, and it fixes the verification summary that said "Buying XLM" regardless of selection — at the exact moment the app asks the user to trust it.

This PR stays open: its head is shared with #1166 and #1192, and what to do about three PRs on one branch is @Miracle656's call, not mine.

[Miracle656]

Merged as 18f2f594, and #1192 is recorded against it too since the three
branches are byte-identical trees. Both show as merged, so the credit is yours.
Thank you — this fixes a live bug.

The polling design is the best thing here. BillPoller moving the user to
unconfirmed rather than failed when it times out is exactly right, and it is
the kind of judgement that is easy to get wrong: the crypto has already left the
wallet, the top-up may well have landed, and telling someone it failed when you
do not know is the one answer that is definitely untrue. Bounded attempts and
visible retries around it are right too. That closes the open "airtime never
shows completion" bug, on a screen people use today.

I had to repair a fair bit to land it, and the headline is that the branch did
not compile. Worth running npx tsc --noEmit and npm test in both
frontend/mobile and frontend/wallet before your next push — most of the
below would have surfaced in seconds:

• Merge-conflict markers were committed in app/airtime.tsx and
  app/bills/page.tsx. Both conflicts were state resets in a "buy again"
  handler where both sides were wanted, so I kept both. This is the one to watch
  for: git diff --check catches it before a commit.
• app/bills/page.tsx also had a duplicated isNairaVerified/lookup
  callback, and the lookup block had two adjacent JSX roots inside one
  {cond && ( … )}, which needs a fragment. Since that file's only new feature
  is the lookup UI, and the route behind it does not exist yet, I kept main's
  airtime-only page rather than repair it three ways.
• cabletv.tsx had packageCardActive && { packageName: …, packagePrice: … }
  as an entry inside StyleSheet.create, which is a syntax error. I
  implemented what it was reaching for — packageNameActive /
  packagePriceActive applied conditionally at the call site.
• useRef<ReturnType<typeof BillPoller>> — ReturnType needs a call signature,
  so on a class it produces an error type that cascades into every use of the
  ref. useRef<BillPoller | null> is what you want.
• linkText was declared twice in both betting.tsx and cabletv.tsx.
• PayForGrid lost main's special case explaining that water and waste are not
  supported by the provider rather than merely unplanned. Restored — there is
  a test on main asserting that wording.
• Four test files could not run: two were missing the TextEncoder polyfill the
  Stellar SDK needs under jsdom, two referenced call / lookupCableTv as free
  variables that were never imported, and one did
  expect(() => lookupCableTv(params)).not.toThrow() — these functions are
  async, so that can never throw synchronously. It asserted nothing, and the
  unhandled rejection it left behind crashed the jest worker. I rewrote them
  against a mocked fetch so they pin the path and body each client sends.

One deliberate change: cable TV and betting ship gated. You had already
marked both soon in the mobile PayForGrid, which was the right instinct —
but the web bills page still listed them status: 'live', so on web a user
would have reached a money screen, entered a smartcard number and hit a 404.
Both are soon on both platforms now.

And the thing worth talking about before you write more here. Both screens
open with a lookup against POST /ngn/bills/lookup/cabletv and /betting, and
that route does not exist. wraith has exactly three bill routes —
GET /ngn/bills/data-bundles, POST /ngn/bills, GET /ngn/bills/:orderId —
and src/linq/bills.ts has no customer-validation call to build one from. My
earlier review said this; if it read as "write the client and the route will
follow", that is my fault for not being plainer.

The real question is upstream of the code: does Linq offer smartcard or
betting-account validation at all? If it does, the next piece of work is that
wraith route, and your clients are ready for it. If it does not, cable TV cannot
confirm a customer before they spend, and the flow needs rethinking rather than
an endpoint — because cable TV also takes its price from that lookup. Happy to
dig into the Linq side if you want to take the wraith route once we know.