Highlights
⚠️ Please note there are breaking changes in this release.
|
Please remember to perform a hard refresh in your browser after upgrading your environment.
New Features and Improvements
Apple Pay can display tax in the modal
We have made an improvement to the way tax is handled in Limio Components to better support our Apple Pay integration.
There is a new tax setting in Settings > Localisation > Preview tax on the order during checkout if your customer is in one of the countries below (typically used if you want to calculate tax at a regional level).
This new setting has been introduced to support displaying tax in the Apple Pay modal. If a customer’s Apple Pay billing country is listed under this setting, then the Apple Pay modal will show the final price WITH tax.
This will be especially useful for our customers whose tax rates vary by region.
Screenshot: There are now two tax settings in the Localisation settings. The new setting is the second setting in the screenshot.
Read more about configuring tax settings here: How to configure tax behaviour for tax exclusive countries
⚠️ Note: This enhancement has a breaking change regarding Apple Pay.
This release will only have a breaking change if you've upgraded to R102 or R104 in your environment. If you have gone straight from R100 or lower to R105, then there is no breaking change.
You must have an Apple Pay script in the Inject Code attribute on any pages that should use Apple Pay. If it is not present, the modal will not show consistently across all browsers and devices.
In order to avoid any issue, please follow these steps if you have previously adopted R102 or R104.
- Adopt Release 105.
- Add the following script to the Inject Code page attribute on all pages that you want to use Apple Pay on:
- <script src="https://applepay.cdn-apple.com/jsapi/v1/apple-pay-sdk.js"></script>
- Save and rebuild the pages.
- Republish the pages.
- Test a purchase using Apple Pay to verify your payment methods are working properly.
Read more about how to configure Apple Pay here: How to configure Apple Pay for Zuora in Limio
Activate subscription in the Orders Table
Previously, we offered a Customer Orders component that allowed users to perform specific actions on their accounts. This component shared significant functionality with the orders-table component, so we decided to consolidate both components into the Orders Table component to streamline our components library.
The final step in this consolidation was to integrate the subscription activation functionality from the Customer Orders component. This feature enables users to activate their subscriptions that are pending activation in Zuora.
There are two new props on the Orders Table component to support subscription activation:
- Show activate button for pending subscriptions?
- If true, a button displays when the subscription is pending activation. If false, the button never displays regardless of the status of the subscription.
- Activate button label
- Determines the CTA on the activate subscription button
Screenshot: A subscription which is pending activation has the Activate button visible, while a subscription which is already active does not have the button.
The Orders Table component has also been refactored to fully use the Limio SDK.
Read more about our Orders Table component here: Component: Orders Table
Improve how self-service components display schedules when accounts have multiple subscriptions
The Limio self-service components sometimes displayed the incorrect billing information for accounts with multiple subscriptions when the Zuora 1-to-many setting was enabled. For these accounts, when a sync was triggered on a given subscription, the schedule was displaying pricing information from one subscription under that account, but not necessarily the correct one.
We have improved the sync functionality to ensure that the schedule displays the relevant pricing information for the correct subscription, regardless of whether the Zuora 1-to-many setting is enabled.
New setting to exclude contact information syncing from Zuora
There is a new setting which allows you to exclude contact information syncing from Zuora into Limio. We only recommend using this feature if your customers typically have multiple subscriptions, and you want contact information to be tracked separately for different subscriptions.
The setting can be found in Settings > Zuora > Zuora Sync Options > "Do not sync contact information from Zuora into Limio". This setting is false by default.
If the setting is configured to be true, then any contact information in Limio will not be overwritten by Zuora data when a Zuora subscription sync is triggered. A Zuora subscription sync is triggered by manually syncing a subscription in Limio Commerce, or by the customer updating their information or renewing their subscription, online or via Limio for Salesforce. Contact information includes delivery address, billing address, first name, last name, name (first name + last name), email, or phone number.
If the setting is false, data will continue to sync as normal.
Improve Evergreen future schedule creation process
We’ve reviewed how Evergreen subscription schedules work and have made some improvements. Because Evergreen subscriptions don’t have a defined term end, only a limited number of schedules can initially be created. Once all schedules are reached, no further schedules are displayed, resulting in inaccurate information in Limio components that display the “next charge” date. This issue also affected migrated Evergreen subscriptions.
To ensure accurate scheduling for these subscriptions, they need to be synced with Zuora. While previously achievable manually from Limio Commerce, there was no automated solution.
Now, we’ve introduced a script that periodically checks Evergreen subscriptions approaching the end of their schedule and automatically syncs them with Zuora.
Faster page build times with optimised Offers v2 handling
When building multiple campaigns, the system searched for Offers and Add-ons for each campaign, adding unnecessary delays. This has been improved so that the search happens once, speeding up the campaign creation process, especially for larger builds.
Bug Fixes
Timeline in LFS crashes if there are Zuora events associated with the subscription (110173)
Timeline events from external sources, such as Zuora, caused the entire LFS timeline to fail. Now, Zuora events display with limited information, ensuring all timeline events are shown.
Fixed missing tracking object in Apple Pay express checkout (110129)
Subscriptions purchased using Apple Pay express checkout were created without the corresponding "New Subscription" event in Salesforce. This has been fixed to ensure that the tracking object is correctly included and the “New Subscription” event is logged in Salesforce.
Customer details appearing in Limio Commerce search even after obfuscating personal data (110184)
Incomplete data obfuscation meant that customer names and email addresses were still visible in orders that weren’t classified as "new", even when customer data obfuscation was enabled. We resolved this ensuring all customer information including names and emails, is fully removed from all orders following data privacy requests.
External toggle not updating in UI (110350)
We fixed an issue where subscriptions marked as external weren’t being flagged properly. The external flag will now correctly display in on the Subscription page of the Subscriptions tab.
Users can delete published Pages v2 via Bulk Delete (110249)
We’ve improved the bulk delete feature to prevent accidental removal of live pages. You’ll now be prompted to unpublish live pages before they can be deleted, ensuring your active content stays safe.
Customer table component displays error if customer has no subscription
The customer-table component would throw an error when a user signed up but did not complete a subscription. This is fixed so that the customer table now returns a blank screen instead of throwing an error when there is no subscription, aligning it with the behaviour of the orders table.
{{currentPrice}} not available in the Confirm Dialog of the Cancel Save Offer component
The confirm dialogue showed the previous payment amount {{currentPaymentCost}}, while the main component displayed the next payment amount {{currentPrice}}. This has been amended ensuring both components now display consistent pricing information.
Consistent handling of related products in block-related-purchase-modal
We’ve improved how related products are managed to ensure that related products are consistently handled and that the block-related-purchase-modal prevents related products from being purchased.
PayPal button does not render if you click another payment method then go back to Paypal
If customers clicked on Paypal as a payment method, then to another payment method, then back to Paypal, then the Paypal button would not appear the final time. This has now been resolved.
Bug affected R104 only.
No Recaptcha in landing pages on offer components
ReCaptcha may be checked on Landing Page level, in which our Initiate Basket functions will check the score of the recaptcha. As our offer components did not have this capability turned on, this would cause them to always fail.
Additionally, we've fixed an issue where the recaptcha icon would display when it should have been hidden.
Tooltip has duplicated popup message in Form component (110514)
There was an issue where tooltips would show twice when used in the Form component. This is now resolved.
Bug affected R104 only.
Comments
0 comments
Please sign in to leave a comment.