In-app purchases for a web shop

We’re planning to write an app with a Shopping Basket and Checkout. This leaves the Payment.

We’ve come up with a few options, but I’d like to check with you whether they are viable, and if you have experience with this and could suggest something Corona-compatible. Listed in order of preference:

  1. In-app purchase for the respective app store. Will this require native code, and will the app stores take a cut of the sales?

  2. Klarna on Demand has native IOS and Android sources. Is it easy to turn them into a plugin? Will we need an upgraded Corona plan?

  3. They also have a web API. Is native Web View support good enough today that we could keep the user in the app and run a web app that we write? This type of web app would likely be more complex than, you know, “a normal website with some Javascript and responsive design”.

  4. In checkout, the user taps a button that opens a normal web-based checkout in the default browser on the device.

Which option is the least hassle and most reliable? We would listen to better suggestions that in your experience are preferable.

In-app purchases from Apple, Google and Amazon are for virtual goods:  Coins, Gems, monthly subscriptions to premium content etc. If you’re selling tee-shirts, you would not use Apple, Google or Amazon’s IAP for that. You would use your own payment system like PayPal, Stripe, etc. The app stores are out of the equation. If you’re selling virtual goods, you must use the store’s system and they take 30%.

If you use IAP, there are plugins for SDK users, so no Enterprise is required.

I don’t know what Klama on Demand is. If they have iOS and Android SDK, you would need Corona Enterprise to link their SDK’s to your app. You don’t have to make it a plugin, though it might be easier. I can’t say how easy it would be. If you look at something like Google Play Games Services, there are hundreds of API endpoints that needs implemented. You look at another service like Stathat, and they have three functions that need supported. I can’t predict what other issues you might run into. 

When I hear “Web API” that means that you can use our network.request() API to access the service and probably wouldn’t need a webView. On the other hand, it may just be easier to throw a webView up. (Your #4

Rob

Thanks for your thoughts Rob. Physical goods, so 1 is out. Web view was my #3 - we abandoned Web views 3 years ago because they weren’t full web browsers - some feature support missing. I was mostly asking to check if this has improved on both platforms; you can ignore this question. Some payment services do require a redirect to their site and back again, but I’m with you on the last point. We’ll likely be able to use their REST API, perhaps some key for transactions must be encrypted at the client but I haven’t found out from a quick look at their documentation.

I’ve done exactly what you are trying to do with an app.  Basically the entire app runs in Corona through a webView and all the normal payment gateway stuff - like PayPal, credit card gateways works just fine.  I wrote this for my company (aka my day job) and that uses Global Payments (HSBC) and PayPal just fine.  Simply design your app as a website and when you have that working you run that through a full screen webView in Corona and you have a mobile ecom app.

Your only charges are from your payment gateway - this should be around 1.5% of the transaction value.

In-app purchases from Apple, Google and Amazon are for virtual goods:  Coins, Gems, monthly subscriptions to premium content etc. If you’re selling tee-shirts, you would not use Apple, Google or Amazon’s IAP for that. You would use your own payment system like PayPal, Stripe, etc. The app stores are out of the equation. If you’re selling virtual goods, you must use the store’s system and they take 30%.

If you use IAP, there are plugins for SDK users, so no Enterprise is required.

I don’t know what Klama on Demand is. If they have iOS and Android SDK, you would need Corona Enterprise to link their SDK’s to your app. You don’t have to make it a plugin, though it might be easier. I can’t say how easy it would be. If you look at something like Google Play Games Services, there are hundreds of API endpoints that needs implemented. You look at another service like Stathat, and they have three functions that need supported. I can’t predict what other issues you might run into. 

When I hear “Web API” that means that you can use our network.request() API to access the service and probably wouldn’t need a webView. On the other hand, it may just be easier to throw a webView up. (Your #4

Rob

Thanks for your thoughts Rob. Physical goods, so 1 is out. Web view was my #3 - we abandoned Web views 3 years ago because they weren’t full web browsers - some feature support missing. I was mostly asking to check if this has improved on both platforms; you can ignore this question. Some payment services do require a redirect to their site and back again, but I’m with you on the last point. We’ll likely be able to use their REST API, perhaps some key for transactions must be encrypted at the client but I haven’t found out from a quick look at their documentation.

I’ve done exactly what you are trying to do with an app.  Basically the entire app runs in Corona through a webView and all the normal payment gateway stuff - like PayPal, credit card gateways works just fine.  I wrote this for my company (aka my day job) and that uses Global Payments (HSBC) and PayPal just fine.  Simply design your app as a website and when you have that working you run that through a full screen webView in Corona and you have a mobile ecom app.

Your only charges are from your payment gateway - this should be around 1.5% of the transaction value.