On testnet, a normal transfer between two wallets in Nimiq Pay fails every time: Failed to send payment transaction: Bad Request No Mini App involved — this is the wallet's own send screen. The confirmation sheet appears with the correct recipient and amount, I approve it, and the error comes after approval, so it looks like submission rather than validation. Ruled out - Amount — failed at 10 NIM and at ~7,760 NIM. - Balance — the sending account holds far more than either. - Chain health — our own light client (@nimiq/core 2.20.0) is following testnet right now, head ~10,095,000, advancing normally. It also fails from our Mini App via sendBasicTransactionWithData, but the plain wallet transfer failing is the simpler case, so I'd start there. When it broke — I genuinely don't know The last successful testnet transaction I have is from 1 August, before the v2 fork. Today is the first time I've tested anything since, so the break happened somewhere in that window. I can't say it started today. Questions 1. Is testnet submission from Nimiq Pay currently working for anyone else, or is the wallet's testnet backend down? 2. Does anything about transactions need to change after the v2 fork — our own node needed upgrading to 2.20.0 before it could follow the chain again. Environment: Nimiq Pay 2.19.1, Android 17, testnet. Sender NQ71 X7LF 40FY 36YC VY8E GT5K 7D33 DBY5 U5JK, attempts on 2026-08-30 around 09:02 UTC.

Cycle 1 is officially in the books. 62 Mini Apps submitted, all of them scored by the Nimiq Community Council, and the results are final. 🥁 Drumroll please… 🥇 1st place: Nimiq Space by @Harley NSpace An open multiplayer world where wallet-signed players can see who is online right now, paint a persistent 500x500 collaborative floor, and build rooms that sync live for everyone in them. 🥈 2nd place: NimJump by @Emre Alt An arcade game built around a minimal client-authority architecture, where the server replays every run itself instead of trusting the score the client reports. 🥉 3rd place: NimQuest by @mystiquemide A learn-and-prove Mini App with server-graded quizzes, where a completion only counts once you sign a one-time message in Nimiq Pay. Congratulations to all three. Winners will be contacted directly to arrange payout. To everyone else who submitted, thank you. You shipped something real in four weeks and set the bar high for future cycles. Every app you built is yours under the MIT License, so keep going with it. 🗓️ Cycle 2 opens August 24. Same $17,000 USDT prize pool, four Sip & Ship calls, submissions close September 18 at 23:59 UTC. If your app did not place this time, you can refine it and submit it again. Full breakdown on all three winners: https://www.nimiq.com/blog/mini-apps-competition-cycle-1-winner-announcement

I'm trying to figure out how to get my Nimiq Pay to connect to testnet. Is there a hidden setting somewhere?

Hey builders! 👋 Just submitted Nimble — and if you're from Poland you'll recognize the idea instantly: it's BLIK-style payments on Nimiq. Here's the 10-second pitch: QR codes can be swapped with a sticker, links can be phished, addresses are unreadable hashes you trust blindly. A one-time 6-digit code has none of those problems — it's not a credential, it moves no money by itself, and you can say it out loud across a market stall. In Poland this UX beat cards for P2P. I wanted that "just tell me the code" moment for crypto. How it works (takes ~15 seconds with two phones): 1. Payer taps Pay → gets a code inside a countdown ring 2. Receiver types the amount + the code 3. Payer sees exactly who gets paid and how much → one tap in the wallet 4. Both screens go green "Paid" seconds after inclusion; Albatross finality and the receipt settle silently in the background Try it right now (testnet, no real money): - Nimiq Pay → long-press settings → switch to Testnet → grab faucet NIM - Mini Apps → Custom URL → https://nimble.gallareton.pl - Grab a second phone (or a friend here!) and pair with a code 🎥 Demo video: https://youtu.be/mwSJtvYDoeA 💻 Code (MIT): https://github.com/gallareton/nimble Under the hood: wallet-signature auth with silent session refresh, atomic code claiming with rate limits and uniform errors, real-time status over SSE, on-chain reconciliation if the app dies mid-payment (token hidden in the tx data field), receipts with the USD value frozen at finality, 6 languages picked up from Nimiq Pay's host language. I'd love feedback on: the two-phone pairing flow (any confusion?), the "Paid vs final" two-phase status, and what you'd want next — I have request-by-link, bill splitting and Cashlink-style cheques on the roadmap. Happy to test your apps back — drop your links 👇

Following up on the network request from this week — here's a second small gap, with a real bug story attached. What happened: I added a pre-flight check to Nimble so a payer sees "not enough NIM" on the approval screen instead of tapping through to the wallet only to be refused. My backend read the balance from the embedded Nimiq client… and every payment got blocked. Turns out the web client runs Pico sync: no accounts tree, so getAccount() returns balance: 0 for any address it doesn't own. A wallet holding 200k NIM reported zero — before and after subscribing the address. I ripped the feature out. Then I looked for the obvious source instead — the wallet itself. It's the connected wallet, it's the user's own account, and Nimiq Pay clearly knows the number (it's on the home screen). But window.nimiq exposes: listAccounts, sign, isConsensusEstablished, getBlockNumber, sendBasicTransaction(WithData) + staking. No balance anywhere, and nothing on window.nimiqPay either (language + device id only). The ask: nimiq.getBalance() (or balance on the accounts returned by listAccounts) for the connected accounts only — no privacy expansion, the user already granted access to that account. Why it's worth it: any Mini App handling payments wants to answer "can this user afford this?" before the wallet sheet opens. Right now the alternatives are all bad: run a full node just to read one balance, depend on a third-party RPC/explorer, or let people hit a refusal they could have been warned about. It's a UX papercut in every payment app on the platform, not just mine. Happy to test a beta build against Nimble, and to open an issue/PR if you point me at the right repo. If you've hit the same wall, a +1 below probably helps 🙂