Realex – Your transaction has been successful but there was a problem connecting back to the merchant’s web site

If your are trying to get realex e-payment integration working on your website and are getting the following message at the end of the realex redirect process:


Your transaction has been successful but there was a problem connecting back to the merchant’s web site. Please contact the merchant and advise them that you received this error message. Thank you.


Then the good news is that most of you integration is working and its just the very last step that’s failing, this means that you have sent to Realex correct values for: Merchant Id, Shared Secret, Account Id, Request URL etc. etc.


Now, nine times out of ten the above error is caused by a badly configured Return or Callback URL, this is a URL that you must tell Realex about by phone or email, Realex redirects back to this URL once the transaction is complete. So there are 3 possibilities why the redirect is failing:


1.) You haven’t yet told Realex what your return URL is. You need to find out what the URL should be and let Realex know, phoning them is often the most efficient route. The URL will depend on which CMS you are using etc. Ask Google for hints.


In ubercat you can get the URL by going to the Realex settings page (Store administration / Configuration / Payment settings / Overview / Payment Methods / Credit Card [realex] settings) and copying the URL from the ‘Realex Callback Page:’ field.


Details about the Magento return URL can be found here.


2.) You have told realex what the URL is but they forgot to configure your account or made a mistake while configuring it – this happens more often than you might think, phone up Realex and get them to confirm that the return URL is set correctly – double check the configured URL it in detail! Do you need to add or remove the www.?


Hopefully it is only a matter of short time before you get everything working as it should!


Realex & Magento – New Return URL for Payments Module v2.0

If you are hooking magento up to realex for payment on your eCommerce website then you will most likely be using the payments module kindly provided by StudioForty9 in Cork.


As part of configuring this you will need to tell realex what your cart’s ‘return URL’ is, this URL has changed since the introduction of the newer version of this module (v2.0) which it seems is for use with magneto v1.5 and greater. The new URL format for use with the newer module is:


In case you are still using the old module, the url format for that is:


Foxycart FoxEE – XML Datafeed Failed

Yesterday I was doing some web and eCommerce development for a client in Kildare, I was working to link Expression Engine and FoxEE up to foxycart. When testing transactions everything seemed to work ok, except that after very transaction I received the following error:


DataFeed Failed: (2134029) 2010-09-30 05:50:28 No data returned for [500]


Every time the error occurred foxycart would send me an email.


The XML datafeed sends transaction data back to the expression engine website and FoxEE so that FoxEE can display the transaction details in the admin interface. Despite the error the transactions were being properly displayed by FoxEE and everything else seemed to work well!


Any script that consumes the foxycart XML datafeed must return the text ‘foxy’, if not this error will occur. It turns out that if your expression engine site is offline (Admin / System preferences / General Preferences / Is system on? == No), FoxEE will return some testing text instead of ‘foxee’ and so the error will occur. The funny thing was that my website was not ‘offline’ it was completely live and so FoxEE should not have been in test mode at all…… strange…. Then I remembered that I did have the site offline a few days ago but not now….


Well I cleared all of the Expression Engine caches and the error went away!!


Hope this helps somebody with a similar quandary – If you get this error, try:

(a) Check that your site us ‘On’
(b) Clear the Expression Engine Cache (Admin / Utilities / Clear Cached Data)


Google App Engine & Paypal Talk Slides

I very much enjoyed the GTUG Dublin meeting last night at Google HQ in Dublin. There were very interesting speakers and a nice pint was had afterwards in the schoolhouse! It was nice to meet everybody and have a good chin-wag.


I have uploaded the slides to my talk on integrating paypal and the google app engine, they can be downloaded from here.

Paypal – Accept Credit Card Payments, ‘Paypal Account Optional’ not visible

Q: I want so setup my Paypal business account to accept credit card transactions and not just paypal payments, but my customers are not offered the ‘pay by credit card’ option and when I look for the “Paypal Account Optional” setting in Profile / Website Payments Preferences I can’t find it! What do I do?


A: Make sure that the email account associated with you paypal business account has been verified (also check that you bank account has been verified too.) if it is not verified the option to pay by credit card will not be available. Once everything is verified the Profile / Website Payments Preferences / Paypal Account Optional should be visible -make sure that this option is ‘On’ and your customers should now be given the option to pay by credit card!

Google App Engine – Paypal PDT Example

We have been slaving away in the cloud working on integrating paypal with a google app engine application for one our clients in Dublin. There really isn’t much information ‘out there’ on the subject of connecting to paypal from the GAE, so I have decided to write up some notes in the hope that they prove useful to others (and me when I forget all about it!)


I am going to start at the ‘end’ while the information is fresh in my head, when using ‘Paypal Payments Standard’ you can choose to get Paypal to pass you back transaction outcome information when it redirects back to your website after a transaction – they call this PDT. You can use this information to update the transaction/order status on your website (once you verify it).


Here is some more information on PDT:


With PDT enabled paypal adds some arguments to the return url, these arguments contain information about the transaction, however you shouldn’t really trust this info as the HTTP POST could have been spoofed by somebody else. So to check the transaction information you pull out the ‘tx’ argument and pass it back to paypal which will return a verification message that contains the transaction details.


So to verify a PDT transaction we must:


(a) Get the ‘txt’ argument from the paypal return request.
(b) Perform a HTTP POST back to paypal specifying ‘tx’
(c) Check the response from Paypal, check for ‘SUCCESS’, check ‘payment_status’ and possibly other transaction details.


In Python on the Google App Engine the python code could look like this:


[code lang=”python”]
import urllib
from google.appengine.api import urlfetch
import re
class paypal_pdt_handler(RequestHandler):
def get(self):
# Get the transaction id, tx=blahblahblah
trans_id = self.request.get(‘tx’)

# Confgure POST args
args = {}
# Specify the paypal command
args[‘cmd’] =’_notify-synch’
args[‘tx’] = trans_id
args[‘at’] = _identity_token

args = urllib.urlencode(args)

# Do a post back to validate
# the transaction data
status = urlfetch.fetch(url = _paypal_url,
method = urlfetch.POST,
payload = args).content
self.response.out.write(‘POST Failed’)

# Check for SUCCESS at the start of the response
if‘^SUCCESS’, status):
# Check other transaction details here like
# payment_status etc..
# Update order status


This is a slightly cut down example, in a real application you would need to do a bit more error handling etc. In this example the following variables need to be given values:


_paypal_url – The url to paypal, either sandbox or live.
_identity_token – Your “Identity Token”, see this post for info on how to find this in your paypal account:


NOTE: Another way to get information on transaction status is to handle Paypal IPN. I tend to use both methods as if you only use PDT and for some reason the user does not redirect back to your site, then your site won’t b able to check the transaction status whereas IPN messages will be delivered in all cases.

Paypal PDT, Fail Error: 4020

There are a few reasons that could cause paypal to send back:




When you attempt to verify PDT transaction data by posting a _notify-synch command.  However, in 9 times out of 10 the cause is due to the request containing an incorrect ‘at’ or authorisation token argument.


The ‘authorisation token’, or ‘Identity Token’ is a big long alphanumeric string, to find yours log into your paypal account, click on ‘Profile’, then click on ‘Website Payment Preferences’, scroll down to the ‘Payment Data Transfer’ section – you will see your ‘Identity Token’ at the end of this section.


This token must be included in your _notify-synch command as an argument named ‘at’.


Some more information on Paypal’s PTD can be found here: website goes live

Our web design partners at Pride Design have put Paula Rowan’s new website live, I worked very closely with Shane at Pride Design to bring the site to fruition and I am very happy with the outcome!  Paula sells a (self designed) range of luxury gloves through her new website.


The website is (once again) built on Drupal 6 with the eCommerece functionality provided by ubercart.  Ubercart worked out very well on this project and it is quickly becoming our preferred eCommerce solution as it provides modern and flexible shopping cart functionality along with the power of drupal.


Anyway, if you’re feeling a bit on thee chilly side on this dark and cold month of December why not pop over to  and see if a luxury pair of leather gloves can help!

Ubercart Option Images module with content template or custom template

Q: Is it possible to use the ubercart Option Images module (uc_option_image) with a custom product display template, via Content Template (contemplate) or a custom node.tpl.php?


A: Yes, you just need to manually call the attribute image into your template with a line of PHP code.


The ubercart Option Images module (uc_option_image) is a really nice module that allows you to provide an alternative image for product attribute options – when the visitor views a product and chooses an attribute option (say colour: Red) the attribute displayed image will change to the one for that option – very nice especially for online shops that sell, say clothes in different colours and patterns etc. 


The strange thing is that (at the time of writing) the Option Images 6.x-1.4 doesn’t work and doesn’t even install!  Luckily some good folks have worked around the problems and come up with a fixed version that does work (with a bit of TLC) – I have written an article about  getting option images to work with the patched version on the Pride Design website  here –>


This should hopefully help you to get it up and running…


Now, by default this module only attaches the option image to the default ubercart product display, if you are using a custom product template (as I always do) via the Content Template (contemplate) module or via a custom node.tpl.php file then the option images will not be displayed. 


To get around this you just have to pop a bit of PHP code into you template at the point at which you want the image to display as follows:

print $node->content[‘option_image’][‘#value’];



This should do the trick.  If you want only the attribute option image to be displayed (i.e. instead of the product image) then just replace your current product image display code with this.

Ubercart style add to cart button

Just in case I forget how to do it – here a link to a post that tells you how to change the add to cart button in ubercart,

very handy indeed!