As we work to streamline our services and bring as much under one roof as possible, we are making changes to who we contract for processing our credit/debt payments for our website and for in-person sales.
Change is in name only, Stripe is still the backbone
Since our inception, we have used Stripe as our primary online payment gateway. We dealt directly with them for functionality, reporting and all processing of payments and refunds.
Our eCommerce platform, WooCommerce, has been a partner with Stripe all along. Stripe is the leading eCommerce payment platform and the most secure gateway out there. Their fraud detection is exceptional and a standard all others need to follow. Although we are making a change in “branding” to our payment processor, Stripe is still the entity performing all the heavy lifting; including execution of security measures. Our new service is merely a means to better integrate Stripe into our website and offer a fuller suite of possibilities. One of those possibilities is allowing Stripe to handle our In Person payments as well.
Formerly, we had to rely upon Square to handle all in person sales. Until last summer, that meant having an entire layout and storefront just for use with Square. Using Square as an integrated payment gateway within our website led to numerous stability issues and created havoc with our inventory handling. Square was great, but not awesome; only being ideal for in person transactions. Running two systems that did not share the same inventory led to problems. It was possible to sell the last item in person to then also have someone buy it online. Some items cannot be made overnight, leaving us in a position to either refund the customer or tell them it will be a couple extra days to get their order. These are things we don’t like having to do and can quickly lead to an upset customer and bad reviews.
Last year we started using Square as only the means to take payment in person, while still processing the order through a “register” web module attached to our eCommerce inventory. This allowed a sale to be completed in person that would take the items out of a single master inventory. This process was not smooth, was clunky at start but in time we learned how to maximize efficiency. The problem arose at Tax time. The payments we accepted through Square were inclusive of Sales Tax as we only took the total from the register to enter into Square for payment and not the before tax sub total and allow Square to apply the appropriate tax. This was an oversight on our part but led to issues reporting income as Square reported to the IRS that no sales tax was collected; meaning everything was 100% taxable revenue. Those with an understanding of Income Tax filing will see how this is problematic.
Online vs Point of Sale; Why are they so different?
Our online sales and payment processing is flawless and works as it should. Protecting us both from fraud and keeping your data safe. The fees we pay are standard and all we need to do is run a report at the end of the month to match up with our orders to make sure all is good. Point of Sale is the problem. By its nature, it is open to more points that can compromise security. The coding needed to build in the necessary security comes at a price and is priced for much larger businesses; out of our affordability. This reasoning is why Square came into being. Square is a very proprietary system that doesn’t want to play nice with others; especially WooCommerce. This leaves us with few affordable options for in person payment processing. Stripe has worked it all out, but it is not something we can incorporate into our eCommerce system without hiring a programmer and we risk what conflicts can arise with other functions of our system. One little variable can throw a wrench into the system and shut is down until we find the cause.
Mobility is essential for our needs
Many of the in person payment services available to us work as an additional gateway to Stripe (or Square) to increase stability and security. These services come with additional fees on top of the fees we already pay to Stripe. Then with us relying upon mobile data and not a wired LAN in a fixed location ramps up the costs and limits what devices we can use. Over the last 2 years we have seen this improve, but not well enough to be able to incorporate payment processing into our POS system when we are at an outdoor event. If we were smaller, then we could use Square with some headache, if we were bigger there would be no headache at all but we pay more.
To get the best option possible for us requires us to add the “go-between” of our eCommerce system provider for all payment processing. All credit and debit cards will be processed by Stripe, we just see the reporting in a new way inside our Admin pages. The benefit to us, and why we are making this adjustment, is that we can accept in person payments remotely using Stripe as the payment processor for orders created within our POS. The downside is that we still need to enter the payment portion into another device/application.
What will this look like to an in person customer?
As before, the customer will shop and bring all their items to checkout. We will then manually, for now, type in all those items into our register running on a Chromebook. In the future we are looking to add barcodes so we can scan all the items at checkout. Being that our register is physical version of our online store, we can also look up registered customers to allow them use stored coupons or Primp + JÖL Club discounts. Once the order is created and placed into a “awaiting payment” status, we then pull out a phone and with an app that extends the administration capabilities of our website we retrieve the pending payment order. Once it pops up, we can click to apply payment and allow you to insert or tap your card to finalize payment. Once payment is authorized, the order will change to paid and we can complete your order. If you are a registered customer, you will be able to look up this order with all other orders. We can also process gift card sales, subscription sales (when we reactivate them). As all of this is fully tied to our eCommerce system, it is all interconnected with in the moment ability to manage everything. We will have more insight into why a card was declined and we can confirm if a payment had any errors – like being double charged.
We will still be able to support online wallets, like Google Pay, Samsung Pay and Apple Pay. And we can still accept cash.
Our hopes are that with further development of the ecosystem we work within will fully incorporate the functionality into the POS register without any unnecessary fees or hardware. Thankfully the Chromebook allows many Android apps to run natively, it is up to the developers to allow their apps on Chrome OS – looking at you Square! There is no difference in the level of security threats between iOS, Android and Chrome OS when it comes to these apps.
We plan to take our site down for 24 hours Between May 31st into June 1st. During this time we won’t be able to accept any online orders. Ordinarily adding another payment processor does not require the deactivation of another as both can operate as a choice for customers to select. In this case since we are replacing one version of the same thing with another, and we wish to tie reporting to a new month, we are going to deactivate Stripe to activate Woo Payments by Stripe. Plus we have a festival coming up just days later.
Once the conversion is complete, checkout on our website will look no different as it is still Stripe at the core.
If you have any concerns or questions, please reach out to us via our support @ pogonotrophics.com address.