Stack Wallet

This commit fixes a bug in the Stack Wallet app's integration with ShopInBit. Previously, if the server returned a successful HTTP response with an empty body, the app would pretend it received valid data and create fake placeholder objects (for example, a support ticket with ID 0). Now the app correctly treats an empty successful response as an error instead. This is a defensive fix that prevents the app from acting on fabricated data, which could confuse users or lead to incorrect app behavior.

This commit fixes a business-logic bug in Stack Wallet's ShopinBit ticket screen. Previously, car-research invoices that had expired but were still within a 24-hour grace period were incorrectly treated as unpayable, so users could not resume or recover them. The change extends the payable check from the original expiration time to 24 hours after expiration, matching the documented spec. There is no direct security signal in the diff itself.

This commit fixes a bug in the Stack Wallet app's integration with ShopInBit. Previously, if the app's login token expired while making a request, the app would simply fail. Now, when it receives an HTTP 401 'unauthorized' error, it automatically refreshes the token once and retries the request. This is a routine reliability fix rather than a security vulnerability patch.

This commit fixes a small integration bug in the Stack Wallet app's ShopInBit payment feature. Previously, when a user tried to refresh an expired invoice, the app called the server without the required retry=true flag. The fix adds that flag so the server regenerates the invoice instead of returning an error. There is no direct evidence this is a security vulnerability; it appears to be a normal bug fix for a broken user flow.

This is a routine code cleanup commit. It removes one unused import and fixes a Dart lint warning by replacing an unnecessary null-assertion operator with a direct property access. There is no security-relevant change.

This commit fixes a race condition in the Stack Wallet app's ShopinBit feature. Previously, the app stored one shared 'customer key' on the API client object. When refreshing multiple tickets that belonged to different customer keys, one ticket's key could overwrite another's mid-refresh, causing requests to be sent with the wrong key. The fix passes the correct customer key alongside each individual request instead of relying on shared state. The commit message notes the fix may introduce other bugs elsewhere.

This commit removes a small performance optimization in the Stack Wallet app's ShopInBit service. Previously, if multiple parts of the app tried to fetch the same ticket list or car-research invoice list at the same time, they would share one network request. After this change, each call goes straight to the API independently. There is no security fix or vulnerability here—it's a straightforward code simplification that may slightly increase API traffic.

This commit removes a fallback mechanism in Stack Wallet's ShopInBit car-research payment flow. Previously, if the server didn't immediately provide the real customer-support ticket ID, the app would try to guess it by listing all tickets associated with the customer and picking the newest one that wasn't already known. That fallback is now deleted; the app simply waits for the server to supply the real ticket ID directly. The change is described as a functional fix, not a security fix, but removing a heuristic that touches other customer tickets reduces the risk of accidentally opening or acting on the wrong ticket.

This commit is a simple code cleanup: it moves the same retry-backoff calculation used by three different screens into one shared helper inside the ShopInBit client. There is no change in behavior, no bug fix, and no security improvement or regression.

This commit updates the Stack Wallet app's 'ShopinBit car research' feature to work with a newer version of the partner API (v1.0.6). It mainly changes how the app checks whether a customer has paid the car-research fee and how it finds the resulting support ticket. The old code relied on a separate 'log payment' API call that is being removed; the new code reads the payment/ticket status directly from a status endpoint. There is no obvious security bug being fixed, but the change removes a workaround where payment confirmation was partly driven by the client calling a logging endpoint.

This commit is a small UI cleanup in a cryptocurrency wallet app. It restores a 'building transaction' loading dialog on desktop, swaps one style of address picker dialog for another, and moves two hard-coded note strings into a shared constants file. There is no obvious security fix or vulnerability being introduced; it looks like ordinary bug-fix/refactoring work.

This commit changes the post-payment navigation in the ShopInBit feature of Stack Wallet. After a user pays, the app now tries to return them to the specific purchase request they came from, instead of always sending them to the general requests list. There is no security issue visible in this change.

This change is a performance fix, not a security fix. It prevents the wallet's ShopInBit ticket screen from making duplicate API calls when several refreshes happen at the same time. The code now shares one in-flight request among callers instead of firing multiple identical requests. There is no evidence in the commit of a vulnerability being patched.

This commit fixes a bug in Stack Wallet's ShopInBit feature where the app kept asking the server for updates every 15 or 30 seconds, even when the server was already saying 'slow down' (HTTP 429) or the request failed. The fix adds a backoff that doubles the wait time after failures, pauses polling when the app is in the background, and starts logging errors that were previously silently ignored. It is a defensive hardening change, not an active vulnerability being exploited.

This change adjusts how the app waits for a car-purchase ticket to become available. Instead of asking the server every 3 seconds for 36 seconds (12 tries), it now asks fewer times and waits longer between each try. This is a reliability and politeness fix that reduces unnecessary load on the server and the user's device; it does not appear to be a security patch.

This commit fixes a reliability issue in the Stack Wallet app's integration with ShopinBit. Previously, when the ShopinBit server was overwhelmed and returned a '429 Too Many Requests' error, the app would immediately give up and let the caller retry right away, potentially hammering the server even harder. Now, the app automatically waits and retries up to three times, respecting the server's 'Retry-After' instruction or using a sensible backoff delay. This is a defensive improvement that reduces accidental denial-of-service behavior and improves request success rates under load.

This commit adds a QR code display to a payment screen so users can scan an address with another wallet app instead of copying and pasting it. There is no security issue visible in the change.

This commit fixes a user-experience bug in the Stack Wallet app's ShopInBit payment flow on desktop. Previously, opening the 'send from' wallet dialog would close the entire payment dialog, so after sending funds the user was dumped back at the Services page instead of returning to the payment view. The change keeps the payment dialog open underneath the send dialog. There is no security vulnerability here—just a navigation/UI behavior fix.

This commit is a routine user-experience improvement for a cryptocurrency wallet's car-research payment flow. It makes the app wait a bit longer for a backend ticket to appear and adds a 'My Requests' shortcut button so users don't have to navigate manually. There is no security-relevant change in the diff.

This commit only adds logging to error paths in the ShopinBit and CakePay shopping/payment flows. It does not change how errors are handled or fix any underlying bug; it simply records details that were previously silently ignored. There is no direct security fix here, but better logging can help developers detect and diagnose future problems.

This commit fixes a minor behavior bug in the Stack Wallet app's ShopInBit ticket screen. Previously, the app kept checking (polling) a support or order ticket every 30 seconds even after the ticket was already closed, merged, or refunded. The change makes the app stop polling once the ticket reaches a final, unchangeable state. This is mainly a resource/battery/network efficiency fix, not a security fix.

This commit fixes a bug in the Stack Wallet app's ShopInBit car-research payment flow. Previously, after a customer paid the research fee, the app tried to open the wrong ticket (a partner-only fee receipt that the customer cannot view), which could leave the user stuck or confused. The fix adds logic to find and open the actual customer-facing car-research ticket instead, with retries and a clearer message if it isn't ready yet.

This commit makes the app more forgiving when it receives incomplete or oddly formatted data from the ShopinBit shopping service. It replaces several strict parsing rules with fallback values (for example, using today's date if an expiration date is missing, or 0 if a ticket ID can't be read). The change is defensive and reduces the chance that a malformed API response will crash the wallet, but it also silently hides bad data instead of reporting it. There is no direct evidence this fixes an active security vulnerability or was exploited.

This commit updates a status-checking helper in the Stack Wallet app so that two additional order/ticket states ('pendingClose' and 'refunded') are treated as 'terminal' or final states. Previously, only 'closed', 'closedCancelled', and 'merged' were considered finished. The change is a small bug fix in business logic and does not, by itself, appear to introduce a security vulnerability. The main security-relevant concern is whether treating these states as terminal could hide or prematurely stop handling of orders that still need user action or refunds, but the diff alone does not show that such mishandling actually occurs or is exploitable.

This commit is a small performance optimization for a feature that fetches support ticket details from a third-party shopping service. It adds a shortcut so that if a ticket is already in a final state (closed, cancelled, or merged), the app skips making three API calls and uses the locally stored data instead. There is no indication this change fixes a security vulnerability.