Paypal documentation for PayPal Sync API (https://developer.paypal.com/docs/api/sync/v1/).
It gives some mysterious date, named "last_refreshed_datetime".
On the sandbox server it is usually in the past, once it was a few days in the past, now it is 2 hours in the past.
What does it mean? How often it refreshes?
I only know that if I create a transaction it will not be visible on PayPal Sync API until the refresh date will not be later than the transaction date. And I'm guessing it should be the transaction approval date that does not presented on this report. The transaction approval date is available on transaction object (https://developer.paypal.com/docs/api/subscriptions/v1/#definition-transaction), it is called "time".
time string
The date and time when the transaction was processed, in Internet date and time format.
Read only.
I have reached out to the product development team for the SYNC API and have gotten the following clarifications in regards to your questions:
If the "last_refreshed_datetime" (Time until which we have data available in our system) is smaller than the requested end date then, in the API response we show end date as "last_refreshed_datetime". As we only have data up until that point. In general there should be around 4-6hrs of delay.
From my own experience on sandbox, on different occasions it was 6.5, 2.5 hours and even 2 days behind.
Related
Looks like there is a bit of inconsistency between 2 ways calendar RECURRING events could be created using the TIME ZONE:
'quickAdd' - does not require you to provide a timezone. The Calendar's default (UTC) or the one set by the Calendar owner will be used. Fair enough.
'insert' - the API doc states: "For recurring events this field is required and specifies the time zone in which the recurrence is expanded. For single events this field is optional and indicates a custom time zone for the event start/end."
Why for 'insert'-ing recurring events we cannot use use the time zone the Calendar already have?
The 'quickAdd' api endpoint clearly shows that it is possible!
For example, if you call the quickAdd with the following text (Important meeting at Office at 11am-11:25am every Fri with John) recurring events will be created with the time zone that already set in the Calendar!
Sure thing that I could get the Calendar time zone from the settings (/calendar/v3/users/me/settings/timezone). But this will require one extra call. It will cause more latency and bring more complexity to the code.
Another issue. The quickAdd api call for recurring events creates not only recurring events but also the same event on the day when the call been made! The API doc does not provide any explanation what are the correct values for the text attribute.
Would be great to hear back from Google API team to clarify those things.
Thank you.
I am creating a report, in which i have to show the number of sessions, users and registrations that have occurred today in a live feed. I see that the ga dashboard is updated only till 7 am in the morning although its 10:41 am right now. Can I know after what time interval does the analytics server is updated? I am using core analytics api to fetch the data as of now, if any other api suits my requirements do suggest.
Please suggest the following:
when a user want a certain package in my site, let's call it basic package.. his starting his recurring payment..after half a month he canceles the package, but his still paid for a full month, my question is this:
When recurring payment involved, what kind of fields should i save from the ipn, and how should i know exactly when to stop the features of the package a user bought...
I've seen in the ipn, i have 'next recurring payment' date, should i save it and use it? should i, every time a user do anything related to his package,check if the package limit time just ended?
What can be a most preferred solution for this?
When recurring payment involved, what kind of fields should i save from the ipn
All of them, for any kind of IPN whatsoever. Log the entire transaction every time.
and how should i know exactly when to stop the features of the package a user bought...
You should definitely stop when you get a cancel or eot IPN message. You probably don't want to deny service just because of payment difficulties. See below for the rest of it.
I've seen in the ipn, i have 'next recurring payment' date, should i save it and use it?
Save everything. Then you don't have a problem.
should i, every time a user do anything related to his package, check if the package limit time just ended? What can be a most preferred solution for this?
I have a 'subscriptions' table which shows the user/product pair and the expiry date. Every time he pays the expiry date is pushed out another period, or maybe I create it with the final expiry date, I don't remember offhand. When he logs in, he is given the roles associated with all his subscriptions that haven't expired yet.
If he tries to do something he can no longer do due to an expiry:
he isn't even provided with a link in the first place by the webapp, so he can't get there by any direct action
in any other case, e.g. somewhere I forgot to do that, or when he tries to access via a bookmark, container-managed authentication will see that he isn't in the appropriate role and give him a 403.
He can also see a table of his subscriptions showing how long they have left to run, and another table of expired subscriptions.
Our app uses Non-Renewable Subscriptions to provide access to content for one year. The subscription receipt is stored on iCloud (when available) and in the device keychain. There is also a WS that is called on occasion to validate the receipt but does not record the transaction.
Our problem is if the users change their clock backwards (say set the date to 2010), our subscription does not expire after one year but now three years (2013-2010).
Our solution was to say that subscriptions with a duration of more than one year are fraudulent and the receipt is cleared and life goes on.
However, my boss now is complaining about users that set the clock to six months in the past (less than one year so ok, but the subscription lasts for 1.5 years instead of the valid one year).
Is there a better way to be dealing with device clock tampering or is it something we have to live with (as I believe)?
If your app gets content from a server then you could store a list of "device-identifiers" combined with an expiration date.
Being on your server the client-time will have no voice on when the subscription is expired or not.
As I said in my comment above, I would check the time with a trusted server instead of using the local time. Just as important, once a receipt expires, immediately delete it or mark it as expired so that they can't turn off network access and roll back the time in order to use it.
In my application, renewing period is 1 month. Validity Time for Auto-Renewables in Sandbox is 5 minutes. So transcation identifier will keep on changing after each 5 minutes.
Initially i will a buy the product. If I am successfull i will get SKPaymentTransaction object it contains all details about transcation like transactionIdentifier, transactionDate, transactionReceipt and transactionState. Till this I understood. If I call restore function, (i.e.restoreCompletedTransactions) I am getting all the completed transaction information. According to my knowledge the first transaction log information will be the late-stet transaction information.
When compare both the object's details are different. How come this is possible. I am totally confused, How to restore this Auto renewable transaction details. Any help is appreciated.
To confirm that user's subscription was renewed or not, restore completed transaction and send first transaction's receipt to apple. In response apple will send you current status of the transaction.
For detailed reference read following link
http://developer.apple.com/library/mac/#documentation/NetworkingInternet/Conceptual/StoreKitGuide/RenewableSubscriptions/RenewableSubscriptions.html#//apple_ref/doc/uid/TP40008267-CH4-SW2
Specially Table 7-2 Auto-renewable subscription info keys
After that send your data to apple in Json format (Note that receipt part has to base 64 encoded.) and read the response carefully. In response you will find codes given in above table depending upon situation.
Please note that in real environment receipt verification should be dome from another server not from iPhone or iPad itself.
Post here if you have any further doubts.