Stack Wallet

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.

This commit fixes a minor app crash and adds better error logging. The app was failing when a backend response contained an empty VAT rate field, because the code expected a number and couldn't handle an empty string. The fix makes the VAT rate optional and safely parses it. The logging change helps developers see what went wrong during invoice loading.

This is a small user-experience and diagnostics fix in a cryptocurrency wallet's car-research payment screen. It replaces a silent failure during a background polling loop with a logged error message, while keeping the existing on-screen error notification. There is no direct security vulnerability visible in the change.

This commit is a large work-in-progress refactor of the ShopinBit feature inside the Stack Wallet app. It restructures local database tables, generated code, and UI files to support a new customer-key-based account model and ticket storage. There is no direct evidence in the commit message or diff that this is a security fix, security patch, or response to a reported vulnerability. It appears to be ordinary feature/codebase maintenance.

This commit simply turns a feature flag back on for a third-party shopping integration called 'shopinBit' in two build configuration scripts. It adds one line to each script that includes the feature in the list of enabled app features. There is nothing in the commit that fixes, introduces, or describes a security vulnerability.

This commit refactors how a shopping feature in Stack Wallet loads country lists. Instead of fetching countries inside the shipping screen, it now fetches them earlier when the user accepts an offer, shows a loading spinner, validates the delivery country, and passes the list forward as a required argument. The change makes the shipping screen simpler and removes a fallback path where users could pick a different delivery country for restored orders. There is no obvious security bug in the diff, but the change removes some flexibility and error tolerance.

This commit removes a feature flag called 'shopinBit' from two build configuration scripts, effectively hiding that feature from two app variants (Stack Wallet and Stack Duo). There is no code change that fixes or changes any security behavior, cryptographic operation, network request, permission, or data handling. It is a straightforward feature-toggle removal with no apparent security relevance based on the diff alone.

This commit fixes a bug in Stack Wallet where transaction fee previews did not include the extra cost of adding an OP_RETURN data output for Firo public-balance sends. As a result, users could have been shown a lower fee than what the network would actually charge, or the wallet might have constructed an under-funded transaction. The patch adds the missing fee calculation, makes the OP_RETURN state provider auto-dispose to avoid stale data, and guards state updates with a 'mounted' check to prevent crashes after a screen is closed.

This commit adds support for embedding small pieces of public metadata (called OP_RETURN data) into cryptocurrency transactions, specifically to enable a feature called Rosen Bridge. The code lets users paste a special payment link or scan a QR code that includes bridge instructions, shows a warning if the user tries to use a private balance, and only allows the metadata on public Firo transactions. It also enforces an 80-byte size limit and validates the data before adding it to the transaction.