Apple Pay supports a auth and capture by marking a transaction type as pending.
However in case of Android once we have the FullWallet. And in this we dont have a ability to set the transaction type.
So the question is does the auth and capture dependent completely on the payment service provider?
Or is there some types similar to Apple Pay of setting transaction type as Pending required on Android Pay as well?
I saw some service provider like Stripe which mentions that it supported Auth and Capture and in its FAQs for Apple Pay says that that also supports Auth and Capture. However, no such details about Android were listed. If anyone has tried before.
You're correct on the first point - auth and capture depend solely on the payment service provider. This needs to be supported / handled by the payment processor (e.g. Stripe) in some form - you can think of Android Pay as just a thin layer that simplifies and secures the transfer of the user's card information to them (it's a bit more complex in reality, but that's the gig of it).
Related
I've implemented in-app purchases in my app by using the Google Play billing library. I've implemented it as per the guidance here. This just a basic one-time purchases, and I don't store the purchase tokens or pass them to backend server or anything like that.
Looking at the data safety form in the Play store, there's a few questions around this area:
Does your app collect or share any of the required user data types? Yes/No
Is all of the user data collected by your app encrypted in transit? Yes/No
Under the: Financial Info > Other Financial info section: Is this data collected, shared or both?
Collected This data is transmitted off the user's device, either to you (the developer) or a third party. This includes data that is processed ephemerally, or stored for longer.
...AND/OR... Shared
This data is transferred to a third party, either on or off the user's device
My initial thoughts were the answers to the questions are:
Yes
Yes
Collected+Shared
But I'm not sure if this is correct. Thinking about it, what information is my app actually collecting/sharing? I'm just using the billing library to say "Does this user own sku X" or listen out when the library says "Hey, this person just purchased sku X". I'm not capturing or storing any kind of payment details or transaction history etc.
Can anyone offer their thoughts?
First off - I definitely recommend going through this doc - https://support.google.com/googleplay/android-developer/answer/10787469
Especially the What developers need to declare across data types section.
To a certain amount these are still murky waters, as this feature is new and Google is still figuring out which services go where. If you are not sure and want to be correct I would contact google support directly.
As to points:
Does your app collect or share any of the required user data types?
Definitely yes. There is an option later - Ephemeral processing - that says that it is being only used real-time and is not collected for a longer.
Is all of the user data collected by your app encrypted in transit?
Depends on the library. Haven't gone through it and hopefully someone will fill in the blanks here. My first guess would be yes, as google probably encrypts it.
Is this data collected, shared or both?
I would pick only collected, yet again for Ephemeral processing and also following lines stated in the documentation I mentioned earlier
The following types of data transfers do not need to be disclosed as
'sharing':
Service providers. Transferring user data to a 'service provider' that processes it on behalf of the developer.
'Service provider' means an entity that processes user data on behalf of the developer and based on the developer’s instructions.
I think you are correct, it is:
1.Yes
2.Yes
3.Collected+Shared
I've got an app which shows user's contacts inside device and allows him to make a call.
I want to show my user the last calls he has made. I was using READ_CALL_LOG permission (and was reading call log) until Google restricted access to it, then I switched to ContactsProvider to retrieve contacts and sort them by LAST_TIME_CONTACTED but now Google says this column is deprecated and effectively it will have 0 value for new versions of Android OS (see https://developer.android.com/guide/topics/providers/contacts-provider#ObsoleteData)
My app is not a default dialer (only default dialers apps are allowed to access call log) so I was wondering how I can achieve what I want in Google Policy compliant way.
I tought about storing the last contacts selected inside my own database (I know it won't be a full call log, as I will only have access to calls made from my app but that's fine for me), but don't know whether it's compliant with G Policy. I wrote an email to Google, however the person who replied said he can't help me with my question and I have to create new version of my app and ask them for review.
Does anyone know if my idea about saving contacts in my own database is compliant with G policy (please provide links from official sites). From my link (which I've provided above) I can only see that Google says
If your apps are accessing or updating these fields or APIs, use
alternative methods. For example, you can fulfill certain use cases by
using private content providers or other data stored within your app
or backend systems.
However it doesn't convince me to whether my idea is compliant
Thanks for help!
I believe you may store and use any user actions that had happened within your app.
The purpose of the policy (as stated here: https://support.google.com/googleplay/android-developer/answer/9047303?hl=en) is to prevent apps from getting access to the call-log in order to make use of it for purposes other then what users' expect, that's why the emphasis on critical core functionality of the app.
In my experience, different Google reviewers tend to review the same app very differently, and while one may reject a certain use-case based on this policy, another might approve it.
I would suggest phrasing the screen you want to create in a way that will help the reviewer understand that this data was not acquired from the call-log but some app specific actions, so for example instead of title "Call Log" which might confuse some reviewers with the risk of rejecting this update, you should title it "Recent app actions" or something like that.
I'm currently trying to get the hang of in-app purchases on Android. I want to implement a non-consumable one-time product, i.e. allow perpetual access to all content in the app after purchasing the product.
In the Android developer guide for In-App-Billing there is a "Best practices" section (see https://developer.android.com/google/play/billing/billing_best_practices ).
It states: "It's highly recommended to validate purchase details on a server that you trust. [...] By implementing your signature verification logic on a server, you make it difficult for attackers to reverse-engineer your APK file."
I do not understand the logic behind this claim - assuming one does not have user accounts in the app.
Both methods seem to implement a signature check - either on the device or on a remote server.
I guess that the cracking tools that are available are able to scan for and disable the on device security check - so maybe this is meant by "making it difficult".
Otherwise I don't see a difference whether a reverse-engineer looks for the on-device check vs. looking for the server-roundtrip. Both calls can be be removed or replaced by an "always true" return value.
The best practices document also states: "verify that the orderId is a unique value that you have not previously processed".
Even this seems questionable to (for?) me.
Assuming that the reverse engineer is not able to find and replace the verification round-trip to the server and you keep track of all order ids on a remote server - they still are not tied to any user id. So how can you decide, whether
a user has switched devices (or lost his data) and is restoring purchases or
someone tries to gain access to paid content illegitimately?
(I guess you could check via heuristics - say allow 3 same order ids in X months, but there would always be the risk of blocking legitimate buyers.)
These questions appear to be rather basic to me - therefore I assume that I'm simply not getting the whole picture. I would be very thankful, if someone could shed some light on this.
I was using Paypal to make payments from my application using MPL. Now I want to enable users to make card payments using Paypal. I have found that to implement this feature I have to move to MPECL. When I am using MPL I used to get call backs regarding the payment status whether its success or failure within my app. Now my issue is
If I use MPECL will I get callbacks to my IOS app about the payment
status?
Are there any nice tutorials in integrating MPECL in IOS/Android?
Also is it possible to use MPL and still accept card payments from
user?
Thanks
1) By callbacks are you referring to IPN notifications? If so, then yes, you'll get them the same way, although the txn_type value may be different.
2) According to this documentation, MPL and MPECL have been replaced by PayPal iOS and Android SDK's. I'd recommend using those instead. There are samples included with the SDK's.
3) Yes, users will be able to pay via PayPal or a credit card when going through the payment flow. If you want to process credit cards directly within your app you can use the new REST API for credit cards or you could use PayPal Payments Pro.
I am building an Android app that uses Google Analytics to record various Events and Screens throughout the app. The Engagement Flow dashboard is quite striking but I'd like to export the data and play with it on my own. How can I write my app so that I can extract the data that is used in the Engagement Flow dashboard using the Google Core Reporting API?
Currently, I am using sendEvent and sendView to track Events and Screens respectively in the Engagement Flow. I'm guessing my approach is working because the report works correctly in the Google Analytics UI, but I can't get the data out using the Core Reporting API for Android. I am fairly confident this is doable because I've been able to access the data using the query explorer for our website with the ga:previousPagePath and ga:pagePath dimensions (see screenshot below), but the same thing does not work for the Android SDK. I can get some data out using an undocumented ga:screenName dimension, but the corresponding ga:previousScreenName (and any permutation thereof) does not exist. Thoughts?
For what its worth, others have had similar questions in case its useful:
How to get “Visitors Flow” data from Google Analytics GAPI API?
Get Google Analytics "Visitors Flow" data from API
According to Google-Analytics, as of now this feature is not available.