We are getting Error 3034 : The Vendor or VendorName value is required in SagePay test environment
We have checked that vendor name is correct
Live SagePay link is working for SagePay
Can you please let us know proposed solution to resolve this issue
Thanks in advance
I had this issue on Sage Pay Direct test, and it turned out to be the Content-Type not being set to application/x-www-form-urlencoded.
The documentation states that the body of the registration transaction must be URL encoded, but does not mention the Content-Type header. This is kind of obvious if you understand how these HTTP messages are going to be parsed, but can result in this very misleading error message from the gateway if not correctly set.
So basically, if you get error number 3034, and you do have the vendor field set correctly, then the problem is likely that the remote Sage Pay gateway cannot parse the body of the transaction in the HTTP message you have POSTed. In that case you need to look at the complete message being sent.
Related
I am doing performance testing of an e-commerce website.
After adding items to the cart it is going to the shipping page
and selecting the shipping address,after that it is proceeding for checkout
In the shipping page,it is giving the following error in the response data
{"status":400,"message":"Malformed request","additional_error":""}
Request is going POST and data as **JSON
How to resolve this error?
We don't know.
It is either a bug in your application or your HTTP Request you're sending with JMeter is really malformed and you need to fix it.
I would recommend capturing the same request to the shipping page originating from the real browser and JMeter using an external sniffer tool like Wireshark or Fiddler. The requests have to be exactly the same (apart from dynamic data which needs to be correlated). Given you send the same request you should receive the same response. Amend your request to 100% match what you see from the browser and the issue should go away.
In the 99% of cases REST requests are failing due to missing Content-Type header with the value of application/json or similar (sometimes charset has to be specified as well). You can add this (and other) headers using HTTP Header Manager
I am facing below error in respose,
<faultcode xmlns:ns1="http://xml.apache.org/axis/">ns1:Client.NoSOAPAction</faultcode>
<faultstring>no SOAPAction header!</faultstring>
i am trying to fixing in pipeline ,
selected pass all headers through pipeline but didn’t helpedenter image description here
Do you really need a SoapAction?
One of the options available in a proxy is to decide which operation a SOAP message is, by inspecting the message body.
If someone sends a message (perhaps through a biz ref) and doesn't include a SOAP action header, a proxy will still recover if it uses this method.
Sending a request using the Test URL for Standalone Token Registration, I am faced with an internal server error with no indication as to what the problem is.
HTTP Status Code: 500:
HTTP Status Message: The request was
unsuccessful due to an unexpected condition encountered by the server.
The Test URL I'm POSTing to is:
https://test.sagepay.com/gateway/service/token.vsp
And the POST parameters are as follows:
VPSProtocol = 3.00
TxType = TOKEN
Vendor = MyVendor
VendorTxCode = UniqueVenderTxCode
Currency = GBP
NotificationURL = Publicly facing url
I can confirm that the Vendor is correct because I can successfully POST to the "Part of a Transaction Token Registration" URL, which returns a NextURL that I use to display the payment portal/entry.
I'm sending all of the required POST parameters, so I'm not sure where I've gone wrong. I hope someone can point me in the right direction.
EDIT: It was me being silly. I neglected to check the response from the HttpWebRequest (You'd think this would be my first port of call). It turns out that the vendor I'm using doesn't currently support a TxType of TOKEN. I'll have to contact SagePay support in order to get this enabled.
I'm attempting to initiate a test transaction with sagepay by POSTing to https://test.sagepay.com/gateway/service/vspform-register.vsp
I've followed the documentation with regards to the format such a request should take, I've whitelisted my IP in the portal on the test environment and I'm using VPSProtocol=3.00 (Which are the two problems that I've seen reported to cause this) but I'm still getting a 5003 error.
I've spoken to support on the phone and POSTed to their showpost endpoint (https://test.sagepay.com/showpost/showpost.asp). It doesn't seem to be able to understand any of the details of my POST despite it being in a Name=Value format separated by &, URL encoding the values like the documentation dictates and providing all the required fields.
I've tried URL encoding the =s as well as the &s just in case I had misunderstood the documentation in that regards but it didn't make any difference.
I believe that I must be sending the body incorrectly somehow. I'd appreciate any suggestions anyone can give. The body I'm sending is below:
VPSProtocol=3.00&TxType=PAYMENT&Vendor=anyjunko&VendorTxCode=123&Amount=143.33&Currency=GBP&Description=TODO&NotificationURL=https%3A%2F%2Fstaging-nelly.anyjunk.co.uk%2Fvs%2Fsagepay-transactions%2F1%2Fsagepay-updates&BillingSurname=NameB&BillingFirstnames=NameA&BillingAddress1=1&BillingAddress2=Putney&BillingCity=London&BillingPostCode=SW11%209YZ&BillingCountry=GB&DeliverySurname=NameB&DeliveryFirstnames=NameA&DeliveryAddress1=1&DeliveryAddress2=Putney&DeliveryCity=London&DeliveryPostCode=SW11%209YZ&DeliveryCountry=GB
Update: I've now tried this with cURL and it worked correctly, but it doesn't work when I send it from Postman or from my code using akka http client.
The cURL command I used was:
curl -X POST "https://test.sagepay.com/gateway/service/vspserver-register.vsp" -d "VPSProtocol=3.00&TxType=PAYMENT&Vendor=anyjunko&VendorTxCode=123&Amount=143.33&Currency=GBP&Description=TODO&NotificationURL=https%3A%2F%2Fstaging-nelly.anyjunk.co.uk%2Fvs%2Fsagepay-transactions%2F1%2Fsagepay-updates&BillingSurname=NameB&BillingFirstnames=NameA&BillingAddress1=1&BillingAddress2=Putney&BillingCity=London&BillingPostCode=SW11%209YZ&BillingCountry=GB&DeliverySurname=NameB&DeliveryFirstnames=NameA&DeliveryAddress1=1&DeliveryAddress2=Putney&DeliveryCity=London&DeliveryPostCode=SW11%209YZ&DeliveryCountry=GB"
There are some requirements missing from the Sage Pay documentation which must be provided otherwise you will get a HTTP 500 Internal Error 5003
Documentation for Server Integration named
"SERVER_Integration_and_Protocol_Guidelines_270815.pdf" is available here:
https://www.sagepay.co.uk/support/find-an-integration-document/server-inframe-integration-documents
First make sure that you have followed the documentation to the letter, especially be careful to include all the mandatory fields and URLencode the values of the name=value pairs.
The following requirements are not mentioned in the documentation:
1 IP Addresses
The IP address from which you send your POST to ~/vspserver-register.vsp must be added to the whitelist on your account settings.
login to My Sage Pay here https://testportal.sagepay.com/mysagepay/login.msp using your administrator account (usually your vendor name)
Go to "IP Válidas" (sorry admin suite is in Spanish for some reason)
Click [Añadir] ("Add") button in bottom right
In the dialog that pops up enter your
"Dirección IP" ("IP address") - type "Whats my IP" into a Google search if you don't know it
your "Máscara de subred" ("Subnet mask") - 255.255.255.000
"Descripción" - just any name you want, has to be unique
Click [Añadir] ("Add") button
2 Firewall
Make sure your firewall is not blocking ports 80 and 443 for HTTP or SSL in either direction
3 HTTPS Protocol
Make sure that you are POSTing to the server using TLS version 1.0 or higher. Also make sure you can use one of the TLS protocols, at time of writing Sage Pay only supports these protocols
TLS1-AES-256-CBC-SHA
TLS1-AES-128-CBC-SHA
TLS1-DHE-DSS-RC4-SHA
TLS1-DHE-DSS-AES-256-CBC-SHA
TLS1-DHE-DSS-AES-128-CBC-SHA
TLS1-DHE-RSA-AES-256-CBC-SHA
TLS1-DHE-RSA-AES-128-CBC-SHA
4 HTTP Headers
There is only one HTTP header required, although it still works if you pass in extra headers such as "Host" or "Content-Length" it will fail if you do not provide exactly
Content-Type: application/x-www-form-urlencoded
What is optimal HTTP response Code when not reporting 200 (everything OK) but error in input?
Like, you submit some data to server, and it will response that your data is wrong
using 500 looks more like Server Issue
using 200 with warning/error response text is bad (allowing caching and everything is not OK)
using 204 and returning nothing, is maybe good (but well supported?)
using 404 is wrong if requested path (script) is available and in proper place
We had the same problem when making our API as well. We were looking for an HTTP status code equivalent to an InvalidArgumentException. After reading the source article below, we ended up using 422 Unprocessable Entity which states:
The 422 (Unprocessable Entity) status code means the server understands the content type of the request entity (hence a 415 (Unsupported Media Type) status code is inappropriate), and the syntax of the request entity is correct (thus a 400 (Bad Request) status code is inappropriate) but was unable to process the contained instructions. For example, this error condition may occur if an XML request body contains well-formed (i.e., syntactically correct), but semantically erroneous, XML instructions.
source: https://www.bennadel.com/blog/2434-http-status-codes-for-invalid-data-400-vs-422.htm
Codes starting with 4 (4xx) are meant for client errors. Maybe 400 (Bad Request) could be suitable to this case? Definition in http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html says:
"The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications. "
409 Conflict could be an acceptable solution.
According to: https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response body SHOULD include enough information for the user to recognize the source of the conflict. Ideally, the response entity would include enough information for the user or user agent to fix the problem; however, that might not be possible and is not required.
The doc continues with an example:
Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the entity being PUT included changes to a resource which conflict with those made by an earlier (third-party) request, the server might use the 409 response to indicate that it can't complete the request. In this case, the response entity would likely contain a list of the differences between the two versions in a format defined by the response Content-Type.
In my case, I would like to PUT a string, that must be unique, to a database via an API. Before adding it to the database, I am checking that it is not already in the database.
If it is, I will return "Error: The string is already in the database", 409.
I believe this is what the OP wanted: an error code suitable for when the data does not pass the server's criteria.
I recommend using 418 when client request something absurd that the server can't process. Like the server is a teapot but client is requesting coffee kind of stuff. Here is all the (400–499) client side error messages: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status#client_error_responses
404 - Not Found - can be used for The URI requested is invalid or the resource requested such as a user, does not exists.