Is there Mobile API for Android that have an option to charge clients automatically or in the end of the month? And also can handle wallet information? (I don't want to keep card information on my own server)
For example taxi, Lime (scooters) apps that charges automatically in the end of ride (card information was entered before), or even Google Ads that charges in the end of the month.
Which payment services they are use? Someone familiar?
For PayPal on Android, a partial answer would be the Native SDK: https://developer.paypal.com/docs/business/native-checkout/ (not the web Checkout SDK referenced in another answer)
This does not address recurring billing / future transactions, however. For that with PayPal you need a feature called 'reference transactions' to be able to save or vault a billing agreement with each user. The PayPal business account owner can contact PayPal's general support (not their technical support) to inquire about enabling reference transactions with their service, and explain the business need for it. On review, PayPal may or may not approve the request, which is necessary for auto billing.
Most merchant services should provide you with one. Here is paypals, but you would only want to use it if paypal is your merchant.
https://github.com/paypal/Checkout-Java-SDK
Really, you should contact your merchant services (the company you are running the credit cards through)
Related
In my android application I want to let users to authenticate with google or facebook account.
I've implemented sign-in with google already.
I'll try to implement sign-in with facebook soon.
I've read about IAP in android:
https://developer.android.com/google/play/billing/billing_overview
https://droidmentor.com/inapppurchase-subscription/
at least what I understand it is about google account authentication.
So I wonder is it possible to make IAP in android application if the user is authenticated with facebook account ?
I cant find examples or explanations by now.
Any good examples/explanations about IAP with google is also very appreciated because I still don't have a clear vision on IAP.
fyi: In my app user will be able to buy "virtual tickets pack" (e.g.: 10, 15, 20 tickets) and to add them to their profile. and later they will "consume" tickets one by one.
Best Regards
My understanding is that you already have a user system that you are using to provide a Google login to your customers. When you add Facebook login, you'll probably want to match both Google and Facebook logins with your own custom user ID. It's always a good idea to have a custom ID of your own so that you can map it to different types of logins.
When purchasing through Google Play Billing, the purchase gets associated with the user's phone Google account and you can also provide an optional way of associating a purchase with your own user account system. In order to do that, when building the BillingFlowParams, call setAccountId and pass your account's system custom ID.
To provide the best experience persisting purchases during installs or across devices you should also be saving the purchases on your server's database. In order to do that in a secure manner, you will also have to implement server-side receipt validation. If you want to avoid most of these headaches, I recommend you to use a service like RevenueCat.
IAP can only be done through the user's google account, as that is what one needs to use any part of the Play Store. The user's google account is also where the credit card/other payment methods are stored for each user.
In spite of the above, the way users log into your app has nothing to do with them using the IAP system. When a user will choose to use an IAP, the google account data will be provided by the android device/Play Store, not by your app (Off subject:the process is similar on iOS if you ever get to try there).
What your app needs to do, is receive the confirmation of purchase from the IAP sdk and then mark on your server that this particular user has purchased this item. Basically for any purchases (no matter the payment provider) you would usually mark in your DB the following:
what the user has purchased
how much did he pay
when did he pay
provider's id of the purchase, so you can later match the accounting reports with the payment provider's report
where he payed from (IP can be a good indicator, although in the age of VPNs not necessarily 100% acurate)(this can be useful for your marketing decisions)
mark that this user now has access to the item he purchased and if it is a time limited item, mark when it expires, so you are able to later check if he still has the right to access it.
Disclaimer:
I have not used the android IAP system directly before. I have implemented mobile app payment systems before using iOS IAP and on android Braintree payments. But the process is most likely very similar with android IAPs as well.
We are developing a Point of Sale app available on iOS and Android platforms.
Our business model is such that, each user will have to pay us a customised cost based upon the number of his business outlets on half yearly or quarterly basis. Once the user will pay us that cost than he could use our apps on any number of devices, on any platform.
I want to know if it's compulsory to process subscription charge for iOS App through Apple In App Purchases. Or we can process subscription offline and show user a alter message to renew subscription directly from our portal if a user's subscription expires.
This is what my team found in developer Apple guidelines regarding similar situation:
3.1.3(b) Multiplatform Services: Apps that operate across multiple platforms may allow users to access content, subscriptions, or features they have acquired elsewhere, including consumable items in multi-platform games, provided those items are also available as in-app purchases within the app. You must not directly or indirectly target iOS users to use a purchasing method other than in-app purchase, and your general communications about other purchasing methods must not discourage use of in-app purchase.
So it is like confirmation of #siddharth-gupta statement.
Note: this Apple statement for April 2019 -> and can always change. To avoid potential rejection/ban Always verify it with current official Apple Documentation
You can accept payment through your website for the membership, but then you'll have to make sure you don't offer this as a way to pay for the subscription inside your app.
Apple's rule basically states that if you have a digital product in your app (in your case, your subscription), the only way to pay for it should be via Apple's in-app purchases. If instead of using in-app purchases, you redirect the user to pay using any other method, your app risks getting rejected.
I'm creating some Android apps that require a very small payment for $0.99 per magazine. I was looking to use Paypal as my payment method but my app keeps rejecting login in I read that is because is in testing sandbox and see this:
Upgrade your PayPal account as necessary
Before attempting to use a live app to directly accept credit cards, go to the Account Eligibility page. In order to use a live app to directly accept credit cards, you may need to sign up for PayPal Payments Pro (a paid subscription).
Additionally, please note that you must have a PayPal Business account to accept PayPal as a payment method.
Is necessary to Upgrade my personal account and pay monthly fees for in app purchasing?
If so is there any other way to receive payments that doesn't cost monthly?I don't think this magazine app will do much money.
Additionally, please note that you must have a PayPal Business account to accept PayPal as a payment method.
You need to do that and make your account business validated. Without verified business account you will not be able to go live with your app as you won't get production API access.
My startup is developing a real-time marketplace platform for taxi companies somewhat similar to Hailo, Get taxi, Uber and Lyft (more or less), etc.
We are shopping around for a mobile payment solution and so far, we looked at the products offered by PayPal, Intuit, Braintree, and Stripe.
We are having a hard time with finding the mobile payment solution that fits our requirements.
Requirements:
1) (Must have) Passenger should be able to pay within the app by using previously added payment methods such as Credit Cards (CCs), Paypal (optional). Passenger is asked to enter the CC information only once when they sign up (or add a new card), so the CC info needs to be stored somewhere and retrieved when needed seamlessly. However, we would really prefer not to apply for PCI compliance.
Q.1) Let’s say I use PayPal Mobile SDK 2.* for payment system in our app. In the above scenario (1), is the passenger required to have a PayPal account (even for just using CCs for payment) and link it to our app?
Note: I have spent a lot of time digging into PayPal Mobile SDK 2.0 documentation (also called their support). I was told by the support person that merchants cannot store credit card info with PayPal for mobile payments (which I thought was the whole point of SDK 2.0).
2) (Optional) Passenger should be able to pay with a physical credit card by swiping it in the reader plugged into the driver’s smartphone. However, we need to integrate this process into our app (which is not currently supported by PayPal Here and Square). So, basically we need an API provider that allows creating custom POS integrated with our app.
Q. 2) Am I right when saying that scenario (2) cannot be accomplished with PayPal, Braintree, Intuit, or Stripe?
Q.3) Do you have any suggestions regarding the payment system that would allow us to implement scenarios (1) and (2)? just scenario (1)?
Please help if you have dealt with similar problems or know more about the subject. Thank you
Q3. You can also check out LevelUp. Facilitates in-app payments similar to PayPal and Stripe.
Similar to PayPal, it will allow you to store an access token after the user links their account. You will not be able to charge the card directly, as this would subject you to PCI compliance. LevelUp does not support the ability to swipe a physical credit card.
A. to Q. 1) Yes, the passenger is required to have a PayPal account if you want to enable future payments. PayPal stores and charges the credit card, without the merchant having access to it. This is pretty much the core of the Digital Wallet industry. You might have thought that you could process the credit card yourself, after retrieving it from PayPal. This is not supported, and would subject you to PCI compliance-ness.
A. to Q. 2) PayPal Here does not have a publicly available SDK yet.
A. to Q. 3) Just scenario 1 can easily be accomplished by integrating the 2.0 PayPal SDK.
I want to develop an Android Application with in-App purchasing using Paypal Api. According to the requirements of the Application the users (Buyers and Sellers) should have the paypal account and I am the owner of the app and I don't require it.
I mean the transaction will be directly between the Buyers and Sellers so my question is
'Is it necessary to have a paypal merchant account in order to use their API?
If yes! I live in Pakistan and paypal doesn't offer its services here.
What should I do ? Is there anyother way ?
I think you need used PayPal.initWithAppID API using the merchant's unique application ID (appID) that PayPal has provided.
As a transaction broker, the easiest implementation would be to ask the sellers to provide something like a "Buy Now" button.
Since this will be an Android app and it involves monetary transactions, I recommend to to read the Android Market Developer Distribution Agreement and the Android Market Developer Program Policies, in particular the sections related to payments.