I'm trying to write a free mobile app that would make payments merchant-agnostic for the customer.
Context: Most web-apps are merchant centric and allow for multiple payment types from the customer. But the problem I'm trying to additionally solve is to have, say, a mobile app that is capable of paying as many merchants as possible using your debit, credit or PayPal account. It shouldn't rely on per-merchant technical partnerships to work. It should just be able to talk to any merchant after writing the upfront code.
There are a few solutions that come to mind: Integrate with VISA, Mastercard, or PayPal. However, my goal is to integrate with stores that sometimes only take debit, sometimes only VISA, sometimes only PayPal, etc, while re-inventing the wheel as little as possible. I'm wondering if anybody has already solved a problem like this before?
Which APIs are the easiest to integrate against? Could you name a few?
Are there well known merchant-aggregating APIs that are already very popular? Do they cover much larger merchants like Costco and Walmart?
Are there partnership costs (with say VISA) I need to be aware of?
Is there one API to rule them all that would aggregate even across Debit, VISA, PayPal, etc to reduce things to one integration point?
I need this for a free consumer Android app and would really appreciate any help I can get - especially if it's cost-effective.
Best!
Amin
You might be able to obtain a large quantity of Paypal account info on companies who publish their account info for payment, but doing it with credit cards directly would be rather challenging as you would need the company's merchant account information and provider's information in order to process. This info is sensitive data as releasing this info would also allow you to refund yourself money using their merchant account.
Have you thought about using electronic check as a pay option instead? If so, that would allow your app to pay thousands of companies from your application without the complications of getting merchant account info. Let me know if that might be a viable solution for you and I can give you a hand with it.
Related
I'm developing a pay for win Android app, in which users are, among others, ranked according to the amount they have spent. The payments are Android in-app purchases.
My questions are:
Is an authentication system required for my users, in order to purchase and be ranked? In other words: instead of using an authentication system, could I use the UUID of the phone, or its MAC address, or any other piece of information that would actually act as an authentication system? If yes: why isn't there any other Android app that proceed in this way (indeed, they use Facebook/Google authentication, or e-mail + password authentication, etc.)?
Is there any Java ranking library that I could use and bind it to the Android in-app purchases? In particular: does Google offer such an API?
Is it a good idea to use Google's authentication and ranking based on Google Play? The ranking criteria must also be the total spent amounts.
Authentication and authorization
Firstly, I would like to make the distinction between authentication and authorization.
Authentication is a way to determine a user apart from other users. Authentication allows a developer to identify Jane Doe as a separate entity from all other users. Authentication is often a precursor to authorization.
Authorization pertains to what actions a user can take on particular resources. Authorization deals with the what, when, how as opposed to the authentication that deals with who.
To state your questions using more definitive language you are asking for best practices relating to:
Authenticating a user inside an application that is available on the Google Play Store, and
Calculating totals related to Android's In-App purchasing, and
Authorizating a user to take a claim action on a prize entity depending on the aforementioned total aggregate
Recommendations
I would highly suggest you use Google's OAuth 2.0 service to authenticate users as opposed to building your own authentication framework or implementing any other authentication framework, especially if this application is only used within th Android ecosystem. I recommend this because:
Android users already have a Google account, and
Implementing your own authentication framework requires very niche skills which usually require a team of people, and
Google already offers an Subscription and In-App Purchasing API which can be queried to rank you users, and
You will already have implemented this API to support in app purchasing to begin with
I would highly suggest you do not use MAC address or UUID authentication because
On a rooted phone I can change my MAC address, and
It does not uniquely identify a user across multiple devices, and
Using this type of authentication would not provide any benefit to your second goal of authorizing actions based on a total aggregate
In other words by using Google's authentication mechanism you can not only uniquely identify users across multiple devices, but you can also leverage the in app payment system to build your particular authorization logic.
The In-App Purchasing API already contains the necessary information you want since you will need to implement it to support in app purchasing to begin with. You might as well use it as a basis for ranking since it is readily available, secure, and contains the information you need with well documented ways of accessing it.
Additionally, you may want to look at the promotional capabilities and one time product-specific billing features functions and related APIs. This might fit your use case and it may make your application more secure and standardized.
Using the provided authentication framework and in app purchasing capabilities standardizes your application up until you implement the claim your prize functionality. People enjoy standardization because they become familiarized with it, and it provided a level of trust, so I would definitely investigate the other aforementioned APIs to see if your prize idea can be based off a foundation provided by Android. This would standardize your app all the way through and, in my opinion, would be best practice.
Summary
I would provide some sample code but your questions are still a but high level to provide anything useful in the way of code snippets. To summarize though my recommendations are as follows
Leverage the Google OAuth 2.0 framework for authentication, and
Leverage the In-App purchasing API and related APIs as a way to calculate total and rank users, and
Investigate the promotional capabilities, or one time product-specific features already provided by Google to see if it fits your use case, and
Avoid using MAC addresses and UUIDs for authentication for the reasons I outlined above
Edit ....
After rereading your title I realized I glossed over the fact that, as I understand it, the term ranking and it's related functionality as used by Android is mostly centered around where you application sits, popularity wise, in comparison to other applications. I have not seen the term used by Android to refer to internal ranking of users against some developer-defined criteria ( total, in your case ).
I'm not saying it does not exist, just that every time I see ranking it refers to application popularity. Therefore I would refrain from using that as a query term when researching how to build this application as you will likely get a plethora of false positives.
What I think you want, to reiterate, is
Authentication
Calculating in app purchasing totals
Promotional or one time features based on that total
Those terms will suite you much better. Please feel free to start a new post when you get further in to the project if you need assistance consuming the APIs
I'm currently developing a mobile application which will list businesses in a marketplace type format i.e. individual business listings, allowing users to purchase smalls items through our application.
Ideally each individual end user will be able to select their desired payment method such as PayPal, Mastercard or visa during sign up; however, we would also like to provide the option to change their desired payment option at a later stage.
The payment details saved by the end user will be stored and then delegated to the businesses at the end of the month etc.
Payment to the businesses will be made at end of month less our fees/subscription.
We conducted research and decided PayPal Adaptive payments to be the ideal option for chained payments to each business; based on the review of Braintree, Stripe and PayPal. Braintree was our next option however they don't offer their marketplace solution to customers outside of the US.
We have attempted to contact PayPal Developer support on numerous occasions, though have not had much luck in confirming what is required for a complete end to end solution based on our needs.
Our questions for the community are, will PayPal adaptive payments allow for the following:
Provide our end users (purchasing user) the option to choose between PayPal and other credit card options such as Mastercard, Visa, ApplePay
Store user payment details and allow for future updating of payment option
Allow Scan card API so a user scans their credit card using native IOS or Android camera?
Allow for top up type functionality so a user can add funds and top up when funds are low?
Our developer has not worked with the PayPal Adaptive solution, however, believe we cannot implement the above requirements with the Adaptive payment option.
The community we need your HELP as we are currently at a roadblock in the development of the payment solution therefore if anyone has implemented a similar mobile solution your advice or suggestions would be greatly appreciated.
I hope my questions are clear, though please feel free to request additional information.
Regards,
Wayne
PayPal Adaptive Payments is in a limited release. See this Developer Doc on the PayPal Developer website. Although they will continue to support Adaptive Payments for existing users, they will not likely accept new applications unless there is a special circumstance.
May I suggest looking into the PayPal owned company Braintree Marketplace?
I would like to know the best way to do this:
users of my Android app gain points as they use the app.
they can then 'check out' their points for money to their paypal or bank account
the app should take the money out of my the app's paypal account and transfer it to the users bank or paypal account.
any suggestions?
The payment from you to your app users does NOT happen on the Android app. Instead, the payment can be triggered either by user actions (for example clicking on some "pay" button) or by other events like "user has gained enough points and the payment will be done at the end of the month", etc.
The payment from you to your app users' PayPal account can be done by calling PayPal Payouts API or Mass Pay API on your server. Payouts API is REST API and Mass Pay is classic which uses NVP/SOAP. Check here for the docs:
https://developer.paypal.com/docs/payouts/
The Payouts API and Mass Pay API can be used to pay a lot of people in a call, so it's recommended to get a list of users and pay them at the same time, say, at the end of the week or month.
Or, in a cumbersome way, you can have script telling you which users and how much to pay periodically, say a month, and ask a customer service person / assistance or whoever you trust with your money to manually pay through your PayPal account. I know it's funny, but it's a way useful if there aren't a lot of users to pay, or this is what you can do before your automated process is in place. Some merchants do this, and I'm just trying to list the ways that you can do through PayPal, and leaving the decision to you. ;-P
I don't know the exact logistics of how to do this but here is a link to a possible PayPal api you could use https://developer.paypal.com/docs/integration/mobile/android-integration-guide/.
I will warn you that if done improperly this could be very dangerous for your bank account. If someone could use a tool like SB Game Hacker or Game Guardian to change their point value they could essentially steal money from you that they did not earn.
To combat this you can set up a database containing your user's point values and use that database when deciding how much money to give. Also make sure a user could not push their own manipulated point values to the db.
I have to develop an app implementing in-app purchase, whoses purchases are suscriptions to a service (with a fixed price).
My client didn't ask me to use Google's in-app billing API, and asked me to provide fields for the user to enter his bank details instead (and to directly interact with banks I guess). I haven't seen many apps doing this (except maybe Uber), and I'm wondering what am I supposed to do.
Should I tell him to use Google's in-app billing API instead ?
Or should I develop this from scratch / using a library ? (I really don't feel confident about this...)
Thanks in advance for your answers !
That sounds like a bad idea. I certainly would immediately uninstall any app that asked for my bank account information. If it were me I would try to convince the client to go with Google's service, or at least some trusted third party - does Amazon have an in app purchase system for Android? I've only used Google's. That system is set up to allow purchases without giving credit card or bank information to the app. It may even be a violation of Android developer terms to ask for banking information, you may want to look into that.
Have they given you any reasons why they don't want to use the Google service? Is it possible they just don't know about it?
If I have an iPhone app, Android app, and Blackberry app, is there any way to implement a monthly or yearly subscription-based billing scheme such that a user need only pay for one subscription in order to use my app on any device? The problem is that each app store seems to have the stipulation that any fees required to use the app must be paid through them so they can take their cut.
Dropbox does this, but I think they can get away with it because their apps will work for free, and the subcription only offers more storage space. Is their any way to do this type of billing for an app which requires a subscription in order to be used at all? If not, will simply adding some sort of free functionality get me around this?
Thanks.
[EDIT]
Let me be clear, my question is about how this can be done legally. I'm basically running up into the same issue that caused the Financial Times to stop offering its paper through a native iPhone app. The difference between them and me, though, is that I don't mind paying the app markets their cut. I just want to know if this is possible; a user can either order their subscription through Android Market or the App Store, and if a user isn't paying through both stores then I think I'm violating the terms of one of the stores.
You could try Bango.But you need to implement a possibility to transfer the Bango User IDs between your different apps on the different devices. They offer a service where they bill a recurring fee to the user. They offer a SOAP-Based API (amongst others) you can use from your app.
But beware: there are some legal restrictions concerning inapp payment in the Apple AppStore and the Android Market and maybe also in the Blackberry AppWorld.