I am using the SagePayMVC (https://github.com/JeremySkinner/SagePayMvc) component in an ASP.Net/C# application to process payments on a website using SagePay.
Everything is working fine except that SagePay does not send notification emails to the vendor or customer on successful completion of an order.
I contacted SagePay support regarding this issue. they say that I am not passing the VendorEMail parameter to SagePay. But I am passing all the required parameters to SagePay.
The post request(captured using Fiddler on my development machine) that is made to SagePay
POST https://test.sagepay.com/gateway/service/vspserver-register.vsp HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Host: test.sagepay.com
Content-Length: 781
Expect: 100-continue
VPSProtocol=2.23&TxType=PAYMENT&Vendor=*&VendorTxCode=20&Amount=17.05&Currency=GBP&Description=Shopping+Basket+for&NotificationURL=http://****&BillingSurname=&BillingFirstnames=&BillingAddress1=b+add11&BillingAddress2=b+add2&BillingCity=b+city&BillingPostCode=WR2+6N&BillingCountry=GB&BillingPhone=1234&DeliverySurname=ghj&DeliveryFirstnames=ghj&DeliveryAddress1=d+add1&DeliveryAddress2=d+add2&DeliveryCity=d+city&DeliveryPostCode=WR2+6N&DeliveryCountry=GB&DeliveryPhone=1234&CustomerEMail=****&VendorEMail=emailaddress%40example.com&Basket=2%3a*++2%3a1%3a5.25%3a0.00%3a5.25%3a5.25%3aPostage%3a1%3a1.80%3a0.00%3a1.80%3a1.80&AllowGiftAid=0&Apply3DSecure=0&Profile=NORMAL
I have no idea why SagePay is ignoring the VendorEMail parameter even though, I am sending it.
Thanks in advance
Mathew
Thanks for the replies.
After interacting with SagePay support, I realized that I was using the Server Integration method instead of the Form integration method. Since I was being redirected to the SagePay site for entering credit card details, I assumed that I am using the Form integration method.
Thanks and regards
Mathew
Probably not what you want to hear, but it isn't working because Sage Pay will only send an email when using the Form protocol. You appear to be using Server, so will need to handle notifications to merchant and customer yourself.
Related
The following request does not result in 3DAUTH response (3D secure is enabled):
POST https://test.sagepay.com/gateway/service/vspdirect-register.vsp
VPSProtocol=4.00&Vendor=adventureworks&Currency=GBP&TxType=AUTHENTICATE&VendorTxCode=689359&Amount=158.00&Description=1%20x%20Membership;%20&Basket=1:Membership:1:131.67:26.33:158.00:158.00&CardHolder=Test%20Visa&CardNumber=4929000000006&ExpiryDate=0834&CV2=123&CardType=VISA&BillingFirstnames=Test&BillingSurname=TEst&BillingAddress1=88&BillingCity=london&BillingPostCode=412&BillingCountry=GB&DeliveryFirstnames=Test&DeliverySurname=Test&DeliveryAddress1=88&DeliveryCity=london&DeliveryPostCode=412&DeliveryCountry=GB&ClientIPAddress=10.13.10.191&BrowserJavascriptEnabled=1&BrowserJavaEnabled=1&BrowserColorDepth=24&BrowserScreenHeight=600&BrowserScreenWidth=800&BrowserTZ=0&BrowserAcceptHeader=text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3&BrowserLanguage=en-GB&BrowserUserAgent=Mozilla/5.0%20(Windows%20NT%2010.0;%20Win64;%20x64)%20AppleWebKit/537.36%20(KHTML,%20like%20Gecko)%20Chrome/76.0.3809.132%20Safari/537.36&ThreeDSNotificationURL=https://someurl.co.uk/join/callback3DSecure.asp&ChallengeWindowSize=02&CustomerEmail=test#test.com&contains=function(n)%20%7B%0D%0Afor%20(var%20i%20=%200;%20i%20%3C%20this.length;%20i++)%20if%20(this%5Bi%5D%20==%20n)%20return(true);%0D%0Areturn(false);%0D%0A%7D
Tried with BrowserJavascriptEnabled='0', same response.
What am I doing wrong?
I get a successful transaction created is SagePay with 3D response OK
Use CHALLENGE as Cardholder Name and you get the challenge window.
Use STATUS201DS to test the fall back to 3DSv1.
EDIT:
Documentation: DIRECT_Integration_and_Protocol_4_Guidelines.pdf
I'm trying to send a TrustPilot invitation using the Create Invitations API but no matter what I try, I get a response code of 415 and with no data returned, so it's virtually impossible for me to debug.
The URL I'm using is correct: https://invitations-api.trustpilot.com/v1/private/business-units/{businessUnitId}/email-invitations (where {businessUnitId} is my business ID)
I am sending a valid (and current) oAuth token in my header.
I am sending a POST request.
I have tested my details with other "Business user OAuth Token" APIs and everything works, so my details are definitely correct. It's just this create invitation API that's not working.
I've tried everything. I've submitted minimal details, a full request, somewhere in between, the example request in the API, and so on. Always a response code of 415.
I've set my "Invitation Settings" in the TrustPilot Business portal, and have even tried submitting those details with the request (ie. sender e-mail "noreply.invitations#trustpilotmail.com" and a valid reply-to e-mail that's been configured).
I've tried contacting the "Integration Engineers" at TrustPilot who after a few back and forth e-mails, also have no idea, which is VERY unsettling. So time for Stack Overflow.
I need to get this figured out, so any help would be great! Perhaps someone can provide a sample request that works in their application that I can try to duplicate in mine?
Http status code 415 (Unsupported Media Type) is returned when Content-Type: application/json is not passed. You need to make sure that this header is added and that the content you are passing in the post body is valid json.
If you are already doing this then I would need an example of a request you are sending to help you further.
I am trying to hit USPS address validation API by AJAX call and I am getting 'Cross-Origin Request Blocked' error.
However when I am trying to access the same address though URL, I am getting the results.
Has this error something to do with approval thing?
The id I am using for this has been approved and I am able to get the result by the API through URL.
I want to access it though scripting. Please help.
Any help would be appreciated.
Thanks in advance.
I think the way you might want to do this is to have the Ajax requests go to your web server -- the same HTTP server where the page came from. And then your server-side program (in PHP, or Python or whatever you're using) relays the request to the USPS server.
Making the request browser-side, from Ajax directly to the USPS server, is just the kind of suspicious activity (called Cross-Site Scripting) that browsers are learning to block.
CORS could theoretically be one way to unblock a Cross-Origin Request, but in that scheme it would be the USPS API server that ultimately grants that permission for pages from your domain. Tech detail: by inserting an Access-Control-Allow-Origin header in response to a request with an Origin header in the Ajax back-and-forth.
I am currently using Heroku's HTTP post hook add-on to send a message to my company's chat client, but now I want to do more with it. Is it possible to add multiple HTTP post hooks, so more than one service could be notified when a deploy happens? (no I don't want to receive emails).
Thanks!
-Doug
My friend Jared made an app for this: https://github.com/deadlyicon/deploy-hook-forker
Not right now - a workaround would be having a tiny app to receives your HTTP post hook and trigger all the HTTP hooks you need.
I'm starting with an address for an Exchange 2007 server:
user#domain.exchangeserver.org
And I attempted to send an autodiscover request, as documented at MSDN.
I attempted to use the generic autodiscover address documented at the TechNet White Paper.
So, using curl on PHP, I sent the following request:
<Autodiscover
xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/requestschema/2006">
<Request>
<EMailAddress>user#domain.exchangeserver.org</EMailAddress>
<AcceptableResponseSchema>
http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a
</AcceptableResponseSchema>
</Request>
</Autodiscover>
to the following URL:
https://domain.exchangeserver.org/autodiscover/autodiscover.xml
But got no response, just an eventual timeout.
I also tried:
https://autodiscover.domain.exchangeserver.org/autodiscover/autodiscover.xml
With the same result.
Now, since my larger goal is to use Autodiscover with Exchange Web Services, and since all of the EWS URLs typically use the same sub-domain as the Outlook Web Access address, I thought I'd see if the same were true for autodiscovery URLS. Since the OWA URL is:
OWA: https://wmail.domain.exchangeserver.org
I tried:
https://wmail.domain.exchangeserver.org/autodiscover/autodiscover.xml
And sure enough, I got back the expected response.
However, I only knew the OWA sub-domain because it's the server I have access to and that I'm using to test everything. I would not know it for sure or be able to guess it if this were a live app and the user was entering in their own Exchange email.
I know that the autodiscover settings must be available without knowing the OWA URL, because I can enter:
user#domain.exchangeserver.org
into Apple Mail on Snow Leopard and it finds everything without trouble.
So the question is...
Should https://domain.exchangeserver.org/autodiscover/autodiscover.xml have worked, and I just missed a step when trying to connect to it? Or,
Is there some trick (maybe involving pinging the email address?) that Apple Mail and other clients use to resolve the address to the OWA subdomain before sending the autodiscover request?
Thanks to anyone who knows or can take a wild guess.
After a bit more banging my head against the Google, I found the following very helpful article on MSDN:
http://msdn.microsoft.com/en-us/library/ee332364.aspx
Specifically the section "Calling Autodiscover"
I'm still trying to figure out how to do a Active Directory Service Connection Point search via LDAP, but step 4, for my server at least, worked like a charm:
The application sends an unauthenticated GET request to http://autodiscover.contoso.com/autodiscover/autodiscover.xml. (Note that this is a non-SSL endpoint).
If the GET request returns a 302 redirect response, it gets the
redirection URL from the Location HTTP
header, and validates it as described
in the section “Validating a
Potentially Unsafe Redirection URL”
later in this article.
Sure enough, a request sent to:
http://domain.exchangeserver.org/autodiscover/autodiscover.xml
sent back a 302 redirect URL:
https://wmail.domain.exchangeserver.org/autodiscover/autodiscover.xml
But this article gives a series of steps, so anyone wanting to implement autodiscover for an Exchange client has 5 things to try before giving up.