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
Related
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.
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 trying to integrate PHP-PayPal-IPN (great library btw, you can see the blog post on usage here).
Since security is essential here, I have checked the source code. I found no apparent problems with it, but I would also like to check the PayPal certificate chain that is bundled with the library: https://github.com/Quixotix/PHP-PayPal-IPN/tree/master/cert
How can I check that the certificate chain is correct? (correct == "it allows only connections from PayPal and from nowhere else")
I don't think that's the point of it. That SSL just allows you to setup your IPN script on a secure server so that the data is encrypted. To my knowledge it's not going to block hits to the script that don't come from PayPal's server.
That's where the verified/unverified check comes into play. If the data comes from anywhere other than PayPal it will fall into the unverified portion of code. You can choose to handle these however you want. Completely ignore them, log them as invalid but keep them for your records, send yourself email notifications, etc.
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 just purchased an SSL certificate from my hosting provider, at the request of a bank I'll be doing Credit Card transactions with. As of yet, I'm not sure if I'll be sending my users to their site to do the transactions or if I'll just be sending CC information to their site to do the transactions. My confusion is in regards to coding a developing my system. I'm building a very simple photo purchasing website, so I've opted to design my own shopping cart system. At what point do I need to utilize the SSL? Is there some sort of PHP code I'll have to use to decrypt the data sent to me via POST? Do I need to utilize it at all, or is the work already done for me by simply having a certificate (as verified by the little lock that appears in Safari)?
Thanks!
You typically don't need to deal with the server certificate in the application logic. Just configure it into the web server; configure the application in the web server to use https.
How to do that is off-topic for StackOverflow (I'm still responding to confirm that you don't need to deal with it in PHP).