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.
Related
I spent the last day and a half researching this problem to no avail. I found many similar problems, but none that exactly address my issue. I am attempting to integrate Payflow Pro with transparent redirect, but cannot successfully complete a transaction. I am using the test environment with a test Payflow Gateway account.
I can successfully retrieve a secure token by posting the following from my test server to https://pilot-payflowpro.paypal.com:
PARTNER=[hidden]&VENDOR=[hidden]&USER=[hidden]&PWD=[hidden]&TRXTYPE=S&TENDER=C&CREATESECURETOKEN=Y&SECURETOKENID=20180916085333999&URLMETHOD=POST&SILENTTRAN=TRUE&AMT=2&BILLTOFIRSTNAME=John&BILLTOLASTNAME=Doe&BILLTOADDRESS=123TestDr.&BILLTOCITY=Testcity&BILLTOSTATE=TN&BILLTOZIP=55511&BILLTOEMAIL=johndoe#test.com&USER1=3&USER2=&USER3=0&USER4=2
to which I receive the following response:
RESULT=0&SECURETOKEN=[hidden]&SECURETOKENID=20180916085333999&RESPMSG=Approved
NOTE: I have configured a Return URL using PayPal Manager, which is why RETURNURL is not included in the secure token request. However, I also have tried with RETURNURL specified, and I have obtained the same end result.
I use the results from the secure token request to create a cc collection form. I input test credit card details using acct# 5105105105105100, then post the following from the browser directly to https://pilot-payflowlink.paypal.com:
fund_id=3&ACCT=5105105105105100&CVV2=555&EXPMONTH=01&EXPYEAR=20&EXPDATE=0120&SECURETOKENID=20180916085333581&SECURETOKEN=[hidden]&feeTokenID=20180916085333999&feeToken=[hidden]
The response is properly redirected to the Hosted Page error URL I have specified in my Payflow Manager Service Settings. My problem is that I do not understand why it is redirecting to the error url with the following message:
RESPMSG=Failed to connect to host Input Server Uri = https://pilot-payflowpro.paypal.com:443
NOTE: The value above is only one part of the response sent to the error page. The rest of the return values include information from my original secure token request, which I would assume could only be returned if a successful connection had been established with the link in the error message??
To clearly state the problem:
I have already successfully connected from my test server to the link specified in the error message, when first I obtained the secure token.
The post that results in the error message was sent from the browser (in this case, on the same physical box as my test server) to https://pilot-payflowlink.paypal.com, which is not the URL specified in the error message.
Finally, the error seemingly occurs during the Payflow process - to my understanding, there should not be a call from my server or the browser to the link in the error message at this point during the process. I mention this specifically to address the many search results I found relating this particular error message to PayPal's requirement for TLS1.2, which is already properly configured on my server (I should mention for the sake of completeness, I do still have TLS1.0 enabled on my test server, but cannot disable it for unrelated reasons. Nonetheless, I was able to successfully connect to obtain a secure token, and my server passes PayPal's own TLS test at https://tlstest.paypal.com/).
I should mention that I also have tried to complete this same transaction on our production server, still using test credentials and test endpoints at PayPal, with exactly the same results. The test server is also set up for TLS1.2 with TLS1.0 enabled, and also passes PayPal's test.
This problem may be the one that pushes me full-on into insanity, so any help really would be appreciated!!
Disabling TLS1.0 has helped others with this issue. If you keep having problems, contact PayPal's support
For anyone who might find this question and be similarly frustrated, I want to share that I was able to solve the problem by creating a new Payflow Gateway test account.
I spent a great deal of time on trial and error solutions with no success, and PayPal Merchant Technical Services was able to duplicate the problem but was also unable to find a solution. Finally, after simplifying my test app as much as possible (two bare-bones HTML forms filled in and submitted manually), I came to the conclusion that there might be something wrong with my test account. Upon creating a new account with new credentials, then inserting them back into my original code, everything worked perfectly.
As of this morning, PayPal MTS is continuing to research the problem, since others have reported similar issues.
For others with similar problems, it is worth noting that I am now able to complete transactions while TLS 1.0 remains enabled.
Like many others, we were frustrated by PayPal's lack of passing traffic source origination and getting all the conversion credit.
However, after adding PP to the referral exclusions list, now all we have is 100% of the conversions coming from direct/none. (We use PP as the exclusive checkout method)
So now while we have traffic that looks clean, the goal completion data is rendered useless as everything is direct/none.
Has anyone found a solution, other than switching to PayPal Pro?
This problem could not be solved by any PayPal configuration. User sessions are being broken before users get to PayPal. Since you're seeing direct traffic and not self-referrals, that means not only is the session being broken, but user continuity. Somewhere in a session on your site they're getting tracked as a new user (thus also inflating your user count).
My guess is that users arrive to the site on HTTP and then switch over to HTTPS (or switch to another domain) for the checkout process. To solve this, you can setup cross domain tracking (which is necessary even if using a single domain if the site is available on both HTTP and HTTPS). An even better option (but possibly a greater lift) would be to move the entire site to HTTPS.
My question is simple yet I can't find any SO posts or PayPal documentation to answer it.
In the event of a PayPal user having some error being redirected after completing their checkout (internet goes out, browser crashes, they close their browser before the redirect goes through, random networking issues, etc.) How are we suppose to handle that?
I thought using the following REST API
GET /v1/payments/payment/<Payment-Id>
Would solve my problem but since the state returned from this request does not change from created to approved until the funds have been executed it is useless. In the case of having some redirect error you will not have been able to execute the funds and thus it will simply be in the created state still which does not help you.
Additionally I thought maybe PayPals IPN system used for CLASSIC API would be the answer to my problem but again it fails. The IPN system does not contain relevant information such as transaction ID which is needed to link the two systems together.
Is there no way to do automated error handling using the REST API?
I have a weird issue with Paypal IPN. Every alternate transaction is failing. So let's say if first transactions goes well then second one fails. Similarly if 3rd one goes well then 4th one fails.
HTTP status code I am getting for failed transactions in IPN history is 400.
I have implemented the new Paypal host header changes that were newly introduced by them.
Any idea why this is happening?
IPN History
http://i.imgur.com/NfqRsGi.png
IPN Detail
http://i.imgur.com/hcKdasw.png
EDIT
I am using PHP with curl to do IPN work (using same sample code as available on Paypal website)
ANOTHER EDIT
Ok I found another code sample for PHP 5.2 from Paypal site. This one is slightly different than the one I am currently using. I tested it on Paypal Sandbox twice and it worked. Later on I will test it on live to see if it is working fine or not.
Error 400 = bad request, this means that the get requests being made on the application layer (by your browser) may contain errors or the transport layer (syn, syn, ack, syn) 3 way hand shack is being interrupted. I would check your PC for Mallware to be on the safe side. Do a netstat -b in dos and see what's trying to get connections to the external network.
Also do a scan with malware bytes and a good virus scanner like Eset nod32.. Let us know how you get on^^
The new script I downloaded from Paypal website fixed the issue.
After paypal updated their interface (sandbox.paypal.com for example is not working, now you have to go to developer.paypal.com) many of the things are not working: 2 of them are particularly frustrating and I was hoping someone here knew how to get around them:
Am I the only one whose sandbox customer test accounts are not able to make purchases? The transaction page says they are not available.
IPN validation is not letting me send a https request. When I do it says there is something wrong with the server name. Yesterday however before the update I could get verified status. If I dont put https, now my handler gives me an invalid responde status, code: 400. What does it mean?
To fix the HTTP 400 error, follow the instructions in https://www.x.com/content/bulletin-ipn-and-pdt-scripts-and-http-1-1 and update your code to pass "Host" information. Ideally, things should work with just the recommended changes from the above link. Apparently, thats not the case. Here is a fix from one of the PayPal MTS person - PalPAL sandbox IPN processor rejecting all messages?
Remove the "cmd=notify-validate" option from the validation URL. I tried this and it worked. Though it doesn't return the right string, atleast it doesnt break with the 400 error.
While we wait for a fix from Paypal, I wonder how a company like PayPal can cause such a huge blunder and not post anything on their status page - https://www.x.com/developers/paypal/documentation-tools/site-status/pp-cri. It just makes you think that even smaller companies can do a better job than companies like PayPal.
For the code:400 issue, you have to update the post to version 1.1. That information is located here.
https://www.x.com/content/bulletin-ipn-and-pdt-scripts-and-http-1-1 in this bulletin.
However, as I posted before the asp.net example uses a call, that does not exist, so I was only able to get mine partly working. After fixing this, the servers appear to be rejecting calls to https, or the cert they have installed is invalid.
Action Required before February 1, 2013
Merchants need to update their IPN and/or PDT scripts to use HTTP 1.1, and include the “Host” header in the IPN postback script. In addition to this bulletin, these merchants will be notified via a direct email.
Alright, seems to be fixed!
If you are having trouble logging in, like suggested above, clear cache and cookies and try again.
Regarding the error 400, seems to have been solved by paypal!