I've inherited this project where the user's credit cards are saved via the Sagepay token card details iFrame. The token used is retrieved through the 3.0 protocol.
The form iFrame is loading fine as you can see here:
But when I try to submit a test card, it fails with Server error 5003: Internal server error.
I can't really debug this as everything is happening on the Sagepay side and the error is so broad.
Any ideas of why this could be happening?
Thank you!
I suspect this is a failure to reach your notificationURL (that usually manifests itself as a 5006 for a standard transaction, but is 5003 when registering a token).
Make sure your notificationURL is externally accessible, isn't using a port number (Sage Pay will only communicate over http/https default ports 80 / 443), and all your firewalls are open - I think test notification posts originate from IP 195.170.169.29 if that helps.
Related
I am debugging a web app that communicates with a secure payment gateway provided by my client's bank. The secure gateway works the following way:
The end user's browser is redirected to the bank's website, where he has to input his credit card number.
If the authentication is successful, the bank's server (not the end user's browser) opens an HTTPS connection to an URL in our site, with the transaction data.
Our site needs to respond to that HTTPS connection with the string "OK", and mark in our DB the transaction as paid. If our site doesn't respond, the gateway shows an error message to the end user, and the payment process is considered failed.
Then, the end user's browser is redirected from the bank's site to our own.
Anyway, the gateway has recently started showing intermittent errors. What's going on is:
The orders get marked in our DB as paid.
I check our server logs, and I see the connection from the bank's server, and I see an 200 response from our web server.
...and yet, the bank's gateway claims that the operation has failed because our server hasn't responded correctly.
So, what I'd like to do is to capture the HTTP dialogue between the bank's server and our own, to see what's going on exactly... but our site is hosted on a shared server (it's a standard LAMP stack). I obviously can't install anything on the bank's server to log the session from their end; is there any way to do so from our server's side?
(If it helps, our web app is written in PHP, so if there's some instruction that allows us to dump the raw HTTP dialog, that would be good too).
EDIT: to be clear, I don't need only the HTTP request that I'm receiving from the bank's server, but also the HTTP response that my app is sending back. I need to be able to verify independently that my app is indeed sending back the correct "OK" string, and there isn't some subtle bug that we missed.
I am new to using Square APIs and am attempting to integrate the PHP version of the API into a website.
I have followed the instructions on their site to the best of my ability, utilizing Sandbox credentials including the location ID. The payment form is created, I fill in the form using the fake credit card information provided in the documentation, I receive the javascript alert indicating the nonce has been created, but receive the following error:
Caught exception!
Response body: null
Response headers: null
Can you please provide me with some guidance on how to fix this?
Square Connect Only allows connections from secure sites. Make sure your site has ssl certificate installed.
My guess is you are testing on localhost, in that case you try to generate the self signed certificate. Although I dint try generating my own certificate. I just tested it on live website with ssl certificate and that error was gone.
If you are using the php api v2 sample try printing out the full response by placing print_r($e); in the catch block and view the full description of your errors. Thats how I figured out the problem.
Hope it helps.
I am creating a php application with the Coinbase API and the blockchain.info API. My (000webhost.com) webhost's communications with coinbase.com and blockchain.info API servers are getting a HTTP 403 CloudFlare Captcha. This completely cripples the API. I tried connecting with HTTPS, and tried changing the user agent, tried curl(), tried file_get_contents(), but I can't seem to get a real response from the API servers.
This is the error I get:
http://s10.postimg.org/ff8ggm6yx/Cloud_Flare_error2.jpg
Thanks for any help, I've been trying to figure this out for days.
The captcha is a security challenge page presented based on the security settings selected by Coinbase. Either the IP you're using or the user agent you're sending triggered the security challenge page here. If you complete the captcha (in a browser) a cookie would be temporarily set indicating you've passed this security challenge page successfully. Your best bet would be to contact Coinbase's support folks if you are still seeing this issue, and request that they consider whitelisting your IP address so that in the future you wouldn't receive a security challenge page like the one you indicated.
Disclaimer: I work at CloudFlare.
I am working on localhost and testing payment for paypal sandbox. But I am not able to get the response from paypal.
Thanks
Actual Testing of PayPal IPN
In order for PayPal to send an Instant Payment Notification, you must provide them (either as a parameter on the purchase/transaction, or as part of your IPN Settings under the account being paid) a URL which they can notify. This URL must be accessible from the internet, so is preferably hosted on a publicly accessible server, and with an address like http://www.yourserver.com/paypalIPN.php
Hosting an IPN listener on a server which is not accessible from the public internet, like under "localhost" on your own computer, will be impossible for the PayPal servers to contact, and so no IPN messages will be recieved.
Callback to PayPal to Confirm IPN
If you are getting the PayPal IPN requests (they will normally be a POST request with a number of parameters), but you are having trouble calling PayPal back to confirm the transaction details, then this suggests that your server is having trouble making calls out to the internet.
This may be due to a configuration issue in your Webserver software, a firewall issue on the server, or a network issue. The first check would be to create a PHP file and attempt to use cURL or file_get_contents() to call and return a webpage, like Google's main page. If these calls work, then it may be a configuration issue specific to your IPN Handler.
There are a number of Open Source IPN Handlers available, which makes deploying a PayPal-backed payment system much easier. Just jump on Google and have a look around.
I'm doing a website with Realex as the payment gateway. I want to integrate remote realex payment method in my website.
I know when we go live we need SSL enabled on our website to do remote method payments. But my question is, Is SSL required when we are doing testing?
Every time I test, it results in error (remote method), but when I do Real Auth method there is no problem.
I don't know what the exact problem is. Am i missing something?
No. We use Realex, and don't use SSL on our test sites.
In fact, if we don't use SSL on our live sites, it still generates no error. Realex doesn't actually have any way to know whether or not you're using SSL.
As TRiG has already said, Realex have no way of telling whether or not you have SSL on your website. However, your customers will not feel safe entering card details if they don't see the little padlock, and this will affect your sales conversion.
Communications between your server and Realex are https/SSL, so this is secure, but the card data must first get from the browser to your server securely. You may prefer to use the Realex Redirect integration if you do not want to buy an SSL cert.
Owen
at merchant site in live / testing ssl is not required
it results in error . may be due to
your response URL is not set
or you are trying to get the response from local host
to set response URL have to contact Realex support ...
it is the same as we do in papal notify
what response URL we send that is to compare not to set