I am trying to upgrade sage pay version from 2.22 to 3.00 and I am using Form Intergration to submit the values to Sage. The codes written VB. In 2.2, it was using "SimpleXor encryption algorithm", but that doesn't allowed in version 3.00 and as a result, I am getting the below error message:
This transaction attempt has failed. We are unable to redirect you back to the web store from which you were purchasing. The details of the failure are given below.
Status: INVALID
Status Detail: 5068 : The encryption method is not supported by this protocol version.
I found, version 3.00 allowed only AES encryption. Is there any sample AES encryption code to fix this issue?
Thank you in advance.
This has been asked before, and there are some really helpful posts under the sagepay tag, so I recommend having a look through those. There is also a classic asp example located here which you might be able to recycle (it originated in one of the old Sage Pay integration kits).
You will also need to check the fields you are sending over - addresses are now split over several lines, and some stuff that wasn't mandatory, now is.
Also note that test and live encryption passwords are different. You can get these from My Sage Pay if you log in under the main admin account.
And finally, if you get the 3045 'Currency' error, it's probably nothing to do with currency and more likely your encryption is wrong.
Related
My code for my PayPal integration has worked for a decade or so with no problems.
Today I've generated a new public certificate as the old one was due to expire. I did it exactly the same (documented) way that I've always done it, and uploaded it to PayPal. Stupidly, I deleted the old one before testing the new one.
And now I get this message when I try to make a purchase:
The email address for the business is not present in the encrypted blob. Please contact your merchant.
Any idea what's happened? My only thought is that PayPal are trying to force me into using a more modern way of integrating their payment gateway with my site, and are giving this error based on me having a newer public cerficiate now. But PayPal, if that's really what it's about, have a link to a help article on the subject FFS!
I'm stumped, any suggestions welcomed.
If you have this problem it might be worth checking the file permissions of your new private key. Mine was 600 and needed to be changed to 644 to match the old outgoing file. Problem solved.
paypalfunctions.asp and expresscheckout.asp files
I'm hoping to find help, and if not help then a developer for hire who is proficient in Classic ASP and PayPal and can help me resolve this.
We have a Windows 2008 R2 Server running Classic ASP. We have been sandbox testing development for over a year now and recently all PayPal Express Checkout "posts" seem to have stopped and now when you click the buttons to take you to expresscheckout the screen goes blank. White. Returns absolutely nothing.
So this would mean that either PayPal seems to have stopped or changed the way its working with WinHTTP.WinHTTPRequest.5.1 or our server has somehow updated itself?
PayPal is using WinHTTPRequest.5.1 in Classic ASP for sending NVP's with its Express Checkout.
We are using Classic ASP with IPN notification with API Signature.
When On Error Resume Next is removed in paypalfunctions.asp I get the following error;
500 Error - Description: An error occurred in the secure channel support.
Error Code: 80072f7d. Line: 176
Adding
objHTTP.Option(9) = 128
to the WinHTTP Request and
response.write(nvpStrComplete)
returns
METHOD=SetExpressCheckout&VERSION=93&USER=sdk%2Dthree%5Fapi1%2Esdk%2Ecom&PWD=QFZ
CWN5HZM8VBG7Q&SIGNATURE=A%2DIzJhZZjhg29XQ2qnhapuwxIDzyAZQ92FRP5dqBzVesOkzbdUONzm
OU&L%5FPAYMENTREQUEST%5F0%5FNAME0=My Order&L%5FPAYMENTREQUEST%5F0%5FDESC0=My
Item&L%5FPAYMENTREQUEST%5F0%5FAMT0=4&L%5FPAYMENTREQUEST%5F0%5FNAME1=Handling
Fee&L%5FPAYMENTREQUEST%5F0%5FAMT1=0%2E42&PAYMENTREQUEST%5F0%5FPAYMENTACTION=Sale
&PAYMENTREQUEST%5F0%5FCURRENCYCODE=USD&PAYMENTREQUEST%5F0%5FAMT=4%2E42&RETURNURL
=http%3A%2F%2Fwww%mysite%2Ecom%2F%23paymentcomplete&CANCELURL=http%3A%2F%2Fwww%2
Emysite%2Ecom%2F%23paymentcancel&ALLOWNOTE=0&BUTTONSOURCE=PP%2DECWizard
This looks ok to me?
Does anyone know how I can workaround WinHTTP.WinHTTPRequest.5.1 using the paypalfunctions.asp standard output Wizard Integration code?
Or if not and this is no longer an option can recommend a professional and competent Classic ASP / PayPal developer so he/ she can work/ revise with our existing code?
Just to summarise the comments.
The error points to an issue with the secure channel which often is related to the wrong protocol being used to call the endpoint.
This does not mean that the WinHTTP.WinHTTPRequest.5.1 doesn't work it just means the wrong protocol is being used to make the HTTP request.
Due to the POODLE internet security vunerability in SSL 3.0 PayPal informed their users that support for SSL 3.0 would be disabled starting with the SandBox.
Quote from PayPal - Required security update
How is PayPal responding?
PayPal will completely disable SSL 3.0 support in a timeframe to be announced via PayPal Notify; however, based on security monitoring, we may need to move quickly to protect our customers so time is of the essence in making changes. Unfortunately, we realize shutting off SSL 3.0 may cause compatibility problems for a few of our customers resulting in the inability to pay with PayPal on some merchant sites or other processing issues that we are still identifying. To enable your assessment and potential remediation, we’ve put together this Merchant Response Guide to ensure your integration is secure from this vulnerability.
The workaround is to use TLS which should allow you to connect to the endpoint without a problem.
You can do this using the WINHTTP_OPTION_SECURITY_FLAGS with the Option property of the WinHttp.WinHTTPRequest.5.1 object.
'The WINHTTP_OPTION_SECURITY_FLAGS option
Const WinHttpRequestOption_SecureProtocols = 9
'Valid WINHTTP_OPTION_SECURITY_FLAGS option flags
Const SecureProtocol_SSL2 = 8 'SSL 2.0
Const SecureProtocol_SSL3 = 32 'SSL 3.0
Const SecureProtocol_TLS1 = 128 'TLS 1.0
Const SecureProtocol_TLS1_1 = 512 'TLS 1.1
const SecureProtocol_TLS1_2 = 2048 'TLS 1.2
You can then modify your WinHttp object (assuming the object is called winhttp) like so to switch the secure protocol;
winhttp.Option(WinHttpRequestOption_SecureProtocols) = SecureProtocol_TLS1_2
Note: Some versions of Windows Server do not support the SecureProtocol_TLS1_2 flag or may require an hotfix. It really depends on what version of winhttp.dll is installed on the system.
Useful Links
Classic ASP / IIS6 / Win2003 Server can't communicate with TLS server
WinHttp errors on option 9 / Win2008 / Classic ASP
WinHttpRequest object
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!
I'm looking to use a PayPal hosted Gateway page to accept payments for a site I'm working on (based in the UK)
After a lot of difficulty, I've managed to set up an test-only Payflow account using this guide: https://www.x.com/developers/community/blogs/pp_integrations_preston/testing-paypal-payflow-gateway
But when I log in and try and change the hosted checkout settings to "test", I'm getting:
"Error: 102 error content"
and no settings will update.
I can find anyone else who's seeing this same error message, but PayPal's documentation doesn't mention this error in the manager, but says that error 102 with transactions is the payment processor not being available - so I think there's a chance it's that.
The guide I used to set up the account only linked to a US version of the registration page, so I just changed the countrycode parameter in the query string attached to the link so I could use a UK address, but the Payment Processors all seem to be based in the US, I've tried 2 different ones (FDMS Nashville and WorldPay) and I'm getting the same error on both.
I've had so many problems trying to set this up, I've been reading various guide and the official documentation solidly for 3 days and haven't even opened my IDE yet - what am I doing wrong?
Do you have link to your checkout that you can provide, so that we could walk through and test it and see what the issue may be? It's hard to see say what the issue is at this point, with out seeing what you are passing over, where at specifically the error is getting generated at during the checkout, and without knowing how your account is set up.
I am getting the response as below.
{"status":21002, "exception":"java.lang.NullPointerException"}
I am encoding the receipt using Base64 only.
I am testing it in sandbox.
What will be the problem? Can anyone help me?
hi all i got the solution
just send the receipt data after encoding into base 64 as json with key "receipt-data"
VIP Worth noting that 21002 is also the message you get back when trying to verify a transaction that was initiated via rooted iTunes hack software like the Urus app.
We verify all transactions server side, so are not device dependant, the only transactions that get the 21002 response are ALL not real payments.
an easy way to spot it to look at the transaction id returned Urus gives com.urus.iap.XXXXXXX (x being random numbers), other ones include returning the pack name as the completed transaction id, all very different to the id's you get from the various iTunes servers.
I can't recommend more that everyone verifies server-side in an environment you can control, test and prove, that cant be manipulated (unless your hacked). If this is not an option, then do not pay out on a 21002 response.
verifying in a java environment the json response for the 21002 will be:
json: {"status":21002,"exception":"java.lang.ClassCastException"}
We had the same problem - until we discovered that we didn't include the post body in the request and only sent an empty request.
The only option that work for me after 2 days of hitting my head against the wall:
Testing in the sandbox
Pay attention to this advice by apple
"Important Do not sign in with your test account in the Settings application."
Make sure on the test device you are signed out of the "test" apple store account before encoding to base 64.