I'd like to think I'm just missing something obvious here, but I can't seem to get a chained payment to complete (using the PHP SDK in the sandbox). I am able to get a successful response, and when I redirect the user to PayPal the transaction details show up fine, but when the user attempts to complete the payment they get the dreaded error:
Your payment can't be completed. Please return to the participating website and try again.
What's frustrating is that I've dumped the request data that is being sent, and compared it to the data in the example given in the documentation and tweaked my request until they were effectively identical, and still no dice. I'm also not seeing anything at all on any of the accounts to indicate that payment was attempted, pending or failed.
This is what's being sent:
requestEnvelope.errorLanguage=en_US
&clientDetails.ipAddress=127.0.0.1
&clientDetails.applicationId=APP-80W284485P519543T
&actionType=PAY
&cancelUrl=http%3A%2F%2Fdomain.com%2Fpaypal%2Fcancel
¤cyCode=USD
&feesPayer=EACHRECEIVER
&memo=Test+Payment
&receiverList.receiver(0).amount=3.25
&receiverList.receiver(0).email=merchant%40domain.com
&receiverList.receiver(0).primary=1
&receiverList.receiver(1).amount=1.5
&receiverList.receiver(1).email=seller%40domain.com
&senderEmail=buyer%40domain.com
&returnUrl=http%3A%2F%2Fdomain.com%2Fpaypal%2Freturn
And the response looks fine to me:
PayPal\Types\AP\PayResponse Object
(
[responseEnvelope] => PayPal\Types\Common\ResponseEnvelope Object
(
[timestamp] => 2013-07-28T23:25:52.676-07:00
[ack] => Success
[correlationId] => bf1ba2c8a50d4
[build] => 6941298
)
[payKey] => AP-XXXXXXXXXXXXXXXXC
[paymentExecStatus] => CREATED
[payErrorList] =>
[paymentInfoList] =>
[sender] =>
[defaultFundingPlan] =>
[warningDataList] =>
[error] =>
)
I also tried setting the action type to PAY_PRIMARY since I am specifying a primary recipient, and that's ideally what I'm after anyways.
UPDATE: Seeing as I still have not received a response on the ticket I opened with PayPal regarding this, and nobody has commented on this question, I did some further testing. If I generate the same request with the API explorer, the transaction completes normally. But the exact same request fails through the API. I have verified (by copying and pasting the generated headers and request body) that the only differences between the request generated by the API Explorer and the SDK code are as follows:
The headers created by the explorer have a space between the name and values
The API Explorer does not include the application ID
My API call does include the application ID in both the header and request body
The SDK API call still does not work if I remove the application ID reference, which was added in an attempt to solve this issue to begin with.
I do not understand why the payment generated by the SDK (which is provided by PayPal) fails to complete, yet the exact call works fine when the explorer calls it. Any help or advice would be appreciated.
So after nearly a month of fighting this issue with PayPal's merchant technical support (most of the time not getting any responses at all) and waiting nearly two weeks for a response on an escalation, it turns out the issue stems from the SDK configuration.
Although throughout the API docs and SDK code the Application ID is referenced as applicationId, apparently the SDK requires it to be entered in the config file as acct1.AppId instead. I only discovered this after coming across this wiki page on configuring the SDK, which didn't even exist 24 hours ago.
Once I updated my config, I was able to authorize the payment without error.
I encountered another cause that can cause this exact problem with Chained Payments.
Here's how my chained payment was setup.
Main account received 100%.
Referring account got 50% from that.
Partner 1 account got 10%.
Partner 2 account got 10%.
Partner 3 account got 10%.
Partner 4 account got 10%.
10% remained in main account and paying the transaction fee.
This worked perfectly in sandbox (with normal prices), absolutely perfect, but I got this error in Live.
What was happening was a final, pre-announcement, test of Live, we were using a transaction amount of $1.00 and sending $.50, $.10, $.10, $.10, $.10 and leaving $.10 to pay the $.33 fee. (At time of writing, paypal charges 2.9% + $.30). All the answers around the internet were not solving the problem in our case, but this did. Changing the transaction amount to $5 (for testing) worked fine because it left $.50 to pay the $.45 fee ($.45 fee for $5).
Related
Since few days the adaptive payments (both preapprovals and chained) seems to be broken.
When we send the user to paypal to complete the order (chained) or to authorize the preapproval (preapprovals), they get a generic "invalid transaction" error. Tested the flow, we get the same error and looking to the console we can see this error on the checkout.js file in the paypal object directory:
Uncaught TypeError: PAYPAL.AP.Subflow is not a constructor
at checkout.js:11
(anonymous) # checkout.js:11
Seems something has broken on paypal side.
Anyone with the same issue? Workarounds?
Cheers, Fil
We've finally figured out what was wrong.
Trying the complete debugging of the call to the svcs endpoint we've discovered that since few days (first time from 2013), we started getting an odd response from the paypal server to our SOAP request as:
{"faultstring":"Unknown Content-Encoding","faultcode":"HTTP"}
We've then thought to some issue in the "transportation" of the call to paypal servers and we've tryed to add something in the headers.
First, we discovered that in our http header request some line that we've never used before was missing, for example:
"X-PAYPAL-DEVICE-IPADDRESS: " . $_SERVER['REMOTE_ADDR'] . "\r\n" ;
But this didn't solve the issue.
Then we've added a new line in the soap client array:
'compression' => SOAP_COMPRESSION_ACCEPT,
Adding this solved the issue but no one ever adviced us about the requirement of this part of the code. Probably, this is a linux issue, maybe paypal has changed some server with a newer one and while the older accepted the SOAP request even if it was not with this "compression" parameter, in the newer environment it seems required.
Anyway, everything is back to normality adding this line, we just still have an odd time response (long) for the Pay operation while everyting is smooth for the Preapproval operation but this might depend on different paypal servers managing one or the other operation.
We use the https://financialdatafeed.platform.intuit.com/v1/accounts/account_id_goes_here/transactions endpoint on a recurring basis to fetch transactions for all of the accounts we sync. We've been using this stably for quite awhile now, across a wide variety of accounts spanning 100s of financial institutions. This works great.
However, occasionally we get a report from a user who claims that we're not receiving transactions that they know to exist. Our investigation protocol is as follows:
To ask the user if they see the transactions when they sign into their bank's web site directly
To ask them to confirm that the credentials they used on their bank's web site are precisely the ones that they entered when setting up credit card sync on our site
We then manually inspect the response body from the above mentioned URL, to make sure that the HTTPS response indicates HTTP 200 and has a non-error response body (our app catches these errors correctly, but if debugging mysteriously missing transactions, we inspect the response body visually).
We look to see whether we're successfully syncing transactions for any other user that relies on the same FI. If we are, we become confident that both the bank and Intuit APIs are well-behaved, and that the problem is on our end somehow.
We sometimes ask users to try the same FI in Mint, guessing that if it fails in Mint, that it might be a bank or FI issue.
Investigation steps 1-2-3-4-5 tease out the root cause of at least 99% of the times when a user emails us to say that we're not successfully receiving their transactions. However, the remaining 1% are the tricky ones.
Today I'm faced with a situation where a user sees the txns on their bank website, swears that they are using the same creds when adding the card to our site, the HTTP response from the endpoint is HTTP 200 but contains zero transactions, but yet when the user tries via Mint they successfully see transactions.
However, the particular FI (OnPoint Community Credit Union) is not one where I can do investigation step 4, because we have no other users that currently rely on that FI. Is it possible for someone at Intuit to check to see whether there is evidence that users relying on OnPoint Community Credit Union are currently, successfully, retrieving transactions from that particular FI?
Any other suggestions for how to further deduce whether the zero-transaction response is due to: (a) user error, (b) bank server responding incorrectly, (c) Intuit server responding incorrectly, vs (d) our app behaving incorrectly?
Can you please submit a support ticket to Intuit with the Account_ID that is missing the transactions so that we can diagnose the issue? The first place to start when diagnosing the issue is to look at the Agg_status_code to make sure that reflects a '0'. If we are unable to login due to invalid credentials or MFA might be a cause of the missing transactions. I can help diagnose though once a ticket is submitted.
been trying to wrap my head around an issue I have with the IPN tester, not 100% sure if its my hosting company's problem or Paypal Developer 'beta' to be honest but my IPN's have worked fine on a few sites I have for atleast a year and now it doesn't on any of them. I've not changed anything and now im getting
IPN Delivery Failed:I/O error: www.mywebsitesname.co.uk; nested exception is java.net.UnknownHostException: www.mywebsitesname.co.uk
and none of my NotifyUrl.ashx handlers are working.
any ideas what this actually means in english? any more info. from me required to help you diagnose my issue?
#
AS AN UPDATE (27-08-2013), I thought I would try out the original C# SDK sample code from Paypal that I used to set up my IPN's with about a year or three ago (ie. it worked great with the IPN simulator). I have put it onto two different hosting companies servers to check its not an issue with a particular hosting server and my results using the IPN Simulator show "error 500: internal server error" for one and "IPN Delivery Failed:I/O error: www.ang##########.co.uk; nested exception is java.net.UnknownHostException: www.ang############.co.uk".
In short, I have the same identical sample file from Paypal (that used to work) in the root of each hosting companies servers and im using the same IPN simulator settings, with the exception of the IPN handler URL has the webaddress of the server followed by '/Handler.ashx' (which is the handler file) but i'm getting different errors.
Also to make this a bit more interesting, today I correctly received an IPN from Paypal to one of the same hosting server webaddress, with a 'transaction_subject : PayPal money request from xxxxxxxx' which was received and processed by my existing IPN handler (not the sample one from Paypal) and returned the correct info. to receive 'IPN Response: VERIFIED DateTime: 27-08-2013 19:05' so this got through and worked fine.
So in conclusion, I wonder if Paypal have either changed something and not informed the community or have an issue with their IPN simulator / CART IPN. If anyone can help or if a Paypal support engineer would like to work with me to try out some code, etc, please get back to me as I will keep trying to solve this but to be honest I see not what else I can do from my end as I've seen working IPN and a non working IPN simulator.
As extra info. here is an IPN Message as from my sandbox seller test account, that can't get through to my IPN handler on one of the same hosting servers (returns error 500) yet this used to get through and nothing has changed.
'mc_gross=2.75&protection_eligibility=Ineligible&address_status=confirmed&item_number1=BabyGrow2&payer_id=KHJGBQZNAFB7L&tax=0.00&address_street=1 Main St&payment_date=14:34:07 Aug 27, 2013 PDT&payment_status=Pending&charset=windows-1252&address_zip=95131&mc_shipping=0.00&mc_handling=0.00&first_name=Test&mc_fee=0.28&address_country_code=US&address_name=Test Buyer¬ify_version=3.7&custom=1csi4t45gy4gkz45r5r4t0ey&payer_status=verified&business=wow####gmail.com&address_country=United States&num_cart_items=1&mc_handling1=0.00&address_city=San Jose&verify_sign=AFcWxV21C7fd0v3bYYYRCpSSRl31A1fBAmiE5lcDRsQKQNaqoyQI7ucQ&payer_email=wow#######gmail.com&mc_shipping1=0.00&tax1=0.00&txn_id=8SG98957G0030294Y&payment_type=instant&last_name=Buyer&address_state=CA&item_name1=Baby Grow Age 0 - 1&receiver_email=wow#########gmail.com&payment_fee=&quantity1=1&receiver_id=8QRMB3QFHCL56&pending_reason=paymentreview&txn_type=cart&mc_gross_1=2.75&mc_currency=GBP&residence_country=US&test_ipn=1&transaction_subject=1csi4t45gy4gkz45r5r4t0ey&payment_gross=&ipn_track_id=7b4507c8c4313'
Still hoping we can resolve this soon.
Many Thanks.
Trev.
Asp.net / C# / HTML / CSS3
My application uses the SetExpressCheckout paypal classic API method. It is working fine when I use real accounts in a live environment.
It used to work fine using test accounts, but some weeks ago it has stopped working right. At some point, my application calls the "SetExpressCheckout" API method using curl in PHP. When I use the test seller account that I've always used for my tests, I always get the following error:
SetExpressCheckout API call failed.
Detailed Error Message: Security header is not valid
Short Error Message: Security error
Error Code: 10002
Error Severity Code: Error
I know that paypal has recently restructured its "developer network", and the issue seems to be caused by this but I have no proof of that. The API I used is now called the "classic" API.
I've read the documentation, and it says that I now have to create a new "real" paypal account, and then use it to log to https://developer.paypal.com. I did that.
Once logged to the developer website, there is a feature allowing us to import all the test buyer and seller accounts used in an old sandbox account. I did that, and my old test accounts appeared in a list.
One of them is the test seller account I used to test. When I check the details of this account, the username, password and signature used to authenticate to the paypal API are there. If I use them, it still returns the previous error.
There is also a feature allowing me to create test accounts. I've created a new seller, and still, I get the same error message.
When I search on google about this issue, most answers says that the username, password or signature are wrong or have hidden white spaces in them. That's not my case.
I don't know how to solve that problem. I am wondering if the API endpoint has changed. I currently use "https://api-3t.paypal.com/nvp" for tests. I am using the NVP API, version 64.
To make it short:
1) My test account used to work
2) The code has not been modified
3) Real accounts used to work and still work.
4) But test buyer account has stopped working
5) The issue chronologically coincide with paypal "developer network" restructuring.
6) I don't know what has changed exactly and might cause this.
7) Does anyone know what has changed and might has caused this (a new parameter in the query string? Endpoint URL changed?)?
8) According to my previous description, do I seem to have misunderstood something, and what?
I currently use "https://api-3t.paypal.com/nvp" for tests.
That's your problem. You're using test credentials, but the live API endpoint.
Change your endpoint to https://api-3t.sandbox.paypal.com/nvp and all should be fine.
Security header is not valid means that your credentials are incorrect. I've never once seen that error where this wasn't the case.
You need to make sure that if you're using sandbox credentials for testing that you're hitting the correct endpoint and using the correct credentials.
Lots of times people accidentally have sandbox credentials set but then send them to the live endpoint or visa versa. If you're hitting the correct endpoint and your credentials are indeed correct you won't get this error.
After spending several hours trying to get django-paypal (originally dcramer's fork) to get a 200 OK response from PayPal IPN, I pinpointed the error to PayPal adding an empty, spurious &cmd= argument when using the IPN Simulator. If I leave the &cmd= in, I get a 400 Bad Request response when I try to postback; if I take it out I get a 200 OK but, of course, the postback is invalid because it's not what PayPal sent my server.
Of course, I'd be absolutely happy to do away with the IPN Simulator entirely and simply use Sandbox accounts, but those are broken too: the ones I create through the developer interface can't login (login failed errors); the ones I created through the "regular" interface on the sandbox site don't send any IPN whatsoever no matter what.
So, actually there's two questions here:
is there a way to work around the IPN Simulator &cmd= bug?
is there a way to make the sandbox accounts work?
A reply to either one would make me very very happy.
Many of the issues you've experienced are now cleared up. The IPN issue and some developer/sandbox log in issues have been cleared up as of Monday evening. If you are still experiencing any issues please let me know and I'll be more than willing to look into this further.