Feature requests

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

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.

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

The trillion needs to be £ (as someone said below) and the word check needs to be changed to spend for it to make sense in the UK. I've had some feedback that it looks great but that they assumed it wasn't really for the UK market. Many thanks

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 🙌

For agencies that offer value-adds like 100% account setup and digital-first, we need to be able to choose and make it optional to offer a 14-day free trial, as implementation requires a significant effort (money) from the agency team. In our experience, we've seen that some clients prefer to have their account set up and make the most of your subscription, rather than learn how to create their cards, etc. One solution for this could be to enable the feature for clients to add their payment card upon registration, but this isn't feasible since they can cancel before the 14-day deadline. In the meantime, our agency team has already configured everything.

Am i the only one wanting to create cards templates via API so that when the customer logs into his account needs only to edit the design and few other settings but the structure is already in place? This is particularly useful if you adopt the same mechanics for all the customers: for example a 10% coupon card linked to a reward card. You could save yourself a lot of support time if you could create those templates via API.

API WL Docs I Profile Get agency profile patch Edit agency profile. Hide this from API WL DOCS please

If you send a mailing test at mail-tester.com you'll see various alerts: Your message should contain an <html> tag You should also include a text version of your message Your message does not contain a List-Unsubscribe header Those goes hand in hand with the need of an unsubscribe link which is still planned since a year: https://bmrng.canny.io/roadmap/p/need-of-unsubscribe-link-option-to-be-compliant-with-canspam-act-of-us Without those enhancements in place we are simply burning money when sending mails because no matter what you end up in the spam folder.