When trying to refund a transaction on MySagePay (test mode, haven't tried live) I keep receiving the following error:
Failed refund attempt via My Sage Pay screens by [redacted]. Error returned was: 4020 : Information received from an Invalid IP address.
Since the information should be being received from Sage's IP addresses, I'm not sure why this is happening or how to fix it.
I've tried adding whitelisting the IP for test.sagepay.com and tried whitelisting my own computer's IP but neither worked.
Is this another case of Sage sending misleading error messages?
If so, what steps can I take to find out the real cause?
If not, what IP addresses do I need to whitelist to make their control panel work?
Found out the answer by looking at a different client's SagePay
For some reason, Sage didn't set its own IP addresses in the valid IPs when they set up the account
Adding the following solved the problem:
10.227.167.3
10.227.177.3
(Subnet Mask: 255.255.255.000)
Related
I checked my domain in mxtoolbox and found following errors/warnings:
dmarc Missing or Invalid Record
https The Certificate is invalid
smtp Reverse DNS does not match SMTP Banner
dns At least one name server failed to respond in a timely manner
dns SOA Expire Value out of recommended range
I added a txt record in DNS zone for as "_dmarc" and checked it
nslookup -query=txt _dmarc.mydomain.com
its showing our server IP
Please advise how can I fix all these errors or warnings?
Best regards
#lifesaver That's a tall order without knowing what your domain is to evaluate.
But here's your general answers.
If you're missing a DMARC Record in DNS Add it. If it's invalid we need to know what you added
Why is the certificate invalid?
You need to make it match for smtp (Also it's a good idea to make it match for pop and imap
mxtoolbox has a small timeout window on DNS queries use a different tool
This is pretty subjective - but it's talking about the SOA TTL value in DNS is outside of their recommended range. Not sure what their recommended range is, but RFC 1912 recommends 14-28 days.
If you need answers to the questions above send an email to mailtest#unlocktheinbox.com - It will auto-respond and give you a lot more insight, to what's going on.
I've been trying to check my balance from by 3g modem via AT commands and seem to be stuck.
The device infomation is as follows:
Manufacturer: QUALCOMM INCORPORATED
Model: M6281
Revision: SSD_M6281A-0.0.1 1 [Oct 02 2008 07:00:00]
The modem has USSD capability (advertised and also present in the factory installed dashboard).
I am connecting via putty to COM4 serial port which is my modems application port. All AT commands are working fine but I am getting an error on issuing the following via putty:
AT+CUSD=1,"*111#",15
This returns a simple "ERROR". *111# is my carrier's balance check code. I suspect that there is a formatting error somewhere but I can't figure out where.
Note: If I issue a blank ussd command:
AT+CUSD=1,"",15
then I get an OK (although I later get a response +CME ERROR: retry operation) ... If I write anything within the quotation marks however, it returns an "ERROR".
Ok, I finally found the way to fix this. Apparently there was a problem in the encoding. Here is what I did:
AT+CSCS="GSM" // change character set to GSM
AT+CUSD=1,"*111#",15 // Issued balance check ussd code
It now works fine.
The default encoding was UCS2, I'd appreciate if someone can share how to convert ussd codes to UCS2 encoding in putty.
Have you tried issuing request by AT+CUSD=1,"*111#" ? (without last parameter)
AT cmmands sometimes differ due to manufacturer implementation.
Issue "Curl::Err::SSLConnectError"
Can any one tell me what will be the exact URL for Payflowpro now ,
the Url "https://payflowpro.paypal.com" does not work for me now.
It was working fine before but for some reason it gives me an error now.
Code in Lib file
Code in module
post_contents = Curl::PostField.content('TRXTYPE', 'S'),
Curl::PostField.content('TENDER', 'C'),
Curl::PostField.content('AMT', amount),
Curl::PostField.content('ORDERID', order),
Curl::PostField.content('CURRENCY', PAYPAL_CONFIG[:currency]),
Curl::PostField.content('CREATESECURETOKEN', 'Y'),
Curl::PostField.content('SECURETOKENID', secure_random),
Curl::PostField.content('PARTNER', PAYPAL_CONFIG[:partner]),
Curl::PostField.content('VENDOR', 'abababa'),
Curl::PostField.content('USER', 'abababa'),
Curl::PostField.content('PWD', 'abababa')
Logs Details
Started POST "/__better_errors/45429440/variables" for 127.0.0.1 at 2015-01-20 12:24:16 +0500
TRXTYPE=S
TENDER=C
AMT=5.99
ORDERID=1421738848U1
CURRENCY=USD
CREATESECURETOKEN=Y
SECURETOKENID=****
PARTNER=Paypal
VENDOR=****
USER=*****
PWD=*****
Rebuilt URL to: https://payflowpro.paypal.com/
Hostname was NOT found in DNS cache
Trying 173.0.82.162...
Connected to payflowpro.paypal.com (173.0.82.162) port 443 (#2)
successfully set certificate verify locations:
CAfile: none
CApath: /etc/ssl/certs
error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
Closing connection 2
The reason for this is the change announced by PayPal.
Whoever is using the older SSLv3 needs to check their implementation of update their code to use the TLS version for curl.
PayPal provides info in this link.
That is still the correct endpoint. It looks like something going on with your DNS based on the message stating "NOT found in DNS cache."
You could try changing to use different DNS servers and see if that resolves your issue. For example, you could use Google's DNS servers or OpenDNS.
Google's DNS servers are 8.8.8.8 and 8.8.4.4.
Open DNS is 208.67.222.222 and 208.67.220.220.
Depending on your router you may be able to update the DNS server there, or you may need to do it from your local NIC card properties.
I'm using Twilio to send and respond to messages. It was working normally, but since we moved to bay area the responding function doesn't work now.
So what happens is when the user send message to us(the IP address of our own computers) from their phones, our server can't receive anything. When we check our Twilio account, we know that the msg was indeed sent to the Twilio server. So we think it's the problem of linking between Twilio server and our IP address. We are suspecting that the IP address is virtual IP address here, which makes Twilio server can't find us. Is our suspection correct? if yes, what should we do? If not, what would be the possible problems?
Apologize for having a description not very clear, but it's pretty much everything of the problem. Please tell me if you need any additional information.
You probably need to use a dynamic dns service. Then you need to find what port Twilio sends the SMSs to the client(your computer), and make sure your firewall is forwarding that port to your computer. Odds are this is a firewall issue, especially since you say everything worked before you moved. Has there been a change in your network setup? You need to be aware of both hardware and software firewalls in your setup.
How is the firewall configured on your router? You need to forward requests to your router to your local IP address. Example: My local ip is 192.168.1.5 my external ip is 245.932.4.3 (This is the value you get from myipaddress.com) Thus you need to set your router (which has ip 245.932.4.3) to forward requests on port x (where x= the twilio outgoing port) to 192.168.1.5
Im integrating sagepay as a payment gateway into my magento installation. There seems to be some issues with the IP address included on the server however ive contacted sagepay and they've asked me to put some test purchases after changing the POST URL to https://test.sagepay.com/showpost/showpost.asp
is there a simple way to do this?
A 4020 error is a common error which can be resolved.
You need to ensure the IP is a fixed IP for Server or Direct integrations rather than a dynamic IP (an IP that changes).
If you look in My Sage Pay within Transactions>Invalids you will see the error along with the invalid IP. If the IP is not visible in Invalids you can either:
use our Simulator (submit a transaction to Test and if the IP is not detailed in My Sage Pay, you will get a 4020 error and you will be able to see the IP within the Simulator). To register for a Simulator account which is effectively a pre testing account click here).
you can send a Showpost to Sage Pay so that we can confirm the IP we are receiving your transaction from.
Once you know the IP that you are posting your transactions from, enter the IP within My Sage Pay, Settings>Valid IPs.
If you are unable to add additional IPs within My Sage Pay chek the Subnet Mask is not overlapping.
You only need to enter one of the IP addresses if you are entering the Subnet Mask as 255.255.255.248 as this means any IP address which is the same barr the last three digits will be accepted subject to the last 3 digits being less than 248. Example:
IP address 217.194.220.205 and Subnet Mask 255.255.255.248 registered on the Sage Pay account will therefore accept any IP address which starts '217.194.220.' and has the last three digits between '000' to '248'. You therefore do not need to enter the other four IP addresses as you have already covered these within the IP address and Subnet Mask already entered.
If you need any further help from Sage Pay, we're happy to help via 0845 111 4455.
Sage Pay Support