We use the Paypal's v2 API: https://developer.paypal.com/docs/api/orders/v2/.
I would like to cancel/destroy the order which have CREATED status and the payment older than 10 minutes.
Do you have any Idea?
I tried to call /v2/checkout/orders/{token} with DELETE method, but this method do not available.
Orders are valid for 72 hours once created by API, and 3 hours if the customer loads the checkout/begins an approval flow. Orders cannot be cancelled.
If they no longer interest you after 10 minutes, simply forget about the order, and do not capture it.
Related
I have some a script with trigger set up to send emails daily with GSuite account (about 10 triggers to send about 15 email in total per day, average 6 recipients/email.
However, last few days, I got the alert:
Exception: Service invoked too many times for one day: email
when running the script by trigger or by manually.
I do not think I hit the quota of sending email daily of Google. This morning, when I check the quota remaining by function MailApp.getRemainingDailyQuota(), I only get 4 email remaining. I do not know what happened.
Is there anyone could please help me to solve this problem?
This is the alert I receive:
Your script, AutomaticSendingEmail, has recently failed to finish
successfully. A summary of the failure(s) is shown below. To configure
the triggers for this script, or change your setting for receiving
future failure notifications, click here.
Start Function Error Message Trigger End
6/13/20 3:59 PM send_overtimerequest_email Exception: Service invoked too many times for one day: email. time-based 6/13/20 3:59 PM
Sincerely,
Looking at the page for Apps Script quotas it does specify that the limitations per day is counting recipient (100 recipient/day), so in this case you have no much option. Make sure that you are using the correct account because the limitation for G Suite accounts are 1500 recipient/day. Also check out if this may be applying to you right now:
Note: Newly created G Suite domains are subject to the consumer limit for the first billing cycle if they have six or more users, or several billing cycles if they have fewer users. For more information, see the Help Center page on sending limits.
A workaround that I would suggest is to have a service account and use Domain Wide Delegation to impersonate and user then make use of the Gmal API
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.
For eg: ride was in progress for 1 day ! Or ride was accepted, but neither the rider or driver, it any action on it. Does this generate webhook callback ?
I am using sandbox-api as of now. My ride just expires after some time(1 hour may be) and I get ClientError when trying to get the ride details. On rebooking, I get a new ride id. I do not know if webhook is firing callback or not, as I do not have a CA certificate as of now on my server listening to callback. Will this happen in production api also ?
Unfortunately our sandbox isn't perfect and doesn't mimic production behavior 100%. In the production environment a trip in the "processing" stage is cancelled after around 2 minutes if no suitable driver is found.
Regarding the duration of a real trip...I don't think we have any hard limit on that. If the driver and passenger mutually agree to keep the trip going, then the trip keeps going.
Webhooks will be fire for all trip status changes (i.e "processing" to "accepted" etc)
Hope that helps!
Best,
Richie
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.
Folks,
I am attempting to verify that auto-renew subscriptions are actually renewing in the sandbox environment. First, it appears that auto-renew subscriptions in sandbox are only valid for 5 minutes. Makes sense. I expect that if I wait for five minutes, then make another call to
https://sandbox.itunes.apple.com/verifyReceipt
With my receipt data, I should see the subscription renewed with an expiry date another five minutes out.
Unfortunately that is not the case. All I see is a response with latest_expired_receipt_info and a status of 21006, which means "This receipt is valid but the subscription has expired" according to the Apple docs.
Can anyone tell me if they are able to test auto-renew subscriptions end-to-end, including this renew component? Or do I have to launch this app and cross my fingers that prod will work as advertised?
Alternatively, is there some sort of client-side magic/API call I have to run prior to re-posting my data to the verifyReceipt URL?
There was some discussion on this topic here, but it's not clear to me if I can/should expect to be able to re-verify subscriptions entirely on the server side by posting to the verifyReceipt URL or if I have to do something on the client side too.
Thanks!
Copied from the Apple's Developer Forum, for those not willing to goto the forum...
Figured it out (but not thanks to the Apple docs):
1 month subscriptions auto-renew every 5 minutes. So far so good. They
auto-renew 5 times and then they stop, so after 25 minutes you'll get
the 21006 error. However even when repurchasing the same subscription
it will NOT auto-renew again on the same test account since it has
already auto-renewed 5 times. So if you want to test renewal and you
have been messing with these subscriptions for a while you need to
create a new itunes connect test user. This is very annoying honestly
and it would be a lot easier if we could just reset the entire
purchase history of a test user account. Also putting all in-app
test information in the Xcode documentation would be a lot better as
opposed to spreading it over Xcode docs/iTunes Connect doc/people
figuring stuff out themselves
Hope this helps.
This conversation in the Apple dev forums may shed some light on this issue for others who discover this post: https://devforums.apple.com/thread/105350?tstart=0
#Lata Sadhwani, App developer
For testing auto-renew subscriptions, the expiration time is 5 minutes
in sandbox (at least for the monthly subscriptions, not sure if this
is different for different periods). So when testing an auto-renew
subscription in sandbox, it should auto-renew every 5 mins and you
know they are working correctly.
But there is one problem. These subscriptions auto-renew only 5 times
(i.e. the purchase happens 6 times). After that you'll get an error
when verifying the receipt. So if you want to test after that, you
will need to test with another IAP test account (yes it is a pain
testing, especially if you have been doing this for quite some time!)
To check if a subscription has been cancelled or is valid, your
receipt verification code will need to parse the response from Apple
servers and they say you should verify each receipt. If the
subscription has expired or has been cancelled, the appropriate error
code will be returned (a non-zero status). If it has been renewed by a
user, the most current receipt is returned by the Apple servers.