12

The other day I made a few purchases using a mobile phone app (Android). I used Paypal, but this could be applied to any payment gateway actually.

Thing is, the application was just opening a "Window" or popup asking for the Paypal details. I trust this app and know I was actually being shown the Paypal website in the popup, but there was no way (or I didn't find one) I could really confirm I was using Paypal and not a mock/phising Window just asking for my Paypal username and password.

What do you think would be a wise way to show it's actually Paypal (or other payment gateways) when you don't have a standarized trustful browser bar which may show the URL and/or https status?

I'm evaluating doing a custom non-web application for the (typically online) web store I run and I was wondering what would be a good way to do this, or at least good enough so that users would trust it without necessarily trusting my application.

I know it can be done with the standard in-app purchases API (Google Checkout in the case of Android) which would use the system's account so you don't actually need to enter your username and password, but what to do for other payment gateways?

Improve this question
2
  • What mobile platforms are there that don't have a standarized trustful browser bar which may show the URL and/or https status?
    – Larivact
    Commented Sep 18, 2015 at 14:26
  • I believe Apple solves this by not allowing purchases through apps directly. So the solution would be to send people to the web browser to handle the transaction.
    – DA01
    Commented Sep 18, 2015 at 21:17

3 Answers 3

Reset to default
2

Great question, Jcl.

To your question...

... I'm evaluating doing a custom non-web application for the (typically online) web store I run and I was wondering what would be a good way to gain users trust without necessarily trusting my application.

The best UX I can think of is to allow your app users to pay with their phone (eg. iPay, or bill their mobile service provider, similar to in-app game purchases). To the user their account will be billed by a trusted source and for you, you don't have to worry about having buyers trust your choice of available payment methods.

On a side note ...

Why a popup?

I've spent hours and hours in security / UX / Dev meetings discussing exact same question several years ago. UX team was trying to improve UX of a payment process and was suggesting to eliminate PayPal popup / authentication process.

The reason why a browser popup / redirect to PayPal is used is because browser window shows the URL of a page (eg. xxxxx.paypal.com/yyyy) that URL acts as a trusted validation mechanic to buyers and merchants.

If a payment page uses any images / certificates / seals onto a page, those can be easily copied and added to a fake page. Same can easily be done with a page copy and links. Browser page address seems like the only item which can offer solid guarantee at this point as far as I know.

On mobile and tablet devices, it's much more difficult for a non-technical user to test validity of image URL's and so on.

Improve this answer
1

This is a security issue with all “In – app Purchase or Payment” method due to phishing attack.

Yahoo! uses a technique which is called “Sign in Seal”. Using that method, Yahoo! users create a seal (normally an image) which is stored in Yahoo! servers and is bound to a random generated token and that token is stored in a cookie on client side. This way when your app (either native app or web app) redirects user to the payment gateway web page, the page first checks if there is a seal associated with that client and it shows the seal to the user. This way user ensures that she is visiting a valid and real page (not a phishing page).

The problems with this method may be

  1. The mentioned method is patented by Yahoo! and I don’t know if using it infringes their patent rights
  2. Users must make a seal at the first visiting to PG page so you have to manage a way to warn users to pay attention to browser's address bar and SSL indicator at least for the first visit

I hope it helps you

Improve this answer
4
  • The sign-in seal as I understand it would not work. It either only requires the username (so a phshing site would only need to request the image seal to the real servers), or it'd require full login, so by the time you get the seal shown to you, you have already given your login information to the phishing site
    – Jcl
    Commented Mar 22, 2015 at 11:12
  • On a non-jail-broken or non-rooted device it is possible to use that method safely. Your app redirects user to a trusted browser (say safari for ex.) then user visits your trusted site. Your site drops a cookie in browser's sand-boxed storage and seal image is uploaded to the server. Well known browsers do not allow cross domain cookie access so malicious apps do not access to that cookie. You should pay attention to the fact that Sign in Seal does not pertinent to user's identity but to the device or client machine identity
    – anonim
    Commented Mar 22, 2015 at 12:41
  • Oh, I see... but then if it needs to go through the standard browser there's just no point, you could just send them to the gateway and users could see the URL and SSL certificate data... however that involves using the standard browser (i.e.: getting out of your app), which is what in-app purchases try to avoid.
    – Jcl
    Commented Mar 22, 2015 at 12:45
  • Well I said that in my answer. IMO there is no possible way of protecting In - app Payment methods against phishing attack as the domain does not switched between merchant and payment. take a look at this 3D Secure.
    – anonim
    Commented Mar 22, 2015 at 12:55
-2

Would it be possible to show a user's recent transaction or some other piece of personal info as a way to validate trust?

What if the payment processor displayed a simple message confirming that they are the real deal and that they have a record of your account? For example, a message saying:

Just so you know it's us, here's a recent transaction you made: 110016MANHATTANSTARBUCKS NYC for $6.39

or

Thanks for choosing ABC Bank. Did you know you've been with us for 3 years and 2 months? You first joined on November 20th, 2011!

If the goal is instill trust when users are transacting with your app, then we have to reduce the risk of having their financial info comprised and validate the relationship they have with their payment processor. Perhaps this could be a work around?

Improve this answer
1
  • 4
    The problem is that showing that information requires the user to be logged already, so it defies the point of trust before entering your login data. Once you have entered it, it's no problem.
    – Jcl
    Commented Jan 21, 2015 at 6:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.