I have written multiple audit reports for my saas apps over the last few years. Most of the logic uses the PayPal API to get the full transaction list (using TransactionSearch) and then for each transaction, get the details (using GetTransactionDetails).
The intent is to line up my database records of recurring payments received with the latest PayPal data to make sure I didn't miss an IPN or anything.
This worked fine up until about a month ago.
Lately, the subscription ID is missing from most transactions.
In the past, subscription ID was contained in the "SUBSCRIPTIONID" NVP field. This is no longer there for all transactions, and I don't see any other fields returned that contain a subscription ID. All other fields seem to be there though, so I know my calls are working. It's just the NVP response is missing the subscription ID. I have also verified that the subscription ID is included with the IPN sent for the same transactions.
My code is using an older API version (108.0). Now in theory, PayPal won't ever change how an API works, so I'm baffled as to why results are no longer what they were with the same codebase a month ago.
I tried the latest API version (124.0), and it provides subscription ID's for more transactions than 108, but also not all of them.
I'm totally stumped here. Does anyone have any clues?
I don't want to ask PayPal support, because it will take 3 weeks to get no help at all :-)
Had the same issue for a month as well just stopped working randomly was going to try the latest version but if your say its the same then think the best course of action is file a bug report with paypal.
The only valid work around I found is to save the created api call which will return the email and subscription id.
Then use the information from get transaction id (email) to search the subscription id from the original database (created). Messy but works for now until they fix this issue.
FOLLOW UP
I am using this method to just keep making the api call until the subscription id is made as we know it does work every 1 in 5 tries.
try {
/* Original call */
$transDetailsResponse = $paypalService->GetTransactionDetails($request);
} catch (Exception $ex) {
include_once("../Error.php");
exit;
}
// If its not got sub id we start a while loop
if ($transDetailsResponse->PaymentTransactionDetails->PaymentItemInfo->Subscription->SubscriptionID == "")
{
// Run while loop until its found
while ($transDetailsResponse->PaymentTransactionDetails->PaymentItemInfo->Subscription->SubscriptionID=="")
{
try {
$transDetailsResponse = $paypalService->GetTransactionDetails($request);
} catch (Exception $ex) {
include_once("../Error.php");
exit;
}
}
I'm afraid I don't have an answer but I can't see any way for me to participate in this discussion, since I don't have enough reputation to make comments.
I have been having this same problem for a couple of weeks now. (In fact, I can tell that the problems first started with a change on 2016-03-07). https://stackoverflow.com/questions/36647177/paypal-api-has-stopped-sending-profile-ids-any-way-to-match-payments-up-to-a-s
I have noticed today that we have started receiving SUBSCRIPTIONIDs again. However the TRANSACTIONTYPE has changed to 'recurring_payment' instead of 'subscrpayment'.
Have also found that we are receiving transaction details from other sellers entirely mashed up with our transaction details -- product NAME lines that are absolutely nothing at all to do with our business. Completely broken and potentially a security problem.
I've opened several tickets with paypal-techsupport.com to describe these issues but I have not heard back from them yet.
PayPal support has finally responded with this:
The products teams are reporting that this issue should be resolved.
Please let us know if you are still seeing instances of this issue.
Related
Summary
I am using the Bot Framework REST API to create and update Microsoft Teams posts.
I have found that I can only update the last two posts of a conversation, but cannot find documentation that describes this restriction.
It is not possible to identify the failed updates from the API response, as the HTTP response code and body is always the same, regardless of whether the update works or not (200 with the id of the "updated" activity). I would expect the response to indicate the failure, and so this appears to be a Teams bug.
Detail
I can create conversations and create replies to conversations using the Bot Framework REST API without issue (using the create conversation and send to conversation endpoints). My problem arises if I try to update these messages.
Given a conversation that looks like this:
parent_message
|_ child_message_1
|_ child_message_2
|_ child_message_3
If I attempt to use the update activty endpoint to update each one of these messages, I observe that:
I can always update parent_message.
I can update child_message_3 and child_message_2, but not child_message_1. In each case the HTTP response is a successful HTTP response (200 response code, with a JSON body that contains the id of the updated message), regardless of whether the update succeeds or not.
If I add another message, child_message_4, then this will be updatable, but child_message_2 will no longer be updatable. I assume this is because now child_message_2 is no longer one of the last two messages.
I see the same behavior if another user adds messages to the conversation, ie. if a user were to make two posts to the conversation I would no longer be able to update any of my own child messages as they are no longer one of the last two messages.
My questions are:
Does anyone know if this restriction is by design? If so, can you point to some documentation on this?
Is it possible to determine when an update fails? As mentioned, the HTTP response always reports success so I'm unable to find a way to do this. Is this a bug in Teams?
Thanks for reporting this. We are able to repro this at our end and we are tracking it here: MicrosoftDocs/msteams-docs#2011
Please follow this issue for updates/progress/questions.
Updates: This is fixed.
This appears to be a bug, but I think the bug is different from what you think it is. Go ahead and "refresh" the conversation and you should see the updates in effect. If you're using the web app then you can refresh the page, but since you're probably using the desktop or mobile app then you could try switching to another conversation and back, or you might have to sign out and sign in again.
I have recently converted a trial account into a paid starter package and, since I've been assigned a long number, my attempts to send messages via the HTTP API have failed with the following messages in the Message Reports console:
An error occurred while attempting to route the message
Routing error (status 9)
I have confirmed that my username, password, and api id are entered correctly and that the long number has been matched to the active API. I've tried the "Valid Sample Code" provided on the API management console, all with the same result. Below are a few failed message ids if that's helpful for anyone on the Clickatell team.
6d7868662782cfd7d1708996bca066b1
4f837467ed535521ef39d9d885f121f9
2be08f4663a3d9d7cf2e5b9e9cad2d5f
For what it's worth, my trial account worked fine and as expected, so I'm fairly certain that this is not (obvious) user error on my part. I also upgraded a few hours ago; I'm not sure if there is a wait period between account activation and functional service. Thanks for any help on this.
Have you tried setting mo=1 and using your long number as your sender id from=123456789?
make sure you dont add any programming symbols in the text message. i had an exclamation mark and it gave me a status 9 error.
http://api.clickatell.com/http/sendmsg?api_id=xxxx&user=xxxx&from=13055140341&mo=1&password=xxxx&to=xxxx&text=xxxx
For what it's worth, I encountered a very similar problem with the REST API. It also requires the undocumented "mo=1" and "from=[your long number]" fields to be included.
Also, in the FAQ, they have "MO=1" but in actuality, it has to be a lower-case.
From OP:
Clickatell support responded with the following advice that resolved my problem. I also changed the password on my API key during the process which seemed to be part of the issue.
http://api.clickatell.com/http/sendmsg?api_id=xxxx&user=xxxx&from=13055140341&mo=1&password=xxxx&to=xxxx&text=xxxx
"from" is your long number, and because I'm using 2 way messaging , mo=1 needed to be set also. It would have been helpful if this were in the exemplary code provided on the api info and help section, but alas, I had to go through support to get my answer. It took about 2 business days for the response, but they were helpful
With the release of the new subscription option from In-App Billing API we started a proof of concept of the service and we found a few issues. Has anyone else tried it and would have some answers for us? Here's the issues we have been facing so far:
1 – While testing the unsubscribe functionality, the Google Play interface displays a white page with an “Item not found” message and a retry button. Is it due to the fact the app is not yet published? If yes, how can we test this flow without publishing it first?
2 – Inter device synchronization. When making a subscription on one device, other devices tied to the same account did not receive a OnPurchaseStateChange event. Is it again due to the fact the app is not published? Or are subscriptions tied to a particular device and not to an account?
3 – On our Google merchant page, when we cancel a purchase, the device does not receive a notification telling the subscription has been cancelled. Is this a bug? As a workaround we are manually checking the current time and comparing with the expiration date to force a restore transactions call. At this point, we are able to see the subscription is no longer valid. Do you think this is an acceptable solution?
4 – When a subscription is made, two transactions show up on the Google Merchant page: a FAILED transaction with a value of $0 and a valid one with the value we charged. Is this the expected behavior? What’s the purpose of the $0 FAILED transaction?
If anyone has faced similar issues we would like to know. Maybe these could be bugs on Google's end or maybe we did not understand 100% how it is supposed to work.
Thanks in advance.
1.I had the same issue and after I published (and later unpublished) my app I could see the app page in the market,so you can publish and than unpublish.
2.I didn't check it with subscriptions ,but for managed item i didn't get purchaseStateChange on two different devices as expected.
3.I do get subscription expired after canceling one,but only after a while.
I didn't understood how you can get the expiration date ?
you only can get it with access to play developer api.
the restore transactions will give you same purchaseStateChange as you got when purchase the item.
*in the developer guide it is recommanded to use restore transactions only in first app use.
4.I have same issue,and i heard at least about 10 people with same 0$ charge.
I have this weird issue in Magento when someone places an order using PayPal Express Checkout. Every so often an order will come in and then the order gets canceled a few seconds later. The comment that is left is as follows:
Canceled order online. Amount: $59.23. Transaction ID: "XXXXXXXXXXXXXXXXX-void".
(ID blanked out just in case)
Now our customers are swearing they did not cancel their orders and when we ask PayPal they say it is a problem on our side.
Has anyone heard of this issue and do you know of a fix? I am running Magento Enterprise 1.8.
I've run into a similar issue. I tracked it down to those users who checked out with PayPal Express and do not have a PayPal account. The issue and the fix appear here:
http://www.magentocommerce.com/bug-tracking/issue/?issue=9894
The face that all users do not encounter the error may be related to the with/without a PayPal account status.
Integrating Magento with PayPal Express (not PayPal standard) the users can buy our store's products.
However, there are two different situations:
1) If the customer has got a Paypal account, he will be able to finish the buy process without issues.
2) However, if the customer hasn't got a Paypal account, or if he doesn't want to use it, and prefers to buy the products using his credit card without use the PayPal credentials, then the process will finish with the following error:
"This payment cannot be processed using your paypal account at this
time".
The problem is the seller will receive the money, but the customer will think just the opposite.
This issue has been discused and confirmed with PayPal support team.
The real issue is during the buy process, the "DoExpressCheckoutPayment" PayPal's function is called. However, when the buy process finish with this error, a parameter called "successpageredirectrequested" is set to "true". This flag indicates whether you need to redirect the customer to back to PayPal after completing the transaction. However, this is an obsolete PayPal's behavior, and should't be used.
As Magento is using this parameter's function, when he tries to redirect again to PayPal (that's what "successpageredirectrequested" set to true is doing) PayPal will return this error.
We can fix it making a little change in Magento's source code, at app/code/core/Mage/Paypal/Controller/Express/Abstract.php
Just changing the function "public function placeOrderAction()".
Look for the following code inside this function:
// redirect if PayPal specified some URL (for example, to Giropay bank)
$url = $this->_checkout->getRedirectUrl();
if ($url) {
$this->getResponse()->setRedirect($url);
return;
}
$this->_initToken(false); // no need in token anymore
$this->_redirect(?checkout/onepage/success?);
return;
}
We just need to comment the "if", just like this:
//if ($url) {
//$this->getResponse()->setRedirect($url);
// return;
//}
That's enough to fix the issue. However, this is not a current fix, and this should be reviewed by Magento's programmers just to fix it in the Magento's new versions.
Goal: Only have successful purchases show up on a customer's billing statement. I don't want declined authorizations showing up on their billing statement (as seen in an online banking system) as pending. A customer often will accidentally input an incorrect billing address, for example, followed by a correct one. Together, the two attempts, one successful and one not both show up on their billing statement as pending prior to settlement. This can scare the customer as it looks potentially like they will be charged twice.
Details: When I do an AUTH_CAPTURE (via ActiveMerchant's purchase) or an AUTH (via ActiveMerchant's authorize) which is declined and subsequently want to void that authorization (via ActiveMerchant's void) so as not to have it appear on a customer's billing statement as pending (even though it will settle out after a few days), the gateway can't find the transaction to void using the authorization code returned from the authorization or capture method calls on the gateway.
This is specific to the authorize.net AIM gateway.
Please advise.
Thanks!
If I understand your question correctly, I'm not sure there is a way to do what you want.
This is a limitation of the gateway / merchant account system.
I just stayed at a hotel this past weekend, and when I checked in I was warned that an 'authorization charge' would appear on my card and then go away. The hotel situation is similar to what you are dealing with, and I don't think there is a way around it. Gas stations do it, restaurants, hotels, etc.
It's so common that I wouldn't worry about customers being alarmed. You might put a statement on your payment form saying something about an authorization charge - I've done that in the past on projects.
And for the auth.net specifics - I'm pretty sure you cannot void an auth, thus the error you are getting. The auth code returned is used later on to capture the amount, if needed.