Learn how switching to PWA helped MishiPay's business.
 Nikil Mathew [X](https://twitter.com/nikil_mathew) [LinkedIn](https://www.linkedin.com/in/nikilmat/)  Thomas Steiner [GitHub](https://github.com/tomayac) [LinkedIn](https://www.linkedin.com/in/thomassteinerlinkedin) [Mastodon](https://toot.cafe/@tomayac) [Bluesky](https://bsky.app/profile/tomayac.com) [Homepage](https://blog.tomayac.com/)
MishiPay empowers shoppers to scan and pay for their shopping with their smartphones, rather than
wasting time queuing at the checkout. With MishiPay's [Scan \& Go](https://mishipay.com/) technology,
shoppers can use their own phone to scan the barcode on items and pay for them, then leave
the store. Studies reveal that annually, in-store queuing
[costs the global retail sector $200 billion](https://www.chicagobooth.edu/review/secrets-wait-loss).
Our technology relies on device hardware capabilities such as GPS sensors and cameras that allow
users to locate MishiPay-enabled stores, scan item barcodes within the physical store, and then pay
using the digital payment method of their choice. The initial versions of our Scan \& Go technology
were platform-specific iOS and Android applications, and early adopters loved the technology. Read
on to learn how switching to a PWA increased transactions by 10 times and saved 2.5 years of
queuing!
10~×~
Increased transactions
2.5 years
Queuing saved
## Challenge
Users find our technology extremely helpful when waiting in a queue or check-out line, as it allows
them to skip the queue and have a smooth in-store experience. But the hassle of downloading an
Android or iOS application made users not choose our technology despite the value. It was a growing
challenge for MishiPay, and we needed to increase user adoption with a lower barrier of entry.
## Solution
Our efforts at building and launching the PWA helped us remove the installation hassle and
encouraged new users to try our technology inside a physical store, skip the queue, and have a
seamless shopping experience. Since the launch, we have seen a massive spike in user adoption with
our PWA compared to our platform-specific applications.
Side-by-side comparison of directly launching the PWA (left, faster) vs. installing and launching the Android app (right, slower).  The majority of all transactions happen on the web.
## Technical deep-dive
### Locating MishiPay enabled stores
To enable this feature, we rely on the
[`getCurrentPosition()`](https://developer.mozilla.org/docs/Web/API/Geolocation/getCurrentPosition)
API along with an IP-based fallback solution.
const geoOptions = {
timeout: 10 * 1000,
enableHighAccuracy: true,
maximumAge: 0,
};
window.navigator.geolocation.getCurrentPosition(
(position) => {
const cords = position.coords;
console.log(`Latitude : ${cords.latitude}`);
console.log(`Longitude : ${cords.longitude}`);
},
(error) => {
console.debug(`Error: ${error.code}:${error.message}`);
/**
* Invoke the IP based location services
* to fetch the latitude and longitude of the user.
*/
},
geoOptions,
);
This approach worked well in the earlier versions of the app, but was later
proven to be a huge pain point for MishiPay's users for the following reasons:
- Location inaccuracies in the IP-based fallback solutions.
- A growing listing of MishiPay-enabled stores per region requires users to scroll a list and identify the correct store.
- Users accidentally occasionally choose the wrong store, causing the purchases to be recorded incorrectly.
To address these issues, we embedded unique geolocated QR codes on the in-store displays for each
store. It paved the way for a faster onboarding experience. Users scan the geolocated QR
codes printed on marketing material present in the stores to access the Scan \& Go web application.
This way, they can avoid typing in the web address `mishipay.shop` to access the service.
In-store scanning experience using the PWA.
### Scanning products
A core feature in the MishiPay app is the barcode scanning as this empowers our users to scan their
own purchases and see the running total even before they would otherwise have reached a cash
register.
To build a scanning experience on the web, we have identified three core layers.
### Video stream
With the help of the
[`getUserMedia()`](https://developer.mozilla.org/docs/Web/API/MediaDevices/getUserMedia) method, we
can access the user's rear view camera with the constraints listed below. Invoking the method
automatically triggers a prompt for users to accept or deny access to their camera. Once we have
access to the video stream, we can relay it to a video element as shown below:
/**
* Video Stream Layer
* https://developer.mozilla.org/docs/Web/API/MediaDevices/getUserMedia
*/
const canvasEle = document.getElementById('canvas');
const videoEle = document.getElementById('videoElement');
const canvasCtx = canvasEle.getContext('2d');
fetchVideoStream();
function fetchVideoStream() {
let constraints = { video: { facingMode: 'environment' } };
if (navigator.mediaDevices !== undefined) {
navigator.mediaDevices
.getUserMedia(constraints)
.then((stream) => {
videoEle.srcObject = stream;
videoStream = stream;
videoEle.play();
// Initiate frame capture - Processing Layer.
})
.catch((error) => {
console.debug(error);
console.warn(`Failed to access the stream:${error.name}`);
});
} else {
console.warn(`getUserMedia API not supported!!`);
}
}
### Processing layer
For detecting a barcode in a given video stream, we need to periodically capture frames and transfer
them to the decoder layer. To capture a frame, we draw the streams from `VideoElement` onto
an `HTMLCanvasElement` using the
[`drawImage()`](https://developer.mozilla.org/docs/Web/API/CanvasRenderingContext2D/drawImage)
method of the [Canvas API](https://developer.mozilla.org/docs/Web/API/Canvas_API).
/**
* Processing Layer - Frame Capture
* https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/Manipulating_video_using_canvas
*/
async function captureFrames() {
if (videoEle.readyState === videoEle.HAVE_ENOUGH_DATA) {
const canvasHeight = (canvasEle.height = videoEle.videoHeight);
const canvasWidth = (canvasEle.width = videoEle.videoWidth);
canvasCtx.drawImage(videoEle, 0, 0, canvasWidth, canvasHeight);
// Transfer the `canvasEle` to the decoder for barcode detection.
const result = await decodeBarcode(canvasEle);
} else {
console.log('Video feed not available yet');
}
}
For advanced use cases, this layer also performs some pre-processing tasks such as cropping,
rotating, or converting to grayscale. These tasks can be CPU-intensive and result in the application
being unresponsive given that barcode scanning is a long-running operation. With the help of the
[OffscreenCanvas](https://developer.mozilla.org/docs/Web/API/OffscreenCanvas) API, we can offload
the CPU-intensive task to a web worker. On devices that support hardware graphics acceleration,
WebGL API and its
[`WebGL2RenderingContext`](https://developer.mozilla.org/docs/Web/API/WebGL2RenderingContext) can
optimize gains on the CPU-intensive pre-processing tasks.
### Decoder layer
The final layer is the decoder layer which is responsible for decoding barcodes from the frames
captured by the processing layer. Thanks to the
[Shape Detection API](https://developer.mozilla.org/docs/Web/API/Barcode_Detection_API) (which is
not yet available on all browsers) the browser itself decodes the barcode from an
`ImageBitmapSource`, which can be an `img` element, an SVG `image` element, a `video` element, a
`canvas` element, a `Blob` object, an `ImageData` object, or an `ImageBitmap` object.
/**
* Barcode Decoder with Shape Detection API
* https://web.dev/shape-detection/
*/
async function decodeBarcode(canvas) {
const formats = [
'aztec',
'code_128',
'code_39',
'code_93',
'codabar',
'data_matrix',
'ean_13',
'ean_8',
'itf',
'pdf417',
'qr_code',
'upc_a',
'upc_e',
];
const barcodeDetector = new window.BarcodeDetector({
formats,
});
try {
const barcodes = await barcodeDetector.detect(canvas);
console.log(barcodes);
return barcodes.length > 0 ? barcodes[0]['rawValue'] : undefined;
} catch (e) {
throw e;
}
}
For devices that don't support the Shape Detection API yet, we need a fallback solution to decode
the barcodes. The Shape Detection API exposes a
[`getSupportedFormats()`](https://developer.mozilla.org/docs/Web/API/BarcodeDetector/getSupportedFormats)
method which helps switch between the Shape Detection API and the fallback solution.
// Feature detection.
if (!('BarceodeDetector' in window)) {
return;
}
// Check supported barcode formats.
BarcodeDetector.getSupportedFormats()
.then((supportedFormats) => {
supportedFormats.forEach((format) => console.log(format));
});
### Fallback solution
Several open-source and enterprise scanning libraries are available that can be easily integrated
with any web application to implement scanning. Here are some of the libraries that MishiPay
recommend.
| Library Name | Type | Wasm Solution | Barcode Formats |
|---|---|---|---|
| [QuaggaJs](https://github.com/serratus/quaggaJS) | Open Source | No | 1D |
| [ZxingJs](https://github.com/zxing-js/library) | Open Source | No | 1D \& 2D (Limited) |
| [CodeCorp](https://codecorp.com/products) | Enterprise | Yes | 1D \& 2D |
| [Scandit](https://docs.scandit.com/stable/web/) | Enterprise | Yes | 1D \& 2D |
[Comparison of open-source and commercial barcode scanning libraries]
All these libraries are full-fledged SDKs that compose all the layers discussed. They also
expose interfaces to support various scanning operations. Depending on the barcode formats and
detection speed needed for the business case, a decision can be between Wasm and non-Wasm solutions.
Despite the overhead of requiring an additional resource (Wasm) to decode the barcode, Wasm
solutions outperform the non-Wasm solution in terms of accuracy.
[Scandit](https://docs.scandit.com/stable/web/) was our primary choice. It supports all barcode
formats required for our business use cases; it beats all the available open-source libraries in
scanning speed.
## Future of scanning
Once the Shape Detection API is fully supported by all major browsers, we could potentially have a
new HTML element `` that has the capabilities required for a barcode scanner. Engineering
at MishiPay believes there is a solid use case for the barcode scanning functionality to be a new
HTML element due to the growing number of open source and licensed libraries that are enabling
experiences such as Scan \& Go and many others.
## Conclusion
App fatigue is an issue that developers face when their products enter the market. Users often want
to understand the value that an application gives them before they download it. In a store, where
MishiPay saves shoppers' time and improves their experience, it's counterintuitive to wait for a
download before they can use an application. This is where our PWA helps.
By eliminating the barrier to entry, we have increased our transactions by 10
times and enabled our users to save 2.5 years of waiting in the queue.
## Acknowledgements
This article was reviewed by [Joe Medley](https://github.com/jpmedley).