I've gotten a subscription product working fine with Google's Wallet for Digital Goods, but I can't make user's cancelling their orders work correctly.
If I cancel for them via the merchant center, it works just fine (I get the postback with the orderId as expected). If the user tries to cancel (and this is the same in the sandbox and in production), they see the "Are you sure you want to cancel" dialog, and when they say "yes" it immediately fails. There is simply no delay there.
From everything I've looked at I'm not getting a postback at all in this case (and I'm handling the postback fine when we cancel from the merchant center). I've looked through the logs on our web server, as well as instrumented the postback handler, and it seems to be failing before it ever gets to my code.
I got the same problem. Seems like there is something wrong at Google. These errors appear in the console.
GET https://224.32.32.221/90187 gr_full.js:26
GET https://224.32.32.221/90188 gr_full.js:26
POST https://wallet.google.com/manage/r903944a86542ecd9d4195e49cd5a8668/rpc/subscription 500 (Internal Server Error) com.google.checkout.buyercenter.client.buyercenter-0.js:4267
Related
This is now the 4th time I am sending my app for review. I want to use Instagram Basic Display API and therefore require instagram_graph_user_media permission to access media (and incidentally instagram_graph_user_profile). I have 2 test users, my personal IG account with a bunch of pics and a test user that I created with an empty feed. I can login with both users. But when the Instagram app reviewer is logging in, my app can't access their media. I successfully retrieve the access token but when comes the time to call the Graph API here is what happens:
https://graph.instagram.com/me/media?fields=media_type,media_url,permalink,thumbnail_url&access_token=IGQV....
returns
{"error":{"message":"Application does not have permission for this action","type":"IGApiException","code":10,"fbtrace_id":"A99vuaAC41DSvlt0Hxvcly-"}}
Here is an update from my latest app review rejection. This time, I added the code above to catch code 10 errors and if I did, try to fetch the user profile data. Guess what, that failed with a code 10 error as well. So, whatever the app reviewer is doing, it is granting access to neither the profile or the media API.
Another update. The reviewer I had this time sent me two screenshots, one of the Instagram login screen and one of my app's error screen. Interestingly, the Instagram login screen had a strange Instagram username that I have never heard of before. It certainly wasn't my test Instagram account. So I now have evidence of them both using my test account and their own special test accounts.
The question in my mind now is, is there something special about their test accounts that ruins the process? After all, I have not added them to be testers of my app, although if someone who hasn't accepted my test invite tries to log in, it errors in an entirely different way.
I am running out of ideas here. My next thing to try is to exchange the short-lived access token for a long-lived token, as well as trying to use the new access token to server-side (where I exchange the code for the access token) to check if the access token ever works or if it is created with insufficient access.
This whole process is a nightmare.
I will put this as an answer because we have dealt with this thing now for over 2 weeks and quite a few submissions. I think you should remove the bounty though.
What you have done so far:
Created and approved IG test accounts
Double and triple checked parameters & permission
Tested your app a dozen times
Created dozens of screencast spoon-feeding, making sure a 5 yo kid would be able to test your app
Having the above, I am sure you noticed:
The reviewer will add a generic text as 'reject reason.'
The reviewer will submit the irrelevant and out-of-scope screenshot(s)
The reviewer will not test with the Instagram credentials provided.
Maybe he WILL test with the Instagram test credentials provided (in fact you're left in the dark as to how they actually simulate IG access)
The reviewer will claim he's unable to sign in using provided credentials
The reviewer claims having tested, but you see no traces in your DB whatsoever (would be smart to do so, to know whether they're actually doing something or not, up to a certain point)
Conclusion
You have to know that your app is at the reviewer's mercy and approval sometimes arbitrarily. Eventually, you will find your app being approved while having submitted it to change at all.
This should be obvious but when you are so deep in the hole and try to think why your app is being rejected you stop thinking logically.
Here is what I did:
Create a dummy Instagram account.
Link this account to an email provider that doesn't require a phone/another way of verification (I used ProtonMail).
Use an Instagram Tester account (do the whole process).
In your instructions let the reviewer that they need to log in to ProtonMail to get the Instagram confirmation code; since they will do login from an unknown location (if you could simulate the above in your screencast that would be great, but I didn't do it).
If you apply for both instagram_graph_user_profile and instagram_graph_user_media you need to do this in 2 steps individually.
The second step getting the instagram_graph_user_media permission is much easier.
I lost a couple of days and tried everything and anything before I realized that.
Hopefully, this should help someone that is having the same problem.
The app was approved the first time.
It is possible that the App Reviewer is unchecking the instagram_graph_user_media access in the authentication screen, thus giving you only access to instagram_graph_user_profile. I had the exact same error code being thrown back my way, and I did the following:
Catch the error code 10 error
Try to fetch the https://graph.instagram.com/me?fields=account_type,username&access_token=${accessToken}
If that works, then display a page that makes it clear that you have successfully connected to the Instagram User Profile (and here is your username and account type) but, if the user wants to do X they also need to approve media access, and here is a button to go and reauthenticate again.
See the image I have below.
Now, I did the above and I still got an app review failure of code 10, which means that the second fetch to only the username and account type failed, and I do not know how they could possibly have managed to do that.
They admitted issue but not fixed yet: https://developers.facebook.com/support/bugs/543633182940083/
To get approved for Instagram Basic Display:
create a Facebook test user
create an Instagram account with that FB test user
give the credentials (email/address) of the Facebook test user to the reviewer in the Instagram Basic Display submission
Basic Display API review process is so bad its beyond words. I have been hitting the brick wall of their rejections for 3 weeks and almost got bald by pulling my hair in frustration. You really have to read between the lines to get a hint of what they are doing.
Turns out what the reviewer was doing is selecting "Continue with Facebook" on the Instagram Login screen and going that route (via Facebook login) instead of entering the instagram credentials directly. Only once I realized that I was able to pin point the problem. Interestingly though testing on the Simulator was fine but the problem only became apparent once I tested on the real device. The reason - simulator doesn't have neither Facebook app nor Instagram app installed, so it behaves differently versus the device where these apps get involved in the flow via deep linking.
The bottom line:
Test on real device.
Make sure to test both the direct Instagram log in and the "Continue with Facebook" option.
Test on the device with and without the Facebook and/or Instagram app installed.
Make sure to use brand new instance of WKWebView with non persistent data store to bring up the login screen, so that it doesn't have any cookies from previous logins:
let configuration = WKWebViewConfiguration()
configuration.websiteDataStore = WKWebsiteDataStore.nonPersistent()
let webView = WKWebView(frame: .zero, configuration: configuration)
Pray the God of your choosing.
I have an action that no longer works when issuing an utterance with "ask [invocation name] [utterance]"
it just returns with a "The agent returned an empty TTS".
However, if i set up nGrok, and try to debug it, the request never gets sent to nGrok and thus never hits my endpoint (backend code base).
Looking for next steps to debug this issue.
Note, "Talk to [invocation name]" works perfectly fine.
Also, if i use the "try it now" feature for utterance testing within dialogflow, with the same utterance, it triggers my endpoint.
The intent that is to be triggered is set as "Implicit Invocation"
While testing in the Simulator, Request tab is empty, Response is empty, Debug shows "the agent returned an empty TTS.", and Errors is empty as well. StackDriver logs does not even show this request being made.
While searching for other ideas, it appears this is possibly the same issue
Try to change your invocation name.
I had the same problem and that minor change fixed it!
Maybe is because you have some reserved word in your invocation
There is a problem when the user is clicking a postback button and the internet connection is not stable or is reconnecting from the internet. After reconnecting to the internet, it will look like the user has successfully clicked the button (Labeled as Sent) but my webhook is not getting any postback events. So the user does not get any response from my bot unless they click the button again with a stable connection.
I already sent a support ticket to Facebook regarding this. I'm asking help for a workaround this issue, that will continue the conversation or maybe a reminder that the user must click the button again to progress.
I'm using Node.js and Microsoft Bot Framework for this.
While I am unfamiliar with Facebook Messenger for bots, as far as I can tell, a postback button seems to work the same as any other button, with added async functionality. The intermittent internet connection appears to be interrupting that async call. There isn't a work around that I know of, as your bot is still waiting for a response from your user, a response that won't come, if your user thinks they've already sent info to the bot.
I would put a proactive/welcome message in the very beginning of your bot dialog that if the user is connecting with a weak/intermittent internet connection, to resend their response if the bot doesn't respond. If you're using the bot for sales purposes, then a message to not use the bot unless they're using a stable internet connection as they could accidentally send a purchase order twice, would be more appropriate.
I have successfully created a Glip bot in the sandbox and registered the corresponding webhooks, following the instructions found here: https://ringcentral-api-docs.readthedocs.io/en/latest/glip_bots/
When testing in the sandbox, I only get a webhook payload about 50% of the time when the bot is spoken to in a conversation. I would expect to get one every time, since the bot has a subscription for posts, and is a member of that group. Additionally, if the subscription wasn't working at all, I would expect to get it 0% of the time. Literally the same text will trigger it once, but not the second time.
I determined that there was nothing wrong with the endpoint by using Postman to simulate webhooks. Every time I created a simulation, the bot became aware of the post and responded accordingly. So it isn't the endpoint. It would appear that RingCentral Glip is not calling the endpoint every time it should.
It could potentially be a sandbox issue but I don't see any documentation that supports that theory. The specific event that's not firing every time is "/restapi/v1.0/glip/posts". As I continue to investigate I thought I'd reach out to see if anyone else experienced this issue, or has suggestions on how to debug.
I have a Actions on Google project that uses api.ai for its actions. This is working well and I can see request/responses appear on the google assistant interface (On mobiles and simulator)
One of my usecases for api.ai needs to broken into 2 parts, in that we have to inform the user that the processing has started and then inform them again once its completed (without them reprompting for the output).
Im trying for a way to inform the user who is using the Google assistant when the processing is completed, but have failed so far. Something like this
User: I would like to see if my loan request is approved
Google Assistant: Hold on, let me check and let u know .
.... (Makes a webservice call to the backend asynchronously)
.... After few seconds ...
.... Postback to google assistant from the webservice
Google Assistant: Thanks for holding, your request is approved.
Im not sure how to do the "postback to google assistant" call. I have tried to get the SessionId from the Api.AI call and then use that to make a event request , but that doesnt seem to send the response to the assistant. Google Assistant seems to be using the formats defined in https://developers.google.com/actions/reference/rest/Shared.Types/AppRequest, but Im unsure how to get the ConversationToken and use that for sending the response back to the user.
Short answer: you can't do that.
Slightly longer answer: At least right now, there is no good way to send a notification. Your Action can only respond to a specific statement from the user. You can say something like "ask again in a minute and I should have a result for you", but that isn't a great experience. At Google I/O 2017, they announced that notifications would be coming to the Google Home at some point... but gave neither a time frame nor any information about an API.
Long, but probably still unsatisfying answer: You can look into Transactions which let them initiate purchase or request of some sort and then "check out". Once they have checked out, you would confirm that a transaction is being processed with an OrderUpdates and then can send updates with the status of the "order". These status updates can turn into notifications or user's can query the state of the order at any time. Transactions don't require payment, so this may work depending on your needs.
However, there are a few things to note. This is still in developer preview, so things may change in the future. It also doesn't work on all surfaces where the Assistant runs, so while it does work on Assistant on phones, it does not work on the Google Home right now.