Messages

So some kind of client refresh is needed here. I spent some time looking through the GWT one page checkout before I realised that it is not used in 6.5.1.0.

The answer is to modify CheckoutOnePageRefreshAction.java so that on an address change it regenerates the shipping quotes and creates an array of shipping quote codes and an array of names. Getters are then provided for the two arrays.

On the checkout side in CatalogCheckoutOnePageBody.jsp, in the onePageRefreshCallback check the result for the arrays and if found process them into the option tags, then use jquery to insert the tags into the shippingQuotes element (the list), and finally call refreshShipping() which will update the totals with the new default shipping.

Exactly the same can be done for payments, if you want to limit them to certain countries (we only want cheques from a UK billing address).

If you configure the Cash on Delivery (COD) payment module there is an option "set order status" which allows you to choose the status that, presumably, an order will be set to when submitted with this payment type.

However the status is always Pending.

In CheckoutConfirmationSubmitAction.java the status is always set to Pending for PaymentDetails.COD

I have written a set of shipping modules with availability depending on the address (currently just country but I also plan one to depend on postcodes). The behaviour that I expected to see was that if the customer changed the address the Shipping Quotes would be regenerated, a new one selected if necessary, and the possible quotes displayed in the pull down on the one page checkout. But, out of the box 6.5.0.0 doesn't do this. The methods on the pulldown and the shipping cost in the totals are still for the original address.

I have customised CheckoutAction so that if the address changes it will recreate the quotes and select an appropriate one (either the original, if still valid) or the first of the new set of quotes, and I can see this change is passed on and used in the totals.

How, in CheckoutAction, can I send the new array of quotes to the OnePageCheckout so that they are displayed in the Shipping pulldown menu?

OK I have got the Paypal module working. At the same time I was also developing my own payment module that uses IPN and that too wasn't generating a callback.

My test server is at work, behind the firewall, and I forward port 8780 from the router (internet side) to the test server port 8780.

From the log (catalina.out) I could not see the debug statement in the PaypalAction class, so it made me suspicious that the callback was not being made.

I went to the Paypal Sandbox and logged in. I turned on the IPN history and could see that all the IPN sends had failed, and the odd thing was none had any HTTP status code (should be 200, or at least 404 or 500 or something if it went wrong).

Then I turned on the GET/POST logging so that I could see the HTTP requests. To do this edit konakart/conf/server.xml and uncomment the valve section, then restart the server. You will then be able to see the requests in konakart/logs/localhost_access_log.yyyy-mm-dd.txt. I could see that there were no POST requests coming in to /konakart/PayPalCallback.action, my hunch was right - but why?

I also "discovered" the Paypal IPN simulator and this showed that it was getting "connection refused" on port 8780. Another good clue.

From my Linux box at home I tried to use wget to get the callback, I got a status 302 and was redirected to the Welcome page - so that could get a connection on port 8780.

I then logged in to the company webserver and tried wget on the callback URL and got a "connection refused" too. So two out of three external connections were refused (plus, I believe the callback from the other payment gateway). Could it be that the remote hosts are refusing the connection based on their own firewall rules for port 8780?

To test this theory I added another port forward on the router to forward port 80 (normal http port) onto 8780 on the konakart server, altered the callback in the Paypal module to remove the port (http://server/konakart/PayPalCallback.action) and... it worked!

This shouldn't be a problem in production as we will want to do it all on port 80, but I am surprised that it worked earlier in the month and seems to be blocked now. Anyone else have problems with callbacks to 8780?

I'm still having problems with 6.5.0.0 and Paypal callbacks not coming through. I noticed this problem...

Some payment modules have a neat feature where if the callback, success or failure urls contain "host:port" then these will be replaced with the actual values for the site, this allows a default URL to be put in the module that works out of the box.

With Paypal the success and failure URLs are modified in this way, but the callback URL is not, and you can see this in logs:

notify_url        = http://host:port/konakart/PayPalCallback.action
return             = http://example.co.uk:8780/konakart/CheckoutFinished.action
cancel_return = http://example.co.uk:8780/konakart/CatalogCheckoutExternalPaymentErrorPage.action

A quick workaround is to set the callback URL explicitly. It could also be fixed in the code in modules/src

com.konakart.bl.modules.payment.paypal.Paypal.java

change:

        parmList.add(new NameValue("notify_url", sd.getPayPalCallbackUrl()));

        sd.setPayPalReturnUrl(sd.getPayPalReturnUrl().replaceFirst(hostPortSubstitute,
                info.getHostAndPort()));
        sd.setPayPalCancelUrl(sd.getPayPalCancelUrl().replaceFirst(hostPortSubstitute,
                info.getHostAndPort()));

to:

       sd.setPayPalCallbackUrl(sd.getPayPalCallbackUrl().replaceFirst(hostPortSubstitute,
                info.getHostAndPort()));
         parmList.add(new NameValue("notify_url", sd.getPayPalCallbackUrl()));
        
sd.setPayPalReturnUrl(sd.getPayPalReturnUrl().replaceFirst(hostPortSubstitute,
                info.getHostAndPort()));
        sd.setPayPalCancelUrl(sd.getPayPalCancelUrl().replaceFirst(hostPortSubstitute,
                info.getHostAndPort()));

Hello

In 6.5.0.0 default reset passwords are 5 characters, but the login form expects 8

If I go to /konakart/LogIn.action

Click on "Forgot your Password?" it goes to /konakart/ForgotPassword.action

Enter in a valid user email address, and click SEND it goes to /konakart/ForgotPasswordSubmit.action

The password in the email is 5 characters long, when entered in the form the error message appears: "Please enter at least 8 characters."

In konakartadmin Configuration > minimum Values the Minimum value for passwords is set to 5.

If you change this minimum from 5 to 8 and re-reset the password you will get a new password 8 characters long and be able to login.

I have got 6.5.0.0 installed today (new storefront looks nice!).
I have tried an initial test and the callback didn't work, I need to turn the logging on for 6.5.0.0 and I will report back with more info.

Previously I had set the Paypal currency to be "GBP", now I have left it as the default "Selected Currency". We'd actually want it to always take payments in GBP though. Can I specify "GBP" here?

Previously, using the sandbox, the customer would be taken to the Paypal site (login, confirm payment, etc) and there would then be a link to return back to the konakart site, however this final link was not present, nor did it redirect.

We are evaluating konakart community edition 6.3.0.0. I am testing the Paypal Standard integration using a sandbox test account. I believe I have set up the module correctly and I can see that the payment is made to the paypal sandbox merchant account from the sandbox customer account however a callback is not received.

I have set the callback user to the "out of the box" admin user. Although our development server is behind our firewall port forwarding seems to be working and I think the callback is received but it fails producing this exception in the log... can anyone offer advice on how to get the callback to work?

Code Select Expand


java.lang.Exception: The callback from PayPal did not contain the 'custom' parameter.
at com.konakart.actions.ipn.PayPalAction.execute(Unknown Source)
at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:405)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:964)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:515)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:302)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)