Credit Card Surcharges can be your Secret Sauce

Getting your business online involves choosing an ecommerce platform like Spiffy Stores, but there are large number of features to consider when trying to make a choice between different platforms.

Credit Card Surcharges can be your Secret Sauce

In fact, for Australian merchants, there’s pretty much only one feature that really makes any difference!

Does your chosen platform fully support surcharges for credit cards and other payment methods?

I’ll explain why this is pretty important. Let’s say you accept payment by credit card or PayPal. For PayPal, you could be looking at having to pay up to 2.6% of the transaction as a merchant fee. Now this means that your net profit on the sale of an item is cut by this amount. If your ecommerce platform doesn’t support surcharges, then you need to increase the advertised price of the item by 2.6% to maintain your profit margin.

Now, considering that credit card surcharges are pretty well accepted as a normal cost for payment processing in Australia, there’s no real disadvantage to adding a surcharge at checkout time. This means that if you’re adding a surcharge, then you can decrease the advertised price of the item without suffering any loss in profits.

This turns out to be a secret advantage that you will have over your competitors. If all your competitors are using Shopify, then they don’t have the option of adding credit card surcharges. Shopify’s platform has been built for and is largely driven by the US market, where surcharges are often illegal. This means your competitors must increase their prices to cover the merchant fees, or suffer a loss in profits.

So for a Spiffy Stores platform merchant, the difference is clear. You can advertise the same item at a lower price than your competitor, without having to sacrifice any profit margin. As we all know, shopping on online has made it very easy to do price comparisons, so for the same item, the store that has the lowest advertised price will most likely pick up the sale.

And that’s it. By choosing Spiffy Stores your online business gets a head start on all your Shopify competitors without any loss of profits.

Spiffy Stores offers the ability to set credit card surcharge rates for individual credit card brands, and also for PayPal payments. It’s fairly likely that at some stage surcharges will be allowed for Buy Now, Pay Later schemes such as Afterpay, and we’ll be able to implement support for that almost immediately.

Spiffy Stores is an Australian-built and owned ecommerce platform that aims to fully support Australian merchants in a way that is lacking in most of the major global platforms. We’ll be adding new articles on a host of other features that can help you, as an Australian merchant, improve your sales and cut down the time and effort required to keep your store up and running. If you have any questions on how we support credit card surcharges, please contact us at support@spiffystores.com.au

Adding jQuery to Webpacker 6 under Rails 6

From time to time we post some notes about technical issues that we’ve encountered during our development work on Spiffy Stores. There are a lot of moving parts to manage, and sometimes we come across some tips or techniques that can help others to build their projects.

In this case, we’ve been looking at how to configure Webpacker 6 (currently Beta 7) under Rails 6.1, which acts as a wrapper to the latest version of Webpack 5. Now, as anyone who’s used Webpack since it was introduced as an option in Rails 5 will attest to, it’s not an easy package to get working properly.

The new versions of Webpacker and Webpack bring around some changes to the way things are configured, and unfortunately, some of the documentation is lacking, or indeed, wrong.

For our environment, we need jQuery as a starter. The trick with Webpack is to get the code loaded and assigned to the global variables, $ and jQuery. The trick with jQuery is to realize that the node modules version provides both a distributed module and also the source code which can be used to build the module with Webpack. If you just

require("jquery")

then you’ll get the pre-built module. It turns out that it’s better to build it from source instead.

If you’ve followed the migration documentation, you should have a custom.js under your webpack directory.

module.exports = {
   resolve: {
     alias: {
       jquery: 'jquery/src/jquery'
     }
   }
 }

Requiring jquery now, pulls in the source files instead, and this will build jQuery with the appropriate global references.

Another important “gotcha” with Webpacker 6 is that when you include the javascript_pack_tag in your layout, you MUST include it only once.

<%= javascript_pack_tag('application', 'common', 'customer', data: { turbolinks_track: :reload }) %>

Webpack builds a number of different file chunks for each entry point, and this means that the javascript_pack_tag will generate a number of <script> tags, one for each chunk. If you have multiple entry point files, then you must include them all on a single javascript_pack_tag and not create a separate tag for each entry point.

Unfortunately, coming from a Sprockets background, most Rails programmers will be used to creating multiple javascript_include_tags, but this is not the case for Webpacker.

If you happen to use multiple javascript_pack_tags, you’ll likely find that scripts may be loaded multiple times. In many cases, this may not be obvious, but if you see errors from @rails/ujs, then this is probably because it is being loaded multiple times by Webpack.