Access GooglePay / ApplePay transactions in mobile (flutter) app - payment

Does anybody know, if there is a way to access the transactions made from (Google/Apple)Pay on the device?
I think of a way where the user first needs to grant the access to a specific card on his wallet to the app, before the sync is then started.
I am looking for a way to somehow verificate billings, which are initiated by our app, without handling the payment process itself. So I just want to "observe" it.
Thanks alot for any advice in the correct direction
I've been researching several different API gateway solutions to process payments, or to access bank account records, but that's all not really what the users will feel comfortable with.

Related

Is it possible to transfer ownership of Chromecast apps?

Have been trying to contact Google Cast support on this, but no response there. Hoping there are someone able to answer or point me in the right direction here.
We have a couple of Chromecast apps developed for a client. These are registered on a Google account we currently own and which is also used for other apps and clients (let's not get into a hindsight discussion about the cleverness of this setup right now).
I am simply wondering if there is a way to transfer ownership of these apps to the client's Google account?
Yes, you can transfer the apps to a different account. Please reach out to us here: https://support.google.com/cast-developer/contact/google_cast_contact_us?visit_id=637100530319223284-3107522626&hl=en&rd=1

composer-rest-server authentication important questions

I am very new to Hyperledger composer, so maybe I understand something wrong.
My situation:
I have a network with several cards. Lets say I have (admin#basic-network) and (user1#basic-network). Now I have created a composer-rest-server with google authentication via this tutorial: https://hyperledger.github.io/composer/latest/tutorials/google_oauth2_rest
Everything works fine but I have 2 questions:
1) Right now everyone can login with his google Account and gets the access key. Is this supposed to be? Because actually it's a private blockchain, and I thought that a Administrator needs to define who can join the network.
2) With the wallet, I need to import a card which is necessary to create api calls. But let's say there are 10x Users who access the Api. When I import my card, everyone else who is accessing the api can see the imported card with GET "/wallet" and can also use it for his Api calls?
I think that I don't see something or that I'm not thinking correct at some point. Hopefully you can help me here.
Thank you!
When you log in with google, you can call api without login error. however, if you haven't imported the card, you won't be able to interact with the network. And only admin can create participants, identifiers, and cards
Each token will manage different cards. unless those tokens also import your card, they cannot interact with the network with your card. Don't foget enabling multiple user mode for the REST server
I hope to help you

Connect Google calendar api and api.ai

So here is what i am trying to do :
I built a bot with api.ai for my business that is hosted on my webpage and my Facebook page right now. Bot works well.
I want to push it to the next step by allowing my customers to make querys on my calendar, ask to book a specific time, see if available, if not offer other time similar, then make a booking.
I have been reading this thread and the great answer attached to it but i think my case is a bit different.
I was wondering if the bot could always have a token so every guests won't have to Auth to query the calendar ?
Obviously i am new to this, i have been reading the guide of google calendar api and api.ai but i don't really see how to do that yet. I guess there is a way to store a token somewhere and then just trigger the query with some specific intents but not to sure how.
I have also done the node.js quickstart guide of the G-calendar api, and it works fine if that helps.
Thanks for your help !
You will probably want to use a Service Account that is permitted to the calendar in question. Service Accounts are similar to regular accounts, but they are expected to do server-to-server communication only, so the method to create an auth token is a little different to keep it secure.
See https://developers.google.com/identity/protocols/OAuth2ServiceAccount for more information about using Service Accounts.
In general, you'll be using a shared secret to create and sign a JSON Web Token (JWT) you send to Google's servers. You'll get back an access token which you'll then use to call the Calendar API. The access token expires in about an hour, at which point you'll need to repeat the process.
There are libraries available to do much of this for you. For example, if you're using the node.js library https://github.com/google/google-api-nodejs-client, then it will take care of this for you (although you need to modify the key file - see the documentation for details).

Get list or count of registered users for application

Using Instagram's API, is there any way to request a list or count of an application's registered users?
Instagram's real-time subscriptions can send notifications whenever a registered user posts to their feed, but I haven't found a way to get a list of those users, or even a count. This is easy enough to store server-side, but seems like something which should be discoverable.
Your Question
Using Instagram's API, is there any way to request a list of an application's registered users?
A quick search yielded no results for such a functionality. This make sense, though, since Instagram wouldn't want to open up all its users to any app designer.
Your App
If you want the number of users using your app, then you can easily track this yourself.
Instagram App
As mentioned before, Instagram probably won't provide even basic count information about its registered users. Presumably, this is valuable information.
Your Example
Instagram's real-time subscriptions can send notifications whenever a registered user posts to their feed...
This is true, but with very limited scope. The subscriptions below are based on users who are using your app or other simple criteria such as tags or geographic data.
Users: receive notifications when users who have registered with your application post new photos.
Tags: receive notifications when a new photo is tagged with tags of your choosing
Locations: receive notifications when new photos are posted and tagged with a specific location
Geographies: receive notifications when a new photos are posted in an arbitrary geographical location as defined by a center point
and radius
As far as I have found this far there is no IG API, however as already indicated you can keep track on your app. HOWEVER, what has not been pointed out is that you won't be made aware if users terminate their account or revoke your app so the count's might be a little off. (or worse if you didnt start keeping track since the public launch of your app)
You could test on a periodic basis if you still have access, but that would require additional code, and a lot of API calls if you app has a lot of users. I hope that IG will add this function at some point.

How to secure account creation via (private) API?

Some time ago, it was commonplace for smartphone apps to open a browser to a registration page with a CAPTCHA, or to require separate signup via web, because API signup was seen as vulnerable.
Now most apps seem to offer registration via native form, though endpoints for this are usually not documented in their public API. I haven't seen many reports of this being abused to create spam accounts.
How is this done? Is there a standard crypto/handshake process to verify real signups, or does signup typically rely on undocumented endpoints and simple API key passing?
Embedding yields a better experience but has the issue you mention. Yes, the service owners on the other end are still worried about this and combating the problem. And undocumented APIs don't help and the service owners know this.
One of the tools in the toolbox these days is keys assigned to devices which can be used for throttling. This would essentially let you limit the amt of service that can be consumed on a per device basis and it would require you have a device (or can steal the key from one) in order to provide service. So long as the process to issue keys to new devices is strong (a solvable problem) then you can offer a CAPTCHA-free signup experience within the confines of what you are willing to give to a device.
I'd also note that there are other well known approaches you can use, like IP throttling and handshakes with other service providers (like a phone carrier). Depending upon the problem domain these are on the table too...

Resources