What’s new in November ‘22:
Brand new this month is our Vouchers feature. We have a full documentation article on how to configure and use them. But I thought it would be interesting to go over some of the design challenges and decisions we made when implementing something that has been around forever in the world of eCommerce.
Ease-of-use vs Security
One of the main things we wanted to achieve with Vouchers, was allowing a customer to use a voucher without needing to have a login account. This is important as there should be no requirement for the recipient to make an account just to use their voucher. But if you don’t require a customer log-in to use a voucher, how secure is that going to be?
We considered an easy path to implement vouchers securely by piggy-backing off our Account Credit feature. Customers could log in and redeem a voucher which would transfer the voucher’s balance to their Account Credit. This is certainly more secure, but there are downsides: a) they have to have an account, and b) since the voucher value is tied to their account, they can’t easily give the rest of it away or let someone else in the family use it. Not so customer-friendly.
Instead of going down that path, we chose to make vouchers usable at checkout without requiring a login by making sure the default codes we generate are long enough that they are essentially unguessable.
Long Codes (WARNING: Maths ahead)
By default, we generate a 16-digit code containing numbers and letters. Since the codes are case insensitive, that gives us a total of 36 possible characters (26 letters and 10 numbers). For a 16-digit code, that’s 3616 possible codes, or 7.96 x 1024 unique combinations. That is quite a lot.
Let’s just say you issue 1 billion vouchers. That gives someone a 1 in 7.96 x1015 chance of guessing one of the codes correctly. And let’s say they could make a guess at a rate of one per second, it would still take over 250 million years to guarantee you could guess one of them correctly.
If we were to reduce the code to 12-digits this would come down to about 150 years - still long, but not quite so impressive. We think 16-digits is a pretty good default, however if you want to set your own digits, to customise either the length, or even the composition of the code, you can do that with custom code generation!
Custom Code Generation
No, this is not some AI program that is going to put our developers out of a job. This is a nifty way our clients can override our default algorithm for generating codes. The full details are in our documentation, but the gist of it is that you can enter the name of an Apex class in one of our Custom Settings, and we will call that class when it’s time to generate a new code.
Vouchers and Stores
One of the great advantages of StoreConnect is you can have multiple stores all running out of the one Salesforce Org. Lots of our clients have developed a multi-store approach, and this made it important that we have a good answer for how Vouchers can be configured to work on just one store, or many stores, or all stores.
By default a voucher can only be used on the store it was purchased on (or created in). However, they can be configured to be used in any store in its Store Group or even any store in your Org at all. Once again, refer to the documentation for full details.
Inviting your existing contacts to log in to your online store can now be triggered directly from Salesforce. Previously there were several steps to accomplish this, but now it’s as simple as checking a checkbox.
Simply check the “Send Invitation” checkbox on the Contact record, and they will receive an invitation email to set a password to create a login account. This is now the best way to invite your existing contacts to log into your store.
We have made some improvements to our automation tools to allow all stores to default to test mode. This means that unless and until you switch your store to live mode, any test payments you make will not be included in your monthly shared success calculation. You can easily see when you’re in test mode so you can put through lots of test orders confident you won’t be incurring shared success fees.
When your store goes live, our tooling will switch you out of test mode so that you can start accepting live payments.
Once you are live, you can continue to place Test Orders (which do not incur Shared Success Fees) by using a test email account, see our Test Orders document for details.
This release updates the Liquid version to 0.10.11. Over the past year we have been migrating our Default Theme to Liquid Themes. Liquid themes allow full customisation of your store pages from within Salesforce.
For more information on Liquid Themes in general see our Theme Builder documentation, our technical demonstration video of themes and the Liquid documentation for the current Liquid version. You can also download our current theme, (located at the button of this page) and use it as a starting point to customise your look and feel, or as a reference for creating a new one.
In this release we migrated the Account’s section to Liquid. The Accounts pages are the pages that your customer can see when they are logged in. In their Account section they can:
- See and update their profile details
- Update their shipping/billing address
- Change their password
- See past orders
- See their subscriptions, account credit, etc
These pages are now all moved to Liquid, along with other related pages such as login, register, forgot password, and similar pages. You can now override these as needed. See the full list of available page templates in our documentation.
One of the main considerations when migrating our built-in templates to Liquid is that we want to enable our clients to have as much freedom as possible to customise their store and take it in whatever direction best suits them. You can see how we have achieved this in our new Liquid Accounts section.
Warning: this gets technical! Let’s take the general purpose accounts pages we had previously. We had identified that customers will want to update their shipping address, or change their email address, or for the security-conscious, update their password. We had separate pages for all of these tasks, along with a page for seeing their order history, managing their subscriptions and so on. The data that was required for each page was only available on that page.
This is not particularly flexible however, and doesn’t meet our standards for not dictating site structures unnecessarily. We knew we could do better with Liquid. Here’s 3 things we did to make the Accounts section super-flexible;
1 - Take advantage of Liquid Variables
Liquid variables are powerful. They allow you to access information on that particular variable, but also information on related variables. Take the variable
current_customer. It gives you access to the Contact object for the currently logged in customer, such as
account which return further objects you can use.
This means that using just the one template, you can show whatever information you can access from an object such as contact. That’s why we only define one page template for this whole section
pages/account. You can access and show all the information you would want about the current customer on the one page.
2 - Wildcard URLs
Of course, showing all possible information on the one page is not ideal. This information should be split up into sections much like our original page was. But we don’t want to dictate how you should split it up, so we have introduced a wildcard URL that allows you to split the pages up as you see fit.
The base URL for the Accounts page is
/account. This will render the
pages/account template. However, any URL that matches the patterns
account/<section>/<identifier> also render the
pages/account template. In the template you can then detect what section and/or identifier have been used (via the
param attribute of the global variable
current_request which returns a Request object), and show different content accordingly.
For example, our default theme has chosen to respond to
account/orders to show the list of the customers previous orders. And likewise
account/orders/<order ref number> will show the details of that one order. You could implement
account/my-orders if you wanted to, or not implement a dedicated order list page at all, instead opting to show it on the main
/account page. Your choice.
We also split the account profile information up into 4 sections:
We think this makes a good set of defaults, but you can choose to structure it differently, as makes sense for you.
3 - Smart forms
Finally, in order to split the account profile pages up into 4 sections, each of which allows the customer to update certain information, such as username and password on the Login details page or email address on the contact details page or shipping address on the shipping address page, we needed to allow our account form to accept whatever fields you choose to give it.
Our account form (see the documentation for details) will allow you to submit all the fields at once if you want to have one big form, or it will allow you to submit just one field - up to you. This means instead of having a Shipping Address section and a Billing Address section you could just have an Address section and let the customer update both addresses at once.
As we roll out more and more Liquid templates, we’re also working on more tools to make developing themes a better experience. The first step is our new Theme Importer that allows you to upload a whole theme into Salesforce. Your theme developers can create the bulk of it with their normal development tools, then zip it for upload and testing in your store.
To get started, download our core theme to see how a theme should be structured, and to see how we have implemented templates such as the new
pages/account template mentioned above. It is located at the bottom of this page.
Stripe ACH Payments
For our US customers, November ‘22 sees the introduction of Automated Clearing House (ACH) payments using Stripe. ACH payments allow customers to pay via pre-authorised direct debit from their bank. Needless to say, this is a slightly more complicated option than the traditional credit card option, however we were impressed by how seamless it is overall and it opens up new ways to allow your customers to pay.
This is available now for US customers taking payments from US customers. Review our documentation to get started.
Square Payments Upgrade
The new SDK supports all the previous options, and should make it easier for us to use newer features in the future.
That’s the round-up of new features in the StoreConnect November release.