Scanner API - invalid barcode scans on certain iPad models

Extensions
1

Hi there,

We’re working with a merchant that’s having issues with the Scanner API. The problem is that the Scanner API is returning incorrect data from a PDF417 barcode on their iPad Pro running Shopify POS and our POS Extension.

We worked with them to troubleshoot the issue, they have the latest version of the Shopify POS app (9.30.2) and the latest version of iOS (18.3.2) on an iPad Pro.

We record the raw data from the Scanner API and can definitely confirm that the data scanned from the barcode is incomplete, only showing a 13 digit number instead of the complete embedded text.

We tested on our own iPad Air (5th generation) with the same exact software versions for the Shopify POS app, iOS version and our extension - but we were not able to recreate the problem.

Additionally, the merchant tested on a different iPad device that’s on iOS v15, and the Scanner API worked as expected.

In all cases, the iPad’s embedded camera is used, not a handheld scanner.

We’re asking for the exact iPad model from the merchant, and will share once we have it.

2

@Victor_Chu are there any restrictions with PDF417 support with the Scanner API?

3

@Dylan Not that I know of, this is the first report that I’ve run into. Could you please provide the iPad model once you have it? This could be handy in finding more information.

Victor

4

Thanks for getting back to me @Victor_Chu

Unfortunately getting even that detail from merchants is difficult, I’ve shared step by step screenshots on how to find it but haven’t heard word back.

Another case has popped up with other store. Is there any other information I can share? Is there a UUID I can somehow retrieve from the Scanner API for a specific scan?

5

Hey @Dylan I’ve seen this as well :slight_smile:

Guy was using POS Go barcode scanner which worked fine, but was trying to use iOS device and that was never scanning. His barcodes we correct and matched Shopify.
I added some logging and discovered the iPhone was always prefixing the barcode with a 0.
After much digging

A UPC-A symbol that is created in the United States can be transformed into an EAN-13 symbol by prefixing it with a zero.

6

Thanks for sharing that example @JordanFinners it’s comforting to hear I’m not the only one seeing issues with the POS Scanner.

My case isn’t exactly the same, because it’s a different barcode format and a huge amount of data is missing but it definitely rhymes.

@Victor_Chu is there another UUID or identifier that is sent per scan we can share with you from a given scan to help communicate the exact cases?

7

If you’ve got a photo of the barcode, happy to take a look at it :blush:

8

@Victor_Chu

Another merchant with this issue trying two different devices:

iPhone

  • iOS Version: 18.4.1
  • Model Name: iPhone 16 Pro
  • Model Number: MYMG3LL/A

iPad

  • iOS Version: 17.5.1
  • Model Name iPad: (9th generation)
  • Model Number: MK2K3LL/A

In all cases the raw data from the Scanner API on a PDF417 is inaccurate and limited to < 18 characters.

9

@Dylan Thank you for your patience and additional information on the issue at hand. I have never run into this issue myself but I’ve sent out a question to the device team to see if they know anything more. I’ll keep you updated if anything comes up.

10

I am unable to reproduce on

  • iPad (9th Gen), v18.4.1
  • POS v 10.1.0

What api version is your extension running? @Dylan

11

Also has the problematic merchants been able to scan other barcodes? Or is it specifically these PDF417 ones?

12

Thanks for getting back to me @Victor_Chu

The extension is running on the 2024-10 API version.

I’m able to reproduce the issue with a publicly available sample NV drivers license: https://media.lasvegassun.com/media/img/photos/2008/10/21/scaled.GVDMV1023b_t650.jpg?5711a3b57decb389a12ba40e20471e031ff69545

The Shopify staffer that I also spoke with had this issue with his MN issued drivers license as well.

I have noticed that both NV and MN licenses feature two barcodes, I wonder if the scanner is picking up the smaller one instead of the primary PDF417 barcode.

13

Just to confirm when you state that you can reproduce, you are referring to the PDF417 one in that example?

14

Correct, that’s the example I’m referring to that is showing the problem.

Since this is a publicly available sample, and it’s clearly mock data I’m comfortable sharing it.

Most of the time, when I scan that sample, the raw scanning data is:

12345678900000000000

That shorter string is the problem. That isn’t the correct data.

Occasionally, I’ll see the correct scan which contains much more information:

@

ANSI 636049030002DL00410466ZN05070057DLDCABCDE
DCBBCDEFJKLMW
DCDHLPT 
DBA00000000
DCSLASTNAME                                
DCTFIRSTNAME                                                                       
DBD00000000
DBB00000000
DBC1
DAYAAA
DAU      
DAG123 ABCDEF DRIVE                   
DAHAPT. 00                            
DAIANYTOWN             
DAJNV
DAK123450000  
DAQ123456789123             
DCE 
DCF0000000000000012345671234
DCGUSA
DCHNONE
DCK                         
DAZABC
DCU     

ZNZNAORGAN DONOR
ZNBREVISION DATE00000000
ZNC603
ZND180
15

Thanks for confirming, @Dylan. It seems the camera scanner is working as expected, but it’s prioritizing the smaller barcode instead of the PDF417 barcode.

This aligns with your previous statement:

“I have noticed that both NV and MN licenses feature two barcodes. I wonder if the scanner is picking up the smaller one instead of the primary PDF417 barcode.”

16

Thanks @Victor_Chu .

As an app developer, I don’t have any control over which barcode is scanned first. I can only subscribe to the API.

In the short term, is there any kind of workaround possible?

In the long term, can we expect any kind of changes to the scanning API to support this use case?

17

In the short term, I recommend advising merchants to ensure only one barcode is visible within the camera view at any given time. Additionally, if your implementation allows, adjusting or reducing the size of the camera view could help merchants more easily frame a single barcode, minimizing the chance of multiple barcodes being scanned simultaneously.

In the long term, while we can’t promise specific changes at this time, we understand the importance of this use case and will keep it in consideration as we evaluate future improvements to the scanning API.

18

Thanks @Victor_Chu

In the short term, I recommend advising merchants to ensure only one barcode is visible within the camera view at any given time.

I understand, but also please consider how close together these two barcodes are. They’re millimeters apart.

You cannot even position the ID in frame of the camera without showing both.

It’s not possible for a merchant to not include both barcodes in the current Shopify POS scanning implementation.

CleanShot 2025-05-06 at 07.16.01@2x
CleanShot 2025-05-06 at 07.16.01@2x1306×858 79.9 KB

Additionally, if your implementation allows, adjusting or reducing the size of the camera view could help merchants more easily frame a single barcode, minimizing the chance of multiple barcodes being scanned simultaneously.

The Scanner API doesn’t allow any customization of the camera zoom/panning etc as far as I’m aware.

Are you referring to some other API or setting that’s outside of the extension’s code?

In the long term, while we can’t promise specific changes at this time, we understand the importance of this use case and will keep it in consideration as we evaluate future improvements to the scanning API.

Alternatively please consider supporting a camera API with direct access to the camera’s feed.

Then we can apply our own logic to ignore the secondary barcode.

19

Can you check the scan data on the subscription in POS? :thinking:
I’ve had to do this because one of my customers has a URL barcode next to the normal one, so I check the data doesn’t contain https:// otherwise try look it up.
Not sure if theres a regex or something you could use for your use case? :thinking:

20

@Victor_Chu

When the merchant covers the smaller barcode, then the POS Scanner API never actually triggers a read out.

I have a video from the merchant that shows the problem I can share privately, how can I get it to you?

@JordanFinners the problem isn’t that there’s extraneous data to filter out, it’s that the wrong data is read from the Scanner API. There’s no amount of regex that can help with this unfortunately.