I am implementing in-app subscriptions with Google Play and synchronize the status of those through polling to Google Play API. The subscriptions have a trial period of 3 days and I expect Google API to return paymentState=0(Pending) or 1(Received) after the trial period has expired. This does not always happen for customers that have a payment failure, as Google keeps returning paymentState=0(Free trial).
It seems Google is giving a grace period, although I don't have any grace period configured for this subscription type.
Do you know why this happens and how should I update the trial period status when the 3 days of trial have expired?
Thanks
Reported this several times to google, the issue is still present, from my experience for some orders the SUBSCRIPTION_GRACE is sent >20 hours after the current cycle ends, and if you send validation request before this notification paymentState will still have value 1 or 2 instead of 0.
Related
I have enabled a Dead Lettering and set the maximum delivery attempts for my pull subscription. I have tested that the delivery attempt increases as its supposed to if I do not acknowledge the pulled message.
However if I do not pull the message for some time (seems to be around 10 min), the delivery attempt seems to go back to 1, or get reset...
Is this the expected behavior or is this only happening to me?
In the docs there is nothing regarding a reset after a specific period of time: https://cloud.google.com/pubsub/docs/handling-failures
Delivery attempts are set on a best-effort basis and are not persisted so it is possible that if a message is not retrieved for awhile, it will be reset to zero, yes.
Is there a good way to retry failed subscription payments? Sometimes our customers will fail a payment but then have money the next day, so we just want to retry the payment instead of having them update their card. Some things we've tried:
Foolishly signed up for "Automatic Retry" thinking it would automatically retry, but it only retries after the customer updates their card.
In order for Automatic Retry to kick in, the subscription needs to change from Suspended to Active which has to be done manually according to support. There's really no way to do this through the API?
Our last resort: On any failed subscription, cancel the subscription and re-create it from the profile, starting on the date we want to retry the payment. Any downsides to this I'm not considering?
There is no way to automatically retry a failed subscription payment through their API. That thread is a few years old but no new endpoints were added since then to enable this functionality.
On any failed subscription, cancel the subscription and re-create it from the profile, starting on the date we want to retry the payment. Any downsides to this I'm not considering?
You will incur transaction fees for retrying even though the chance for success is low.
Make sure you control all notifications. If your user gets emails telling them they're making unexpected payments or setting up new subscriptions you run the risk of chargebacks which could cause you to lose your ability to accept credit cards.
3 days ago we received an alert from the facebook developers page inform us that one of our apps had reached 100% of the hourly rate limit. Our application had an error that caused the increase in calls to the APIS that we solved yesterday afternoon. Since that we deployed the fix we see that in API calls graph (graph: "Application Level Rate Limiting") we don't reach the limit but the calls to the facebook APIS still failing. We want to know if there is a period of time to recover access to the APIs after not reaching that limit.
Here you can see a screenshot of the alert:
alert
In the response headers of one of the calls, we receive this error:
Status code: 403
Header name: WWW-Authenticate
Header value: OAuth "Facebook Platform" "invalid_request" "(#4) Application request limit reached
You can see the header here
You are not the only one right now:
https://developers.facebook.com/support/bugs/169774397034403/
But i suppose it should be gone after a day or a few hours, in my experience, sometimes i can make a few calls and then it shuts me off again, while our application is not that api call intensive.
This is the response from Facebook:
Dear all,
We checked with our rate limiting team who confirmed that several
improvements were made to help you troubleshoot rate limit related
error messages. For example, we've fixed an existing graph and added a
new one in the app dashboard to give you more info about the status of
your app.
If you continue to receive error code #4 in your request, we'd
appreciate it if you can create a new bug report because this thread
is getting rather long. We'll be happy to analyze each individual case
for you if you can provide the following info:
your app id the entire error message include the trace id a screenshot
of the graphs on your app dashboard
Thanks for your patience while we looked into this.
Xiao
I was wondering about the performance of WSO2 throttling. Whilst checking it out, I did the following :
I created a new subscription tier (say Tier1)
I set a limit of 10 requests per hour on it
I created another subscription tier (say Tier2)
I set a limit of 20 requests per hour on it
I allowed my API to use those tiers and created a test application to use the API with Tier1
Using the API console, I started sending requests to my API
After the 10 calls(though it exceeded 10), I unsubscribed the test application and subscribed to the same API using the same application using Tier2
It took around 15 mins for the throttler to unlock. Which brings me to my first concern ...
How long does it take for a change in tier subscription to reflect on the same application????
In relation to the excess calls going through, I also set up tiers with limits on a per minute basis. Once again, I noticed excess calls going through.
What I also noticed was that this excess was in the initial number of calls and the throttling worked normally after those initial excess calls.
Which leads to my next ...
How long does it take for a newly set up tier to throttle properly? In the per-minute basis, I assume that some calls carry over to the next minute. Am I right in assuming that?
Any help in understanding this would be much appreciated. Thanks
I want to add an alert on Google Cloud Monitoring such that, for a given topic and a subscription, I want to know if a topic is being published then subscriptions are not being acknowledged at the same or similar rate for a given time frame.
How do we achieve that using Alerts in Google Cloud Monitoring or StackDriver?
I have tried an approach where I have 2 conditions to satisfy:
If publish operations > 0.016/sec for 2 minutes (meaning atleast one
publish per minute)
If subscribe acknowledgments < 0.001/sec for 2 minutes (If no subscribe acknowledgements happening in 2 minutes)
Then, alert.
Whats happening here is, during low load, if there are no publishes happening say for a span of 3 minutes and a publish happens, both conditions 1 and 2 are set to be true and devs are alerted about this as failure.
So, what is the right way of designing such alerts?
If my approach is close to what I want, the next questions that come to my mind are,
Is there a way to say count your two minutes from the instance where
the publish happens to see if acknowledgement condition is
satisfying or not.
Or, is there a way to make the alert to wait for 2-3 minutes to see if the incident resolves, and then send an alert to devs.
Or, is there a way we can count the occurances of these conditions satisfying and then alert only if the occurances are more than 5 or 10 in a span of 15 minutes or something like that.
Sorry for the long post. But, any kind of help is appreciated.
In order to calculate frequency for tasks a time window of 2-3 minutes is used. So if you had 0 tasks for 2 minutes or longer this issue recurs. This is described in documentation about partial metrics. Also, there are workarounds inside this link.
You can try creating your own custom metrics.