Feature requests

Hi Team, I’m currently using your Agency white-label tier, but I’ve run into a major brand isolation issue that makes it easy for clients and competitors to spot our white-label setup. You’ve done an awesome job white-labeling the API and documentation, but I think this is a more pressing priority right now. ⚠️ The Problem: AI & Search Traceability Currently, agencies are instructed to point custom subdomains to ns.digitalwallet.cards . While this domain is meant to be a generic "ghost" address, it is not fully isolated: 👣 Public Footprint: The domain currently hosts your official API v2.0 documentation ( docs.digitalwallet.cards ) and active marketplace apps (e.g., lightspeed.apps.digitalwallet.cards ). 🧑🏻‍💻 Instant AI Detection: Because these public, indexable endpoints live on the exact same domain, I discovered the connection to your brand instantly simply by asking Gemini who owns ns.digitalwallet.cards . The AI immediately identified it as Boomerangme infrastructure. Since tech-savvy clients and competitors regularly use AI assistants and DNS lookups for research, this public link completely breaks the white-label illusion we are paying for. 🟢 The Requested Solution To fix this loophole, we need a truly anonymous routing path. Could the development team implement the following: A Pure "Ghost" CNAME Target: Provide a completely separate, generic domain (e.g., ns.customercards.net or route.loyaltyrouting.com ) dedicated solely to traffic routing. 🌐 Zero Web Presence: Ensure this new domain has absolutely no public web presence, no indexable developer documentation, and no branded subdomains. If visited directly, it should just return a blank page or a 404 error. Could you please let me know if moving to a completely unbranded routing domain is on your immediate roadmap, or if there is an alternative generic target we can use in the meantime? Thank you,

Hi team, I wanted to raise a security concern I noticed with how Sub Accounts & Card links are currently structured on the platform. Each Sub Account & loyalty cards are assigned a sequential numeric ID, for example: -Sub Accounts : https://www.myplatform/agency/clients/111222 Card URL : https://www.myrplatform.com/getpass/1234567 Because the ID is a plain incrementing number, it would be straightforward for anyone to write a script that loops through IDs and visits every card on the platform. Since the card pages are publicly accessible (they need to be, for customers to enroll), this means a bad actor could potentially harvest business names, logos, and other details from every card on the platform at scale. 🟢 What I'd like to request: Replace sequential IDs with random tokens /getpass/a7x9kq2m4p instead of /getpass/1234567 , same thing with Sub accounts, this makes it practically impossible to enumerate cards. Rate-limit the card enrollment endpoint block or challenge requests that hit too many card URLs in a short time. Add bot protection to the enrollment form something like Cloudflare Turnstile or a CAPTCHA to prevent automated fake signups being submitted at scale across cards. Avoid exposing card IDs in CDN asset paths currently the logo URL also contains the numeric ID (e.g. /templates/1234567/logo.png ), which creates a second enumeration surface. This is a relatively simple fix on the backend but it closes a meaningful exposure for all businesses using the platform. Thanks

Manager permissions are currently limited to Business plans, but this restriction is not mentioned in the pricing model. Since Grow Plan clients are already paying for multiple managers, we believe it would add value — and encourage them to keep upgrading — if this feature were available on the Grow Plan as well. Providing manager permissions at this level would demonstrate the benefit of upgrading while still leaving room for clients to move up to the Business plan for additional features. Thank you

WhatsApp is the primary communication channel for businesses in markets like UAE, Saudi Arabia, Brazil, India, and LATAM. Currently, Boomerang supports WhatsApp mainly for loyalty card-related functionality. However, many businesses need the ability to use WhatsApp as a proper broadcast and customer communication channel — similar to how SMS and Email campaigns work today. Current Limitation Businesses are currently unable to: Send WhatsApp broadcast campaigns to customers Reach customers who haven’t installed the loyalty card yet Run promotional campaigns through WhatsApp Send bulk announcements, offers, reminders, or festival campaigns Use WhatsApp as an engagement and retention channel like SMS or Email This is a major limitation because, in many countries, customers are significantly more active on WhatsApp compared to Email or SMS. Especially in WhatsApp-heavy markets, this can become one of the most valuable features in the platform. If this would help your business too, please upvote this request so the Boomerang team can prioritize it

Hi team, GeoPush is a powerful feature, but right now it creates a poor user experience in real scenarios — especially for customers who live or work near a business. 🚨 Current Issue Customers inside a geofence receive repeated notifications: • Multiple times while staying in the same location • Every day without control • Even during late hours (night time) This leads to: ❌ Notification fatigue ❌ Annoyance ❌ Customers removing the loyalty card ⸻ ✅ Suggested Improvements One Notification Per Visit Send only one push notification when entering the geofence, not repeatedly while the user stays inside. ⸻ Daily Frequency Control Allow: • Max 1 notification per day • OR customizable frequency (e.g., once every X days) ⸻ Time Window Settings Let businesses choose when notifications are allowed: • Example: 9:00 → 22:00 • Block notifications at night ⸻ Smart Detection (Optional Advanced) Detect if the user is: • passing by vs • staying long-term (home/work) And adjust notifications accordingly. ⸻ Cooldown System After one notification: • pause notifications for X hours • avoid repeated triggers ⸻ 🎯 Why This Matters GeoPush should: 👉 bring customers back NOT 👉 push them away Right now, over-notification reduces retention — which is the opposite of the goal. ⸻ 💡 Final Thought This feature has huge potential, but it needs smarter control + better UX logic to be effective at scale. Would love to see these improvements implemented 🙌

Just lost a potential client on our highest plan because of the domain connection requirement. All they wanted was to remove the "Powered by " branding from their digital loyalty cards. Currently, removing "Powered by" branding is strictly tied to connecting a custom domain. For non-technical high-ticket clients, the complexity of DNS management and domain procurement is a significant friction point. This has led to lost sales and churn because clients cannot achieve a true white-label experience without technical overhead they aren't prepared to manage. 🟢 Proposed Solutions: Logic Decoupling: Allow the "Powered by [Company]" footer to be updated for White-Label Tier accounts regardless of whether a custom domain is mapped or not - I also suggest moving the "Powered by" section to the card setup. This would be helpful for clients with multiple businesses, as they could then update the "Powered by" label for each individual business. Automated Domain Onboarding: Implement an API integration (e.g., via Namecheap or Cloudflare) that allows users to purchase or connect domains with "one-click" DNS configuration directly from the dashboard. 🔴Business Impact: Implementing these changes will reduce onboarding friction, decrease refund requests from non-technical users.

Currently there is no setting to change the branding color on the registration tab, please add that setting so we can adjust the branding color.

Please fix this bug. Everything looks perfect on PC and Android devices, and my agency's brand favicon is displayed. Unfortunately, ONLY on iPad does the Boomerangme favicon still display, even though I've uploaded my logo in the favicon settings.

Please remove all boomerang identifiers found in the frontend source code to protect our white-label integrity. I've ran a test on a card installation link and found boomerang everywhere after you've update the installation form. Where to Find the Exposures: The following specific areas contain the provider's name and must be scrubbed: • Internationalization (i18n) Objects: Within the main JavaScript bundles (look for self.__next_f.push), there is a large JSON object containing translation keys. Specifically, look at the keys starting with pass_form_. – Examples found: pass_form_terms_of_use_boomerang, pass_form_privacy_rcs_checkbox_boomerang. • Legal Compliance Strings: The text values associated with those keys explicitly name the platform. – Examples found: "...promotional SMS from Boomerang loyalty platform" and "...via Boomerang Loyalty Platform." • Support Email Addresses: Embedded within the legal text for SMS/RCS terms. – Example found: support@boomerangme.cards . • Technical Identifiers: The provider's name is being used as a suffix for various system configurations and metadata tags. ⚙️Instructions for Developers: Search & Replace: Run a global search for the string "boomerang" across the entire repository, including all locales/, components/, and config/ directories. Generic Naming: Replace the provider's name in keys and text with a generic placeholder (e.g., loyalty_platform) or our own system name. Update Fallbacks: Ensure that the default legal text in the messages object is updated to use our support email and brand domain. Verify via Browser: After the fix, open the loyalty card URL, right-click to "View Page Source," and use Ctrl+F to ensure the provider's name no longer appears anywhere in the code.

You did a step in the right direction by unchecking the "i have read and accept term of use" pre-checked chekbox but you did two step backwards with this "when you tap the button, all the checkboxes will be checked automatically". According to GDPR "consent must be explicitly obtained" and checking automatically the checkboxes does not mean that the consent was given. If you want to be compliant the first checkbox should say "I have read and accept terms of use and privacy policy", the second field should be about getting communications from us. That separation is NEEDED because you need one consent to process user's data to create the loyalty card and another one to communicate with the user. Think about realy loyalty cards, the ones in the real world. User gives you his details to get the card but can also decide if he wants to receive emails from us. I understand that communicating with the user is part of our proposition so if he doesn't opt in to receive communications from us you could refuse the service but AT LEAST you should remove the automatically check of checkboxes to be compliant. Link to skool discussion: https://www.skool.com/boomerangme/im-not-sure-the-new-form-is-not-gdpr-compliant