Implementing stripe connect directly from within an iOS app - swift

There is a post re: implementing stripe connect from a couple of years ago.
How to use Stripe Connect in an iOS app
I have built an app where only User A needs to register and login while User B can choose from a list of User As and i am trying to set up the app so User B can pay directly to a User A.
While the basic version of stripe is relatively easy to implement Stripe connect is giving me a bit of grief.
Specifically there is an example called Rocket Rider on github (which is meant to.mimic uber, etc.) made by stripe but in this example the "Pilot" had to register via a website.
I'd like it all to happen from within my app. I've read the docs a few.times now and still a touch uncertain.
Is the post from a few years ago still relevant? Is the only way to have the registration done via the app to use a webview?
In the stripe docs there is a section https://stripe.com/docs/mobile/ios/standard
Which essentially goes through the implementation for iOS. But I wasn't sure if these docs only refer to payment that as the developer I would receive if say I was selling a product to users.
Again, in my app there is a list of User As and each User A would register ideally within the app and then User B can choose who to pay. I wasn't sure if the "Standard" doc above also refers to this scenario.
Thanks

Been looking into the same thing today (March 2019) and have a few answers for you
The current state of the Stripe Cocoa Pod does not have anything that has to do with connect accounts. That will not help you in any way with creating connect accounts.
All is not lost. If you must stay in-app, you may create what is called a Custom Account--This means that you are responsible for the UI, User Validation, and Communication. Your users will not be able to use the Lovely Express Dashboard either....but you can stay in app.
As you alluded to, you are still able to use Safari to open Stripe Express and have your app handle the deep linking once the experience is complete. While this is an annoyance, there are some serious perks to having the Express experience. You don't have to deal anything bank account related because the Express Dashboard will handle it for you and Stripe will handle all verification communication. (Outside app).
TLDR: You can do it completely in app using Custom Accounts......but you'll be on your own!

Related

Stripe iOS integration server side code

I have been playing around with the Stripe SDK and API and I am a little confused. I have a very simple use case. I want to use the built in STPAddCardViewController and STPAddCardViewControllerDelegate to save card information that a user puts in. We also need to charge the card based on the credit card the user created. We have a unique identifier for each user when they create an account and any user that has access to our app does need to create an account. What is the best way to do this?
We also aren’t able to get the card information (STPCardParams) that a user selects from the STPAddCardViewControllerDelegate. How would we do that?
The part that I am having the most trouble with is the server side piece. I know Stripe gives example code for this but I haven’t been able to get it to work for us. We are using a backend as a service for our app so don’t use code to create our server. Is there any simple code that we can deploy that allows us to pass the card information, our Stripe API key, a charge amount, and a currency to a server (on heroku for example), and just have that server charge the card for us? I don’t think this is that hard to do and it seems like it can be pretty cookie cutter for everyone who is using stripe. If this is the case, does anybody have the code for this? Is it possible to use stripe without server side code?

Automate distribution of redemption codes for Custom B2B app

I have built a Custom B2B app for one of our clients. My question is how to automate the distribution of the redemption codes.
I have already looked at some of the MDM providers. Their solutions are too expensive and all we really need is a way to distribute the app from a webserver, not manage a bunch of mobile devices.
As you probably already know, when a client buys a Custom B2B app through the Apple VPP program, they get a spreadsheet with valid redemption codes for the number of licenses they have built. This spreadsheet has 2 columns: 1) redemption code 2) URL to redeem the code
I want to provide my client with a URL where they can send their users to download the app. They just don't have the expertise/infrastructure to distribute the app themselves. And emailing clients is not going to work.
I'm not a web guy, but it seems to me that we could write a webpage that would look at the spreadsheet for the next available activation code and then redirect the user to the associated URL. I'm not concerned with the number of licenses they distribute since I have another way of auditing the real number of users (Flurry). So I want this to be as painless as possible.
In fact, I have multiple clients and want to provide them each with their own URL for their clients. It seems like this shouldn't be too difficult to code.
The problem is, I'm not the guy to write that code. Any ideas on how best to do this?
Assuming that you don't want to show the user a website you should be able to do this with an online service like parse.com and the features it offers.
From a user POV you would supply them with a link which directed them to parse.com with a path and parameters indicating the action to be taken (get app) and what account is associated. This would redirect the users browser to the appropriate destination.
The main issue (and this applies to any solution) is knowing if the user actually followed through and used the code. i.e. should it be removed from the DB so it isn't offered to another user in future. Then you would update the DB each time you get a new spreadsheet.
Anyway, this could be achieved with a little javascript in parse.com, specifically, by using cloud code which can interrogate and modify the DB and then redirect the user.
Obviously if you need user authentication of some kind or other restrictions then you would need to start adding some web interface on top of this in order to collect the details.

App Rejected on 17.2 clause. Asking for email ID

My app is a sync solution (imagine dropbox).
The user needs to sign in to access the app's features, and if he does not have any account already created, he can sign up.
The sign up asks for email id verification, and this email id is also used if the user has forgotten his password to send him one.
but Apple has rejected this app saying:
17.2: Apps that require users to share personal information, such as email address and date of birth, in order to function will be rejected
We found that your app requires customers to register with personal information to access non-account-based features, which is not in compliance with the App Store Review Guidelines.
Apps cannot require user registration prior to allowing access to app features and content that are not associated specifically to the user. User registration that requires the sharing of personal information must be optional or tied to account-specific functionality. Additionally, the requested information must be relevant to the features.
Although guideline 11.6 of the App Store Review Guidelines requires an application to make subscription content available to all the iOS devices owned by a single user, it is not appropriate to force user registration to meet this requirement; such user registration must be made optional.
It would be appropriate to make it clear to the user that registering will enable them to access the content from any of their iOS devices, and to provide them a way to register at any time, if they wish to later extend access to additional iOS devices
Please help me solve this. Many apps like dropbox/facebook require login.
I don't get the exact reason why they rejected my app.
Also, please guide about the in app purchase, why registering cannot be mandatory
Asked App Store Review people for clarification on their rejection.
They accepted it. and the app got approved :D
Its on Appstore now :)
I also Faced this kind of Problem and my app also Rejected due to this.And Again I Changed my App flow Like User Registration will be Optional. User can See all the Feature of the app with out Registration by skipping this step.If he want to do something user-specific then you can ask to register such as : (user like,comment,photo upload etc) or else he can use the contents and features which are public.
in Case of in-app Purchase You can Prompt user that if He will Register with your app he can able to use this Content in his all devices.
It would be appropriate to make it clear to the user that registering will enable them to access the content from any of their iOS devices, and to provide them a way to register at any time, if they wish to later extend access to additional iOS devices
Apple does not allow apps that require you to share person information to work, like an e-mail address.
You options are, remove the need for an e-mail address or remove account creation form you app and move it to a website.
It also states that you app is asking to create an account to access the full app and even needs the account or acces features that do not require the user to have an account. You can make those features available with out the account creating you might be able to get thru the review.
The reason apps like Facebook and Dropbox got thru the review proces is because they don't have a register option which is in app only. They redirect to a website.
I recently spoke to an Apple Rep over the phone in regards to an app of mine that was also accused of violating clause 17.2.
I explained to him that the email would be used for password recovery, monitoring transactions within the marketplace, and managing any inappropriate behavior (such as users uploading offensive or copyrighted content). The rep responded, "Sir, the clause states 'Apps that require users to share personal information, such as email address and date of birth, in order to function will be rejected'. I cannot allow you to require your users to submit their emails if its not account-based". He did not seem to understand that the emails are account-based for the very sole purpose of security.
I did mention to him that Instagram and Facebook alike require logins at startup. He simply replied, "Yes but those apps are entirely account-based."
Honestly, I felt he was blindly following Apple's Guidelines ("Because that's what it says we must strictly follow!"). He had little understanding of how social networking apps operate, and even less understanding of the law (specifically the DMCA - on a separate issue). Explaining to them how all that works proves to be futile; they wont budge because they are asked to follow Apple's BROAD Clauses as strictly as they do.
My conclusion: I had to compromise the app's user flow such that the app's registration page can be skipped, and all other functions within its marketplace were locked to non-registered users. It makes no sense.
The sign up asks for email id verification, and this email id is also used if the user has forgotten his password to send him one.
Apps cannot require user registration prior to allowing access to app features and content that are not associated specifically to the user.
It seems to me that the point is that you are asking the user to provide his email address as a step towards the creation of a user account. This is different from what dropbox and other apps do (i.e, you provide your credentials for your dropbox account, which is different from your email address, although it can be the same).
You may either remove altogether email verification, or you could postpone it to a later point when you have made clear to the user that this is required to access private information.
I got the same thing last week and this is Apple's reply:
As for the 17.2 issue, a nickname, avatar, or sharing are not inherent or specific features of those social networks, and thus, the user should not be required to register with those services, or provide you with access to their social network accounts. The user should not be prevented from using your app and service if they do not provide this information.
Instead, it would be appropriate use your own authentication method and give users the option to create a nickname and upload an avatar, independent from those networks.
Moreover, we realize that these social networks may be very popular. However, the popularity of the social network is not an appropriate reason to force a user who has not, or chose not to register and provide their personal information to those services, before they can use your app.
Therefore, we ask that you to include your own authentication mechanism to allow the user the option to register only with you, creating an account with only the information needed and relevant to your app's features.
Best regards,
App Store Review
So in short, you have to provide custom authentication and not just use Facebook. Although I've seen many Apps who do require you to login with Facebook.
Thanks,
James
It happened same for me, although the first version was approved, the second version was rejected for this reason, I added the Skip button at the landing view.
It's all summarized in the last paragraph. Apparently, your application doesn't inform the user (in a clear way) that registering is for syncing and from their reply, it seems that your application is useless without the Sign Up.
If that's the case, you should be more specific why you need the user to register.
On a side note, I personally don't like the applications/websites that force you to register before you see or try anything. I hope your application isn't the same.

Does my client need a developer account to submit the app I made them to the App Store?

I wonder if someone could offer insight here:
I work for an independent multimedia firm who builds communications material for their clients. We're currently working through our first iPhone app. So, my shop has now completed an app that conforms to our client's brand, and we wish to deploy this app to the App Store on behalf of our client. Looking over Apple's documentation, everything seems to be written on the assumption that you are releasing your own app... therefore, the Apple documentation seems to start one step ahead of where I need it to.
So, as a multimedia production firm, I have set up a developer account for my company that I have been using to develop our client's app. However, I assume my account cannot release my client's application, given that it would cite my company's name as the publisher. Therefore, how do I start this process on behalf of my client? Will they first need their own $99 developer account to publish with, or is there a separate publisher identity that I can set up within my account that represents my client?
Any and all help on this would be appreciated. Thanks!
I typically have the client create their own account. From there most clients will provide me access to their admin account so I can go through the rest of the steps.
I often submit apps through their admin account, however, a team member is an option if the client is not interested to provide admin credentials.

Can you automate the new product registration in iTunes Connect (In App Purchase)?

I am considering using In App Purchase for our iPhone app. But since we will offer a larger quantity of content items (>10 video items each day added), I would like to automate the new product registration in iTunes Connect.
Is this possible ?
If not: how long does it typically take before Apple approves a new registred product in iTunes Connect ? Since the content looses quickly it's 'freshness' (news broadcasts...), it is crucial to be able to have new content available ASAP.
Would you recommend using In App Purchase for this scenario or would you recommend developing our own payment & account system ?
As far as I know, it is not possible to automate it, unless you develop your own script (in AppleScript, for example, to operate safari and I am not sure if it will work as expected.
A new app will be reviewed and approved typically in 7 days. In-app purchases will go live when the app is approved.
In-app purchases can operate in two ways:
you include the content inside the app
you put the content on your severs and include the mechanisms to make the magic work. When the user buy the app, Apple server will communicate with yours and vice-versa, and a signal must be sent to Apple servers, during the process, so they will know the content was delivered. You will have to read the docs, as this is too complex to explain here.
I automated the input of a large number of in-app purchases using the Firefox extension iMacros. The free version is absolutely sufficient for this.
You have to create a CSV file containing all the data, then record the workflow in iTunes Connect and press start!