Things to Know When Building an Ecommerce Mobile Web App
Our team at 201 Created recently built a best-in-class mobile web app to see how far we could push the boundaries of cutting-edge browser APIs and have our web app achieve feature parity with a similar native app. You can try it out; it sells stickers: www.shop-201.com (best viewed on a mobile browser like mobile Safari).
If you are interested in accepting payments on the mobile web, the following lessons may be useful to you.
Your site must be served securely via https
This should be obvious. Apple Pay, the PaymentRequest API, and payment processors like Stripe will all refuse to operate when run from an insecure domain.
Luckily it’s very easy to set up your own TLS certificate for free with LetsEncrypt. If you’re using Ember or Rails (like we did), here are some notes on serving those locally via TLS, which is necessary if you want to make test payments locally.
Apple Pay goes nicely with a helping of Stripe
Stripe’s Apple Pay on the web documentation is great, and a darn sight simpler than Apple’s Apple Pay on the web documentation.
There are a few other Apple Pay-related gotchas to look out for, however:
Gotchas regarding creating a Sandbox Tester (Step 1 of Stripe’s Docs)
Stripe doesn’t tell you this, but in order to create a usable Sandbox Tester (part of the Step 1 steps in Stripe’s docs), you need to do two things:
- Verify the user’s email. (Even though this is a test user you’ll need to give them a real email — and then you’ll need to check their email account and click the verify link that Apple emails to you)
- Visit icloud.com and sign is as the test user so that you can accept the Payment terms of service (it will be presented to you after logging in).
If you don’t follow those two steps the login process on your iDevice will fail in odd ways (either telling you the login info is incorrect, or putting you into a “you must update your password” infinite loop).
At this point you have a usable Sandbox Tester that should be usable to to log into iCloud on XCode’s iOS Simulator with. Another gotcha: Stripe suggests adding a test credit card, but you cannot do this on the simulator. It will seem tantalizingly possible, but neither test credit card nor real credit card will be accepted by the simulator, so don’t bother (and it doesn’t matter if you attempt to add the card via the Wallet or via the iCloud screen — both ways won’t work).
If you’re using your own iDevice for testing and have seen the dire warnings about data loss when signing out of iCloud, but have thrown caution to the winds and signed out anyway so that you can sign in with the test card, good for you! You will be able to add a test credit card.
Testing on the iOS simulator will work if you are using your Stripe test keys, although you’ll get this somewhat unsatisfying “Pay with passcode” option instead of the fingerprint icon.
If you attempt to make a real payment when logged into a sandbox tester iCloud, you’ll see this message:
iOS Add To Home Screen Caveats
Luckily no one really uses the “add to home screen” functionality in iOS, but if you do, there are a few gotchas to be aware of.
Firstly, Apple Pay isn’t available if you run the app from the home screen. This is either a problem with the code Stripe provides to detect Apple Pay availability, or simply a lack of that API being provided by the frame that runs the app. Either way, this is a good place to use Stripe’s simple checkout code instead.
Secondly, Stripe’s checkout has a nifty 2FA modal that pops up with 6 blank spaces for you to type in the 2FA code that they SMS you when you attempt to make a purchase. Unfortunately, after switching away from the home-screened app to iMessage and back, the modal will have disappeared. Stripe suggests using the lower-level Stripe payment APIs instead of their Checkout.js for this case.
Android Pay is a “potemkin village”
Even though Google’s own documentation about using the PaymentRequest API on the web shows demo code that uses Stripe as the gateway token provider, Stripe has confirmed that this code will not work in production. They suggest that support is “in the works” but no ETA has been provided. However, the test code they show does work, in case you are planning on building a business around people pretending to pay you.
We’ve reached out to Braintree support as well and have conflicting reports about whether the same gateway token approach can be made to work on with Braintree.
All in all, it’s clear that although there is definite work being put in by both the Android team and payment providers, there’s still a gap between expectation and reality. It seems quite likely that one day (soon?) you will be able to accept Android Pay payments on the web, but today does not appear to be that day. If you have it figured out, or know of a site that does this today, please let me know!
Want to learn more about 201 Created? Follow us on twitter or send an email to hello@201-created.com.
