I'm starting making an app for a website that I own. I know some about programming with xcode but there's a lot of stuff that I don't know yet. Mostly I have almost everything figured out for the app but I need to add to the app a way to sign in and sign up to the website and also a way to pay with credit card. I don't know how to start with all that.
I have tried to look some videos but I didn't see anything similar to what I want to do. I would really appreciate if you could explain me it, or send me some kind of help.
While I can't help you with sign-up/in features, I do know that ZooZ seems to be the cheapest and easiest way to accept credit card payments on mobile apps.
Both iOS and Android compatible, ZooZ's 3 lines of code monetizes your app in minutes. Users have their choice of checking out with credit cards or PayPal.
The biggest advantages of ZooZ are that your user always stays within your app and won't have to re-enter payment details in the future, resulting in faster processing and higher conversion rates.
Of course you can always build your own credit card processing platform, but considering the challenges of security, merchant accounts, and PCI compliance, it's probably not worth the headache.
Full disclosure: I have the privilege of working at ZooZ :)
Good luck with your app!
Related
I'm in the process of making an iOS app. This will be my first iOS app. It is based on making phone calls using calling cards. The customer will buy the calling cards in the real world and they will get a pin which they would need to enter in the app. Through this pin they will get the credit to make the calls.
I went through the submission guidelines. Usually when a app requires the user to buy something from with-in the app, then IAP is used but here the purchase is being made in the real world, without using the app. Do I need to integrate IAP into the app? Will Apple accept the app into the app store?
Any help is appreciated.
Thanks
As your requirement suggest
The customer will buy the calling cards in the real world and they will get a pin which they would need to enter in the app. Through this pin they will get the credit to make the calls.
It means you are dealing with somewhat physical stuff like customer will buy the calling cards in the real world so at that time he/she must have to pay something for that. so there is no need to integrate IAP in this scenario.
IAP is only for the stuff/service that will provide within the app by service provider. for physical service you can exclude the IAP. if you give proper description and explanation to apple when you submit your app for the review apple will definitely approve it
hope above answer will help you
I think you're in a grey area because it all depends if Apple thinks the credit is consumed in the app. If considered consumed in the app, you may have a problem. Try to find another iOS telephony app that uses cards, one that's well know enough to be sure that Apple may have had a good look.
If you'd give users game credit with physical cards, it's clear that Apple would not allow this.
What makes this a grey area is the telephony side: If it's a VoIP app you could argue that the the credit is (partly) consumed while using the app. But you could also argue it's outside the app on the VoIP/telephony network.
If it's not a massive investment, I'd try the calling card route first.
You could try ask Apple, but you'll probably won't get a clear answer as they want to see the app first. I've tried this a few times in the past. Makes sense because they don't want to make promised based on what you write in an email.
I am building out a iOS & Android app. My app may not fully scale to support users and have some limited functionality out the gates. I wanted to put an invite list on the front of registration like Mailbox did a few years ago.
I was trying to read the Apple app store guidelines to creating a "waiting list / invite list" and couldn't get a clear picture. I assume Android is more flexible on this, so I figured I could start with Apple's guidelines first.
Here is what I can find.
In Apple's docs, it says under 3.2.2 "UnAcceptable"
(v) Arbitrarily restricting who may use the app, such as by location or carrier.
In this specific case, I am not blocking by location or carrier. I am just putting up a wall to use the app since some of my users can use it in a limited form, but I can't open it up to everyone on Day 1.
I understand I can run a "testflight" release, but I wanted to make our app available in the App Store for anyone to download since it will be publicly available, just not fully ready for a million people to hit it. My understanding is that the testflight release requires a bit more work based on their docs and isn't as simple as just putting it in the public app store so anyone can get to it.
Apple has the ultimate authority for approving and rejecting apps in their app store so nothing on SO can really be perfect advice. If you are really concerned about approval, you can try to contact apple developers support. Here are a few things I would advise:
Make sure in the developer notes for Apple when you submit to them you include a free account.
In the notes for the app store let the users know that it may take up to __ hours for their registration to get activated.
My understanding is you are doing this to handle the volume of users as you are launching the app. Be advised though that if you start restricting users too much you will possibly get poor reviews. Only restrict usage if absolutely required. If you run into issues make sure you are communicating with the users so they understand.
Good luck with you new app!
All,I am making app for reminders & its kind of social reminders. I can share my reminders with my contacts. I want to make it like whatsapp. Can we use user's mobile number for this purpose? Or will apple reject it? Please tell me more, if anyone has done such app before?
Thanx.
You can ask user for any information, no matter how personal. In terms of Apple guidelines, here's a few things to bear in mind:
asking is fine, but taking (via a hack or whatever) will get you bounced.
the ask has to be essential to the service the app delivers. in other words, it's perfectly okay for a retirement calculator to ask about how much money user has in the bank, but not so okay for a tic-tac-toe app.
editorially, be very clear and honest about how you'll use the information (Apple might not catch you here, but you should do this anyway to motivate the user's answer).
the app must remain functional even if the user opts not to provide the information. for example, the retirement calculator should supply a default bank balance and carry on.
I'm building an app that registers people for an event and charges them a registration fee. I've got most of it built but I'm having trouble actually charging them. I've read the guidelines and don't want to use apple's in-app purchase method because they charge a big fee and the goods being purchased aren't digital or for in-app use.
I've looked at doing paypal and I think that should work fine for me, I've already started playing around with their sdk and sandbox. However, I would also like the ability to charge a credit card. I found card.io that looks like it works really well but that just gets me the card information, it doesn't give me a way to actually process a transaction. Also, I know there are card readers like Square out there but I'd like to do everything in my app, not need the user to switch out to a processing service. Any ideas on how I can make this work? Thanks!
If you use a service like Balanced or Stripe you can tokenize your card info straight from the phone, this will save you having to process it via your server which keeps the PCI hassle low. These services are only for tokenizing and charging cards, if you're looking for a way to capture card info e.g. scanning or swiping the card, then a service like card.io or Square is what you want.
If you don't want to get the assle of the PCI-DSS certification you could use Braintree in combination with card.io.
Braintree offer an ios sdk so it won't even hit your server. (See https://www.braintreepayments.com/mobile-payment-processing.)
Card.io just let youscan the card, but when youget the card info back youcould push it to the braintree api.
Since what you are selling is a "service" you don't need to use the Apple in-app service.
You might look at the newly released PayPal iOS SDK.
Looks like you're looking for a Square solution but in your own app. You might want to check out CardFlight (https://getcardflight.com), as they provide the hardware and an SDK so that you can process payments within your own app. They work with your processor so you can still use Braintree to process the payments.
Full disclosure: I am currently working on this. We realized that there was a huge opportunity to provide the software and hardware so that people can accept physical card payments within their own app.
So I've spent a lot of time making an iPhone game and have recently realized that I don't have to limit myself to just Apple - I know there are app stores for Palm and Android, but does anybody know of a good "app store" for the plain old PC? I would like to have one where individual developers can publish an app and not have to worry about all the billing and piracy issues!
Valve has Steam, although that's a bit of a game store. It comes with DRM so it might be what you want. http://store.steampowered.com/
From what I can see, their website has an email to coontact them about distribution and that's it. steamworks#valvesoftware.com
Stardock has Impulse, which is more of a general app store although it does have games as well. No DRM baked in, and it has a very liberal return policy. http://www.impulsedriven.com/
Impulse has a page with more info and a contact form - https://developer.impulsedriven.com/#publishing
The page states the base rate is 70% which is likely more than Steam gives you.