Swedish Swish can not scan barcodes on Xperia II

I have noticed that the Android swish application from aurora store can not scan barcodes on Xperia II.

I don’t know why. Is someone else in sweden pay using swish on any other device and got it to work?

I think it may be that the app select wrong camera or something (XperiaII has 3 back cameras) and I am not sure that dalvik engine support all cameras?

Any idea how to debug this or make it work would be nice?

1 Like

Ir’s just a guess, but I rember you can “Enable QR code recognition” via Settings / Apps / Camera. I hope this will help!

From F-Droid I installed “(SECUSO) Privacy Friendly QR-Scanner with minimal permissions”. This works fine on X10ii.

@mike7b4
I too have noticed this. But since you mention the phone model and number of cameras… are you saying it worked on another device?

My assumption is that they lean on Google Play Services for QR code scanning.
So without it, it will not work. But i have also noticed that it does not help to install microG, so i can only assume the implementation there is incomplete.

See API implementation status here.
Hint: it is called “vision”. Supposedly it should be complete for “barcode”, but which sounds like it means QR codes too.
My hypothesis for why BankID works is that they ship their own QR library, but i did not verify that.
I’ll do some more digging in the log and see if it sheds any light on things.

@jolla4ever, @rob_kouw

What does this have to do with Swish, the Swedish payment app?
Its QR codes are not swish:// urls, so it is not obvious that out-of-app QR code reading would help in any way.

Seems i guessed correctly:

08-03 19:44:40.910  2436  2436 W GmsDynamiteLoaderImpl: No such module known: com.google.android.gms.vision.dynamite.barcode
08-03 19:44:40.910  2436  2436 D GmsDynamiteLoaderImpl: unimplemented Method: getModuleVersion for com.google.android.gms.vision.dynamite.barcode
08-03 19:44:40.911  2436  2436 D GmsDynamiteLoaderImpl: createModuleContext for com.google.android.gms.vision.dynamite at version 1

And a google search leads me here:

Seems we are not alone. But the good news is they think it should have worked, so most of the implementation is hopefully there, just in need of some tweaks.

2 Likes

Having the same issue on my Xperia 10 III with microg.

BankID started to work when they ported it to huawei phones and they made their own implementation, before that BankID QR-codes didn’t work.
I haven’t got QR scanning to work with swish but one can scan the qr-code with the camera or another qr app and copy the code and edit out the number.
One can try QR-codes at https://www.swish.nu/skapa-qr-kod and they have a rather easy format. C<payee>;<amount>;<message>;<lock_mask> https://assets.ctfassets.net/zrqoyh8r449h/12uwjDy5xcCArc2ZeY5zbU/ce02e0321687bbb2aa5dbf5a50354ced/Guide-Swish-QR-code-design-specification_v1.7.2.pdf
The C isn’t always C it can be A or B but it’s always a capital letter.
Maybe something that only copy the payee could be useful?

As I mentioned in the thread about BankID, I was able to get scanning QR-codes with Swish working by installing Open GAPPS. So I guess that means those that want to be able to use this feature need to install Google.

For me it actually became a “must”, since there are PoS integrations (and Kustpilen only accepts Swish payments on their trains), that need QR-codes to connect the sale with the payment (I haven’t had time nor energy to try to scan the cise with another reader and transfer the info to Swish though).

1 Like

No test done on other SFOS phone. It was just a wild assumption. But as you say probably API differs from the one used in bankid and other working apps.

@Nille
I don’t think that is how the PoS codes work, or do you know?
Generally for that type you describe, one can always ask the merchant for the number, whereas in stores they look at you like you have three eyes.

Assuming that was before they fixed it; and yes, that should do it.

I see you also like to travel in style!
And please do complain to SJ (yes they run it nowadays) about this.
This should not be acceptable (and it is actually a bug).

I dont know what these PoS codes are but if i know where to find one then i can scan it.
I have seen some codes like A1234567890 that is only A<payee> for business.
I still think that something that scans and only copies payee could be useful since i can paste it into swish.

@Mohjive Could you scan some of those codes so the format can be known.

One example of a PoS code would be what Kustpilen shows you, or even some online stores with Swish payment (SJ possibly).
AFAIK these does not contain a payee, and consist only of something like a transaction id.
(But i could be misremembering, and don’t have any on hand).

So my point is just that (if true) in this case QR code reading is indispensable, but for what you describe it is “nice to have”. Just be careful to include messages if they look important when you dissect codes - some will be “the OCR number”.

Edit: and we should look at reconstructing both these types to swish:// urls if at all possible

I see that you are right there is a token and a callbackurl.
https://developer.swish.nu/documentation/guides/create-a-payment-request
https://developer.swish.nu/documentation/guides/trigger-the-swish-app
https://developer.swish.nu/documentation/guides/qr-codes-for-your-terminal
https://developer.swish.nu/api

It includes more than just a reference and a receiver number, as after a successful payment I’m being presented with a QR-code that the PoS terminal uses to verify my payment. I guess it’s a callback-url that generates this QR-code, as @Nille mentioned.

I don’t know next time I will travel with them, but I’ll try to scan it with a regular reader (or even take a photo), just to get the data out, before I scan it with Swish.

Otherwise someone could start a Swish payment at another merchant, e.g H&M or similar, just to get the code and then switch to card/cash to complete the payment.

If the QR code you mention is not in the Swish app itself, i think yes - but also that it varies from integrator to integrator.
If it is in-app there is no need for that.
The documentation more or less confirms that and says it is to call back to the invoking app (or presumably webpage), which would be what callback urls normally are used for.