We have created an iOS app for short rental owners with the objective of holding rental deposits on a credit card during a few days. The user can decide to capture the payment if there is something broken in the flat.
This app has been made with Stripe.
We encounter the following issue: when the user enters his client's credit card in the app for holding a deposit of about 300€ for exemple, Stripe doesn't accept to continue the operation without 3D Secure verification.
While in the same time, it works perfectly without 3D Secure when doing this operation on the Stripe Dashboard, with the same credit card, the same amount and the same location.
We would like to omit 3D secure in our iOS app, just like the Stripe Dashboard.
How is it possible ?
Thanks for your help
This is not recommended, you should build your integration to support 3D Secure authentication, even when placing a hold to capture later.
Related
I have a service (iOS app) that works by letting users use a real-world service many times, but each time it's impossible to know the cost of each 'session' up front.
I'm aware that Apple Pay allows for a single checkout with an unknown amount (will be shown as 'pending'), but does Apple Pay also support a method where the user can 'authorize' an app once for (many) future update checkouts, without the user having to manually accept them each time?
No, this is impossible. Same as with credit card
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.
It would be appropriate to include significant account-specific features from Amazon and not just an authentication method in order to be in compliance. You may also implement your own optional registration, iCloud or Game Center as another option.
Great Apple rejected my game 6 times due the above reason, first of all, they rejected my game because they said it need a user registration to save purchased data even if user changed the device and they can access all purchased things if he have a registered user id with the game, i done the user registration using amazon login sdk, and three other games approved with the amazon login, but this game rejecting showing the above reason., is there any sample login view form for cocos2d for user registration? i dont know how can we do a login with iCloud or game centre. all i want to do is a simple login form for cocos2d.IS there any samples out there how to make a login form using iCloud or game centre ,, i have some ,but they al are native iOS sample, cocos2d samples is not there.
hope anyone can help me to get rid of this situation.,
I'll be submitting my app to Apple for review at the end of the week. The app is a marketplace platform so users need to enter a credit card when creating an order.
In order for Apple to test the app I assume they need to go through every screen but a credit card is needed for to get to most of them. I'm using Stripe for payment processing and have a dummy card I use for testing, but when I switch to the live environment I don't think the dummy card works any more so how can I allow apple to test it?
I can't figure out how I can submit a production ready app with live API keys and let apple test without processing a real order and charging a real card.
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.