I am working with a 3rd party web service to process credit card payments.
When I swipe a credit card via google chrome the payment is detected and processed.
However when I attempt to swipe a credit card via the built in Delphi web browser TChromium, nothing happens.
Can't figure out why its not working are their any settings I need to set on the TChromium browser?
Update
I have verified that that the card reader reads and posts the data to whatever field/component is selected.
One difference I have found with Chrome and the TChromium web browser is that when I process a card in the TChromium web browser it automatically tabs to the next html component after processing the card.. Where this does not happen in Chrome it just stays with the current field/component selected.
The Question title is misleading but only because I did not understand what was happening after some investigation I was able to solve the problem. I hope this answer might come in Handy for someone someday though its a pretty isolated problem.
So I found that the MagTek reader reads the credit card data to the field and then Sends a "Enter" button afterwards.
And the Program I am currently working with has an option where when a Enter Key is pushed it will instead send a Tab so that a user can get to the next fields by the enter key.
So the program was intercepting the MagTek reader initiated enter key and replacing it with a tab which interfered with the payment process.
Related
I have an electron app built, it is basically a form.
When a user clicks finish on the form, their details get registered remotely but it is also essential that an A4 printout of the electron app screen gets sent to the default computer.
Is this at all possible with electron, I imagined it would work the same way as simply clicking ctrl+p on chrome but it doesnt work
Yes, It's possible, Check the following:
https://github.com/tojocky/node-printer
So the usual flow for magic link is:
User clicks on the link in their email (e.g. www.domain.com/auth/:token)
Page is opened in the email’s in-app browser.
Token is stored in the in-app browser’s local storage and token is removed from the URL (either by redirection or some other method).
User is logged-in (in the in-app browser).
The problem happens if the user then clicks the “Open this app in Safari” (or another browser) in a mobile's in-app browser. The user will be logged-out since the local storage state is not carried over and the token was already removed from URL parameter. Unless the token is present as a query / parameter on every page URL which is unsecure and defeats the purpose of using local storage.
What is the best solution for this use case without providing a typical login flow (username/pw)? (Or is that the only way?) Seems like you cannot browse any app in iOS using a magic link via an actual browser app since the magic link will always come from your email app (and hence, will always be opened using the in-app browser).
To use a magic link in order to open your App from an anchor clicked into an email client, you need definitely to setup Universal Links.
That said, things are not always that simple. In some circumstances Universal Links won't work and will open directly into some in-app browsers instead opening your app, this occurs sometimes with the SafariViewController embedded into email clients as you noticed.
So what to do to make it work in all cases?
As you know an Universal Link should open your app if it is installed, but it should also open a fallback web-page in any other circumstances when your app cannot be opened. This is where you will make it bulletproof: on the fallback web-page make sure you put an obvious button with a "safety" second/backup Universal Link that will do the exact same action into your app.
It will work because if your Universal Link fails to open directly from the email client and opens a browser window by mistake, it will most probably open your app when triggered from the in-app browser fallback web-page.
At the end, you might want to focus and put an extra effort to setup a very nice design for your fallback web page, making it look like your app, to provide a good UX so that your users may not even notice that they went thru an extra-step…
I'm in the same boat with our webapp's passwordless login authentication. Did you end up using Universal Links to successfully overcome the issue?
I was wondering if there was any way to have a Credit Card reader connected to an iOS device, and when swiping a card, pre-fill a form in the browser. Basically have the Card reader act as a Keyboard and with some Javascript on the page, fill the right info in the right fields in the current page. I'm looking to do this purely on a Web Page with Safari.
Thank you!
I don't think you're going to be able to do this from Safari on iOS. Safari would have to support this feature, which it does not.
Instead, you could create your own app that interfaces with a credit card reader and uses a web view as a mock Internet browser. You can interact with the content of a web view via stringByEvaluatingJavaScriptFromString:.
i have a web app on html5 and running on a single page, lots of Ajax and javascript, so everything takes place on a single page.
Payment takes place with paypal digital good express which on desktop opens on the same tab without opening a separate page. It all works great on desktop, running all on 1 single html5 page.
On iPAD the problem is that paypal digital goods express opens on a separate tab. And i need to find a way to communicate after payment with the previous tab where the app is running.
Because after successful payment the single page web app immediately runs a new key process.
On iPAD i cannot start that process because paypal opens on a separate tab and once payment completes successfully there , i dont know how to send a signal to the javascript code of the previous tab.
I guess the main tab of the web app could be polling the server for news, but that seems rather inefficient considering how easy it is on desktop
i appreciate very much any help :)
I've got (actually my employer has) a mobile website that enables Safari integration (for iPhones and iPads) - meaning that customers can bookmark it to their home screen and then it would behave as a standalone web app (no address bar, custom icon, start-up image etc).
It works all right except that one week ago (coincidentally soon after apple has released iOS 6.1.2) some of our customers (6 of them initially) complained that they no longer get the normal content but a '404 page' of a public wifi provider (The Cloud owned by Sky here in the UK). After a bit of investigation we've figured that at some point those customers connected to the Cloud wifi without actually logging in (it's one of those providers that would redirect you to a login page to enter your credentials, after which you can carry on browsing). The thing is that even after switching back to their private wifi or mobile data connection the application would display the Cloud's page.
This only happens (as far as I can tell) when the application is launched via the bookmark (I couldn't see this behavior when using it from safari).
What happens is that the customers would connect to the cloud wifi (without logging in), they would open the application at which point the router will issue a redirect response to their login page; the application would cache the login page and it will always display it whenever using the bookmark again. (I've performed a capture when this happens and there are no requests being made at start-up whatsoever).
Even weirder, in this situation, if removing the existing bookmark and adding a new one will show you the same cached page (with the whole operation being performed away from the Cloud). We've fixed this by adding a unique identifier to the URL each time we hit the bookmark screen (this indicates that the web apps' sandboxes are linked to the url, which is to be expected).
What we're trying to achieve is to have the application properly recovering after the customer has moved away from the Cloud. But there doesn't seem to be a straight forward way to do this.
Furthermore there's a level of inconsistency in all of this - most of the times when the flow is performed I will see a 404 page (a custom 404 page https://service.thecloud.net/service-platform), but sometimes I would be properly redirected to the login page, in which case the application would not break.
My assumption is that there is a weird race condition in the standalone web app application model causing the browser not to properly handle redirects (and actually caching 404 pages). I've raised a support incident with Apple (which eventually turned into a bug report) but it might take a while and I'm trying my best to figure out a workaround.
Any ideas, maybe someone has seen this before?
The issue is aggravated by the fact that I need to have a 5 minutes walk ever time I'm testing any fixes; I've tried creating simple test forms, but I wasn't able to reproduce the issue, where as with the full app I can do it pretty much every time.
Here's a summary of the steps to reproduce:
Via private wifi (or mobile data connection) add a bookmark to a website (I've managed to reproduce it with quite a couple of apps that support safari integration as described above)
Open the application to review the normal content
Connect to a Cloud hotspot and open the application from the bookmark (open-close it for a couple of times if you don't get the 404 right away)
Connect to the private wifi (or mobile data connection) and open the application via the bookmark -> you'll see the same 404 page again
In the end the fix was to add a unique query string parameter with the initial page request (pretty easy with the setup we already had, via the launcher page). I've filed a bug report with Apple which they've acknowledged by linking it to a previous item. Here's a post on the topic:
http://blog.onos.ro/ios-6.1.2-caching-issue