I am busy with implementing payments using Sage Pay direct protocol 3.0
(4,0 unavailable yet as I understand)
I register transaction using vspdirect-register.vsp
I redirect user to ACSURL with MD, PAReq and TermUrl using POST
I catch user on TermUrl and check transaction status using direct3dcallback.vsp with MD and PARes
BUT on this stage I always get:
STATUS: 'OK'
AVSCV2: 'ALL MATCH',
StatusDetail: '0000 : The Authorisation was Successful.',
AddressResult: 'MATCHED',
PostCodeResult: 'MATCHED',
CV2Result: 'MATCHED',
'3DSecureStatus': 'ERROR'
Using MySagePay tools I get an explanation like :
3D secure status The authentication callback message was MALFORMED. No 3D-Authentication occurred! ERROR
Attempt 1
ECI result Unknown result type
How can I debug this error?
Is it normal that I get status OK even when 3DSecureStatus : ERROR ?
Q1: Why are you getting a 3-D Secure error?
The MALFORMED status points towards SagePay not being able to read your request .. (e.g it's syntactically or structurally invalid etc).
Given the lack of code in the OP, rather than try and guess what you're doing wrong, I'll instead show what we do (which works - we've implemented both v3.00 & 4.00).
We perform an HTTP POST with the following parameters to https://live.sagepay.com/gateway/service/direct3dcallback.vsp (or https://test.sagepay.com/gateway/service/direct3dcallback.vsp in the case of testing):
For direct protocol v3.00
VPSProtocol: "3.00"
MD: MD posted to TermURL (e.g 20156570522002324295)
PARes: "PARes posted to TermURL"
For direct protocol v4.00
VPSProtocol: "4.00"
VPSTxId: VPSTxId from the initial payment response (Note that curly brackets {} need to be removed!!!)
CRes: "CRes that was posted to the ThreeDSNotificationURL"
Q2: Why do you get an OK status when 3-D Secure failed?
I believe this is probably due to your merchant ruleset. You can state what you want to happen with the transaction if 3-D Secure is unavailable or fails.
So, check your ruleset. I believe that we force our consumers through 3-D Secure as our chargeback percentages were quite high otherwise.
Footnote
I would also concur that since you are doing this work, it would probably be more beneficial to implement version 4.00, since that means the majority of your customers should have a better experience, and you'll have a better conversion rate too. Win win.
HTH.
Protocal 4.0 is available on the SagePay test server and you can start working on that already. It needs to be implemented by the 14th of September 2019 and the last info I've got from SagePay support staff is that the protocal 4.0 will be on the live server by the 14th of September 2019.
To your probelm: I call the ACSURL with the added query string for MD, PaReq, TermUrl which works ok.
I see that you posted PAReq. Please note that I use PaReq. A small a instead of a capital A. See page 16 of the Documentation. DIRECT_Integration_and_Protocol_4_Guidelines.pdf
Maybe you could post the complete URL you post to SagePay.
Hope this helps.
Thanks guys!
Sage support have helped me to find issue.
The point was - route 'ThreeDSNotificationURL' make changes in 'CRes' as we have configured some security behaviors, and when we check this key on Sage side - we got an error. so some extra security behaviors for this route have solve the issue.
Thanks guys!
Related
I'm integrating SagePay Server and am stuck at step 4 here: https://developer-eu.elavon.com/docs/opayo-server/taking-payments
I get this error: Server error 5006: Unable to redirect to Vendor's web site. The Vendor failed to provide a RedirectionURL.
I know there are quite a lot of suggestions for this error out there. That it basically means there is something wrong with your code on the Notification URL.
I know it is completing the previous steps fine (I get the correct response parameters), I have made sure Opayo's IPs are allowed, the MD5 signatures match.
I think the problem is how I am "Responding to the Notification Post".
I am doing a standard WebRequest to send our RedirectUrl to SagePay - but the link here - SagePay RedirectURL failure - suggests it doesn't need that. Rather I should just "write to the simple Response object." The trouble is, I don't know what they mean by that.
Any help / experience with this, much appreciated.
Jon
I hope this answer isn't too late to be useful to you.
You're suffering from the main issue I've always had with Opayo (formerly SagePay) - namely that their integration guides for developers are terrible.
As the Opayo Server integration method is identical to the old SagePay version, I found it helpful to follow the much more in-depth instructions from before they rebranded. You can find those instructions here:
https://www.opayo.co.uk/file/12246/download-document/SERVER_Integration_and_Protocol_Guidelines_010814.pdf
In answer to your specific question, you can refer to page 68 of the above PDF guide. RE: You acknowledge receipt of the Notification POST, quote, "This is the plain text response part of the POST originated by the Server in the step above. Encoding must be as Name=Value fields separated by carriage-return linefeeds (CRLF)."
Literally, your script just has to print or echo something along the lines of:
Status=OK\r\n
StatusDetail=Hashes match - proceeding\r\n
RedirectURL=https://www.yoursite.com/endpointpage/
Or the equivalent for errors, aborts, etc.
Bear in mind that any output not formatted like the above will break the foldback process, so you must supress any errors or warnings your script might generate (ideally capturing them in a log or some other way).
Opayo give you basically no help in bugfixing, so if you continue to encounter errors you pretty much have to work in the dark.
I am working on a c# service that uses the V4.0 protocol of sagepay. I am trying to simulate a 3DAUTH request by passing in CHALLENGE as the Cardholder name.
It was working fine earlier this week but today the response status returned is OK and the 3DSecureStatus is ERROR.
Looking at the test MySagePay Fraud Results screen, there is a red shield with the message "The Authentication callback message was Malformed..."
I have set the ThreeDSNotificationURL to a page that doesn't exist but could the error be Sage is somehow trying to validate this page?
I was expecting a status response of "3DAUTH".
Any help greatly appreciated including any tips on getting more info from the mysagepay console error.
this is part of the message I am sending in
&ThreeDSNotificationURL= http://test.somepage.com/testpage.aspx
&UseDefaultValues=True
&BrowserAcceptHeader=Unknown
&BrowserLanguage=en-GB
&ChallengeWindowSize=03
&BrowserJavascriptEnabled=1
&BrowserJavaEnabled=1
&BrowserColorDepth=16
&BrowserScreenHeight=800
&BrowserScreenWidth=1500
&BrowserTZ=-60
&VPSProtocol=4.00
&TxType=PAYMENT
&Vendor=mycompany
&Currency=GBP
&ClientIPAddress=127.0.0.1
&BrowserUserAgent=Unknown
&Apply3DSecure=0
thanks
I think it (the test sandbox) is working again now.
You need the ThreeDSNotificationURL. This is the page the bank posts back to after the challenge.
There you have to get the post values for cres, VPSTxID and threeDSessionData from the form and post them to SagePay. Then handle the SagePay response to find out if the payment was successful or failed or if an error occured.
We have the same issue. Our code was working fine. We would pass "CHALLENGE" as the CardHolder and we would get the expected status but, at some point, we started receiving "3DSecureStatus=ERROR".
Has anything changed with the sandbox?
Seems to be working again now. Getting this response
VPSProtocol=4.00
Status=3DAUTH
StatusDetail=2021 : Please redirect your customer to the ACSURL, passing CReq.
VPSTxId={2FD68707-9DDC-76B8-2002-FBAE65F}
3DSecureStatus=OK
ACSURL=https://test.sagepay.com/3ds-simulator/html_challenge
CReq=ewogICJtZXNzYWdlVHlwZSIgOiAiQ1JlcSIsCiAgIm1lc3NhZ2VW
Must have been a blip on the test site. Be good to know if Sage post release notes for these instances so deployment history can be tracked.
For info, you don't need a valid ThreeDSNotificationURL when posting using Cardholder=Challenge.
Thanks all
I can't complete a transaction via the SagePay Test Environment when attempting to run through the "challenge" flow. I'm supplying the new PDS2 fields and using VPS Direct Protocol 4.00
I've triple checked the VPSTxId to make sure it's the one I received in the response to the first stage transaction. The CReq is also present and valid (I've Base64 decoded it and it looks reasonable enough to me).
Response from test system (first stage transaction):
"Status" -> "3DAUTH"
"3DSecureStatus" -> "OK"
"CReq" -> "ewogICJtZXNzYWdlVHlwZSIgOiAiQ1JlcSIsCiAgIm1lc3NhZ2VWZXJzaW9uIiA6ICIyLjEuMCIsCiAgInRocmVlRFNTZXJ2ZXJUcmFuc0lEIiA6ICJjMzY2NjEyMi04Yjk4LTRhNmEtYjlkZS01OGI2MWFkNjhhZTMiLAogICJhY3NUcmFuc0lEIiA6ICI5YjNkOGFkMS0yZDY3LTRjNjYtYmM4Yi02ZWQ1ZDIwYzk2OWEiLAogICJjaGFsbGVuZ2VXaW5kb3dTaXplIiA6ICIwNSIKfQ"
"StatusDetail" -> "2021 : Please redirect your customer to the ACSURL, passing CReq."
"ACSURL" -> "https://test.sagepay.com/3ds-simulator/html_challenge"
"VPSProtocol" -> "4.00"
"VPSTxId" -> "{2C04F723-BC87-3C7B-D805-DD4ED5B6BAFF}"
Request to test system (second stage transaction):
"CRes" -> "ewogICJtZXNzYWdlVHlwZSIgOiAiQ1JlcyIsCiAgIm1lc3NhZ2VWZXJzaW9uIiA6ICIyLjEuMCIsCiAgInRocmVlRFNTZXJ2ZXJUcmFuc0lEIiA6ICJjMzY2NjEyMi04Yjk4LTRhNmEtYjlkZS01OGI2MWFkNjhhZTMiLAogICJhY3NUcmFuc0lEIiA6ICI5YjNkOGFkMS0yZDY3LTRjNjYtYmM4Yi02ZWQ1ZDIwYzk2OWEiLAogICJ0cmFuc1N0YXR1cyIgOiAiWSIKfQ"
"VPSTxId" -> "{2C04F723-BC87-3C7B-D805-DD4ED5B6BAFF}"
Response from test system (second stage transaction):
"Status" -> "INVALID"
"StatusDetail" -> "5083 : VpsTxId provided in callback does not match transaction in CRes"
"VPSProtocol" -> "3.00"
I've tried submitting the second stage transaction with VPSProtocol (both 3.00 and 4.00) and without. No difference.
Any ideas? I expect the SagePay Test Environment is just broken, but there is also a possibility I'm doing something wrong ..
The challenge is not yet working on the SagePay test server for v4.0. I got an email reply from their support staff on the 24/07/2019 saying "At the moment there is not an option to test this. Further communications will be sent in due course." Haven't heard since. Tried it yesterday and it didn't work either. Hopefully they get this done soon. I do get an error 404. The response you posted shows Invalid and then Protocal 3.0. That would be the fallback and you would need the PaReq value and all the data they require for protocol 3.0. Basically 2 differnet codes.
EDIT:
I have posted answers on other questions relating this subject which can help with the integration.
3DSv2 Sagepay Direct Integration 'page not found' after correct challenge
3DSv2 Sagepay Direct Integration basics
If you search for SagePay on this site you can find all relevant questions and answers.
I am currently testing the changes for version 4.0 of the protocol for PSD2 using Direct Integration.
I am running under Visual Studio using a localhost website address.
When calling the SagePay payment endpoint with ThreeDSNotificationURL set as a localhost address (http://localhost:15536/Payments/ThreeDResponse) I receive the following error '3228 : The ThreeDSNotificationURL field format is invalid.'
If I change this field to a fully qualified domain (http://www.google.com) I no longer receive the error, but can't complete my testing.
Using localhost for the termurl in version 3.0 of the protocol works as expected.
I was attempting to work locally like your self and receiving the same issue. After speaking with support they confirmed that they will not accept "localhost". Also, the documentation suggests that HTTPS is a requirement, so this might also be a blocking factor.
I think someone suggested using ngrok as a means of tunneling external requests into your localhost, which is a good method to continue development locally whilst also being visible externally to services like SagePay.
Once I got passed the above issue, I got several more errors for other missing required fields as listed here; https://www.sagepay.co.uk/support/38/psd2-under-direct-integration (note that if BrowserJavascriptEnabled is true all conditional fields are then required)
Did you URL encode the ThreeDSNotificationURL in your post?
I send it like that and it is ok:
sb.Append(HttpUtility.UrlEncode("https://www.clientdomian.com/ac/ThreeDSNotificationURL.aspx"));
I run the site on my local IIS for development.
I recently had this issue and I wanted to document it here, because searching for this issue gives very little in terms of results.
I was getting this error code when i switched my Opayo/SagePay extension (MageNest SagePay for Magento) to 3ds2.
As it turns out, the full URL wasn't being sent. It was trying to send sagepay/direct/postBack?form_key=HZuYxgiEq9w2CNFB and NOT https://www.example.com/sagepay/direct/postBack?form_key=HZuYxgiEq9w2CNFB. It's partly my fault because there was a domain field in the config which was empty (it's not like the domain can't be retrieved automatically, huh) and partly the vendors fault because it was very badly documented.
So while this is a different problem for a different platform, I hope this helps someone.
I have searched the answers to similar questions asked about this SagePay error, and checked that the fixes don't appear to apply to my problem.
Specifically:
I am using a correct 2-letter country code for BillingCountry and DeliveryCountry.
I am POSTing VPSProtocol, TxType and Vendor as well as the Crypt value.
I have re-checked that I am using the correct encryption key from the MySagePay test portal.
Now I was using http://localhost:8084/app/success and http://localhost:8084/app/failure for my success and failure URLs, since I thought that although these are (obviously) not visible externally, it shouldn't matter since SagePay is re-directing at the end of its part of the transaction. (Is this assumption correct, or do these URLs need to be externally accessible?) Some of the answers have thrown doubt on this, so I changed them to an external website I own, and I still get the same error.
Another line of thought is that the client I am developing for has already gone live, and there seem to be hints that once you have gone live, you no longer have access to the test server (Is this true?)
Is there anything else I should be checking? (Additional info: I'm using the SagePay api (sagepay-api-1.2.2.0.jar and related libraries) to validate the form contents and encrypt them.
I used the integration from https://github.com/tolzhabayev/sagepayForm-php
I had this error (5080) and spoke to SagePay support and they guided me to the MySagePay portal where you can view Invalid transactions to be able to troubleshoot this error easily!
Hope this helps someone.
Chris Rickards
I had exact same problem and I tried everything that you described as well, one day after I found that the problem was in "VendorEMail" field, it had 2 email addresses separated by ;, once I removed second and left only one email everything worked.