I'm using Google Pay with Stripe on Android.
I'm part of the testing Google group, so I have the list of Google Pay test cards that I can test with, but they all succeed. I've been unable to add Stripe's cards that give specific failures to Google Pay.
I'd like to be able to test failing for insufficient funds for example, where the card is valid, it just fails to actually charge.
I've been able to reproduce some of the errors in production, for example by using a card with a $0 balance, but I have to do this on a release build and don't have access to the debugger, which makes tracking down issues a lot harder.
What's the best approach for testing all the various failure cases with Google Pay?
EDIT: I'm able to mock responses and do testing that way, but the errors in production don't seem to act the way the documentation would lead me to believe, so I'm having trouble mocking in a way that actually matches production behavior. Would be nice to be able to end-to-end test with Stripe's test cards in Google pay for example.
Google Pay won't typically return information related to things like insufficient funds. The reason is Google Pay will perform some authorization checks when the card is added to Google Pay, but not when the user selects a payment method.
When a user selects a payment method with Google Pay, it returns a payment token that you would then pass onto your PSP (Stripe) and Stripe would respond with insufficient funds (and other scenarios). Therefore, it comes down to how your Stripe integration responds with the payment data specified. My suggestion is to stub/mock the request to Stripe and return your desired response instead. The response from Stripe would typically need to be handled in your back-end code and sent to your Android app with details of the failure (e.g. insufficient funds).
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.
I have integrated Paypal-SDK with my Android Application This is
working fine when i am using PayPal, but when i am using direct
payment with credit card it crass.... how can make direct payment
using PayPal sdk.
Even the application i have created is showing like that.see the line features that are not - available for live transaction
Now more thing how can i get test credit card details including
cvv so that i can request test transactions in sandbox mode.
In my case, Its giving this Disclaimer:
"Unfortunately, due to recent product changes in the region, we are no longer able to allow Live DCC processing via RESTful APIs to Canada. We are continually looking for ways to expand our services, so please stay tuned. We apologize for any inconvenience this may cause"
This mean that, paypal does not provide Live DCC processing to some areas in "Live api" (you can test it in test Api), you should check if it is the case with you. Either show your log cat.
While Using Test Api, two accounts are generated, one business account, another personal account. You can test it by transferring some amount (not actually transferred) by personal account in your app and check it in your sandbox business account.
It may help you.
I am creating an Android application that will offer users a subscription option if the user has his credit card information stored in their device. If he does not, I am thinking about offering different methods for the user to use the application.
Does anyone know if there is a way to check if a user has his credit card information stored in their device?
To clarify what I am looking for:
Android devices allow users to store credit card information so they don't have to re-enter the information for every purchase. I'm talking about identifying that the user has that data stored. I am not talking about storing that information myself for the user or trying to get it. All I need is a boolean method that will tell me if the user has the data stored or something similar.
Credit Card information isn't really stored "on the device." In the case of devices that are connected to the Play Store, Google account credentials are stored and payments are made through Google Wallet. I don't have a lot of experience with other types of devices, but I imagine they all work in a similar fashion, for example a Kindle Fire will keep Amazon account credentials, etc.
If you're looking to create an application that provides in-app purchases and will be available on the Play Store, you can click here to read about Google's In-App Billing API that allows your users to use their Google Wallet to make payments. For Kindle Devices, Amazon has a similar API.
It would be a pretty major security concern if arbitrary apps had access to the device owner's credit card information. If you're writing an app that you intend to distribute outside of a reputable app store and therefore without a built-in in-app purchase api, you're going to have to use your own payment mechanism. If this is the case, I wouldn't recommend creating your own. I believe PayPal has an Android API, and a quick Google search came up with a few other less notable brands that offer this service, though if you do intend to use the Play Store or Amazon's app store, using a 3rd party payment API usually goes against their terms of service.
Edit: The AccountManager class allows you to view info about accounts on the device, however, I don't believe that you can use it to discover if the user has a payment method set up through Google Wallet. I found this SO question that goes into detail about what the AccountManager can be used for. If this is a Play Store app, I'd look into the Google In-App Billing API, it's probably the best option for what you're trying to do.
I am in the early stages of scoping an app that targets a specific vertical market. It is not consumer orientated. The organisation developing the app has existing web-based products and established infrastructure for registering user accounts and billing for those products, and the app should inter-operate with these products. To that end, I have a few questions:
1) If the app that has functionality that can only be enabled from outside the app (for example, via a separate web site) and where the developer bills the user for doing this:
Q1. Can this App be distributed using Google Play?
Q2. Since enabling the functionality takes place outside of the app, does the developer have to use Google Play's payment system to bill for it?
2) If the app which allows a user to create an item of content on a separate web site, so that they can subsequently modify it on that site and be billed for doing so (eg, a bug tracking app that charges for creating a bug record on a site):
Q3 Does this count as an in-app purchase and require use Google Play's payment system to bill for it?
Where can I find definitive statements from Google on these scenarios? I am only finding material that relates to consumer applications where the purchasing and billing scenario is fairly simple.
I cannot shed much light on the potential "thou shalst not have any payment methods beside me" aspect of your question, but as per the technical side, the following aspects come to my mind.
Q1: Technically, the app could either be free on GP and use other payment methods, or it could use the Licensing Validation service.
Q2: The only secure way of deploying Google Play Licensing is to perform all integrity checks on your own secure server. The app could request the GP LVL info and pass it to your server. You could use the GP LVL user ID (an obfuscated binary app-specific byte string) to identify the user and negotiate with your app any password details you may want to implement. Of course, in this scenario, I would expect the user to feel like he already payed so the registration on the server side should be smoothly integrated. If an "enabling"/"authentication" step is additionally required on the server side, I'm not so sure I'd use the GP LVL.
Q3: You could use GP IAB V3 consumable in-app purchases for this (or V2 subscriptions but it sounds more like a per-item payment). Again, this is only secure if you generate a per-purchase developerPayload for the buy Intent on your server and validate it when the app looks at the user's purchases. Validation again must take place on your server, or else you'll have to include your app's public key in your app, which is a major step towards your app getting cracked.
In general, if you have a user management of your own which is to be used, it is important to know that the GP info is relatively anonymous (LVL: obfuscated, IAB V3: no info in the direction of the app at all). So a reliable, use-case oriented binding between "your" accounts and the GP experience would be key here, I'd say.
Inching slowly (but methodically) towards my first implementation of In-app Billing, I reached the point in which I can actually run the market billing sample application: The app is signed and uploaded to the AM, the "product list" has been created per the instructions and a test account has been set in both Google and the phone.
But when I proceed (successfully) with a purchase, despite selecting the test account on the AM, I am prompted to confirm the purchase with my real gmail account, to which my real credit card is linked.
When testing PayPal, for example, one can create test accounts, too, with fake CC numbers, to test freely w/o burdening the real CC system.
Is this available (or possible) for In-app Billing development & testing, too?
Update: I tested this on a different device, having only the test account set, and sure enough the Android Market behaves erroneously, responding the following error message:
The item you were attempting to purchase could not be found.
I know that the item is there and that it is set up properly in the Android Market because this error is never issued on the device with the real account with the CC number (there I receive a perfect behavior with the masked CC number, the Total and an Accept & buy button). Why does Google write such misleading error messages?
Update: I found this incredible thread, which seems to partially answer my question. Unless something new has been introduced by Google since then.
You have to use a real credit card. However, you can always refund your test purchases!
Note that you'll have to make the purchases from a test account that's separate from your developer account, since Google Checkout doesn't allow an account to buy from itself.
Test accounts are useful when you upload your application as a draft application,not published.Then using test account you can do even purchase of unpublished application.Hope this helps.