Actinic / Paypal and zone (courier) shipping - incorrect charges levied

[Brian Cox]

I cannot believe that we are the only company in the UK who ships product based on weight according to zonal charges set by UK couriers, however in the lonely world of website development, we are often made to feel that we are.

The problem;

UK split into (say) 3 zones: Mainland UK, Highlands and Islands, Northern Ireland

Shipping to customers in each zone is determined by weight. So in our example

Zone Mainland UK Highlands Northern Ireland
Weight

<10Kg £10 £15 £20
<20Kg £18 £30 £40

Payment methods accepted:

Payments can be made by Credit Card (Not Actinic Payments, but Paypal Payments Pro) which is integrated with the website, or via "Checkout with Paypal" button residing on the last page of the checkout process.

The Problem:

Ok, so customer lives in Manland England, and buys something that weighs between 10 and 20 Kg. As He/She goes through the checkout process the cart is updated with the price of the goods. On checkout, As "United Kingdom" is selected as invoice address, they are prompted with a request for "County/State/Province" where "England" is selected from the drop down menu comprising the allowable zones.

... the cart is then updated with the correct courier charge (in this case £18)

....... now ..... paying by Credit Card works fine, the customer is charged for the goods plus the courier charge.

........... however if the "pay by paypal" button is clicked, the customer is taken off to the paypal login, where login to their account is completed before being returned to the website final page where the order is either confirmed or cancelled (No money has flowed out of the paypal account at this stage, and no order will ever appear in the "pending" tab if cancelled at this stage).

...... those pesky customers ..... they can read. There on the final page is a brand new courier charge ... no longer is it the £18 they had agreed to, but no, it has increased to a mind boggling (well to the customer) £40. On further examination, hapless customer realizes that there is a selector on this confirmation or decline page under "Shipping And Handling" called "Class of Service" which seems to have the number he first agreed to, and the extortionate number that now appears on his invoice that he is being asked to pay, and some other odd numbers that he has never seen before.

What he is presented with, in order, is £40 (visible), with £30 and £18 visible if the twisty is clicked ... <we know that these are all the courier charges available for the specified weight in each and every zone applicable to the United Kingdom>

.... So he selects £18 ..... the invoice presented does not change.

... so he either confirms the order, and prays that his selection is reflected in the payment taken from Paypal, which unfortunately it isn't and results is distressed, frustrated and sometimes abusive emails containing the word "fraud" in them

.... or he just abandons the order and goes elsewhere ... invisible to the business (erm ... but hey, we have historic day by day, hour by hour financial data, so we know when something is wrong).

My conclusion is that Actinic can not handle shipping charges by zone and payment by paypal.

Snapshots have been in the hands of support and development for over two weeks, we have been on version 9.x (where we could charge correctly via paypal, but couldn't accept payment by credit card for different invoice and dispatch addresses) and version 10.x (where we can now not charge correctly by paypal, but can accept credit card orders for different invoice and delivery addresses)

No shipping charges are levied in Paypal (hey, the numbers all reflect exactly what is in the zone / class table within Actinic when they are changed and uploaded ) so Paypal is a red herring

Last information from Actinic Support / development

"This has now been confirmed by development, that the country codes for the regions are not compatible with the PayPal Pro System. The standard countries and states that are automatically in Actinic will work, as it has the correct country codes. It conforms to the ISO standard shown in this link: http://www.iso.org/iso/english_count..._code_elements

It has been suggested that you do not use the state/provinces for England, Wales, Northern Ireland, Scotland Lowlands and Scotland Highlands. This has been a problem with other payment service providers, such as Sage Pay.

Unfortunately this is not a problem with the Actinic software as you are able to process card transactions through a standard checkout, this is a incompatibility problem with PayPal Pro, and they need to conform to the ISO standards
"

... Paypal need to conform to the ISO Standards ... they are ... they are returning the UK country code, Actinic is not storing / handling zone information correctly or providing meaningful final checkout pages. Oh and dont forget that even if the paypal payment is abandoned, your shopping cart details are replaced with those held on your paypal account ... so the customer can actually specify a third completely different address to ship to within Paypal.

Anyways ... has anyone figured out a way of shipping weight based product to customers within courier zones within the United Kingdom and getting paid by Paypal, or have you all given up and moved to / Tiger / <nah .. you cant answer that if you have moved can you??>

[leehack]

Well first of all Paypal Pro is not PCI compliant, so that's a reason not to use it, if that's not enough to sway you, then the fact that it's a really poor PSP and has always been a white elephant should be. But in your defense, if the actinic system still lets you use this, it needs to work, i'm not sure it ever has worked correctly.

Instead of having countries and states, can you not setup the areas mentioned as countries (settings - locations), give them the dummy UK codes (UK1, UK2, UK3 etc.) and then assign the different weights to each of them in the shipping settings. They should operate as standalone countries then and customer also only has to select their location from one drop down list. Worth a try anyway, that's the workaround many of us have used over the years when needing to split up the UK.

[Brian Cox]

The solution is actually embedded within Actinic, making the trasition from V9 to V10 caused hiccups, and the payment methods previously used no longer apperars as an option in the PSP providers.

The whole crux was to ditch Paypal checkout, all that was required was to select Paypal Website Payments (or whatever it is called in the new PSP drop down) in Business settings / Payment etc etc

Actinic now passes the total to Paypal, which treats it as a single item purchase called <whatever the invoice number is>

However .. not all runs smoothly, as now once payment is completed the page bounces back giving a "General Script Error" in a tab that is conveniently labelled "Actinic" with a web address of our web site.

Thsi is being looked into by Support / Development ... Pearl Script pages haev already been modified, and Paypal set correctly to not bounce to a URL ......

[click4]

postcodes

Hi

Thanks for taking the time to reply.

We actually had something like this set up, some people clicked on the correct charge some didn't..for example for us to send our heavy goods to IV postcode could cost £70. Some people were ticking mainland UK and paying only £30. Just added paperwork and time having to have the conversation about asking for more money. Some admit seeing the charge but thought thye'd just click mainland anyway. We just dont have the time to mess around and want something in place to do what i think is pretty standard ask for an eccommerce site.

[leehack]

What you want is relatively straightforward yes, but ecommerce software cannot contain lie detector software to detect when someone tells porkies. You are always going to rely on a customer telling the truth as you do with their card details, email address and phone number for example. If you setup the different locations like i mentioned and do not have Mainland UK as the first option, perhaps it will help a little more, but people will always try these sort of things on and you can't really blame them with such disparity in costs at times.

[Brian Cox]

Surely it is not beyond the whit of man to include

1/ a post code verification process (yes there are the predictable add ons for post code look up such as PostCodeAnywhere) as Actinic Vanilla doesn't appear to have any Validation on its address fields (please tell me i have missed it somewhere) then

2/ If using Zones to ship, include postcodes in the zone which are valid. Courier zones are pretty well defined, even down to splitting the dreaded highlands and Islands IV post codes. A simple SQL statement running within an access database can perform this task with ease. So why is it so difficult to implement in Actinic's shopping cart?

Nothing can be done without stage 1, garbage in , garbage out

[click4]

What you want is relatively straightforward yes, but ecommerce software cannot contain lie detector software to detect when someone tells porkies. You are always going to rely on a customer telling the truth as you do with their card details, email address and phone number for example. If you setup the different locations like i mentioned and do not have Mainland UK as the first option, perhaps it will help a little more, but people will always try these sort of things on and you can't really blame them with such disparity in costs at times.

its simple lee...surely people would have to tell the truth by putting in their delivery postcode????Forget all these shipping zones and evrything else..why can't a customer simply put in their shipping postcode and the cart calculates the delivery price? Dead straightforward...it can be done on other eccommerce software. ie calculating cost by weight and postcode. or indeed by number of items and postcode, or even by order value and postcode. Needs to be postcode for a lot of people as postcodes are often split, meaning higher charge for some than others. eg PA1-7 lower than PA14+

[leehack]

Problem is you're comparing an online database that does it's work there and then against actinic which has already done its work and sent the information online ready. There is no facility in actinic because of its offline architecture, to check customer's postcode and cross reference that to a shipping matrix.

I fully understand what you mean and want and agree to a certain degree, but ultimately your choice of software does not allow this 'on the fly' kind of calculation. The only way you can get anywhere close is to expect people to input their address and then also select their shipping destination to correspond with the address they have input, by having postcode areas setup as locations for example.

[leehack]

A simple SQL statement running within an access database can perform this task with ease. So why is it so difficult to implement in Actinic's shopping cart?

Because actinic is an offline solution and doesn't use SQL, that presents two rather big bloody hurdles to your perceived 'ease' of application. The relative ease of what you say is OK, your misunderstanding of actinic's architecture is your stumbling point.

[Brian Cox]

"Problem is you're comparing an online database that does it's work there and then against actinic which has already done its work and sent the information online ready. There is no facility in actinic because of its offline architecture, to check customer's postcode and cross reference that to a shipping matrix."

... I presume that shipping country and zone charges are able to be levied as they are a determined by a selector (If Austria then shipping = £59, If Highlands and Islands zone in the UK then shipping = £50 for example) for a certain weight. Does actinic not do something along the lines of "if weight is between x and y, and shipping zone equals z, levy postal charge AA" if so, is this done server side, and again, If so, is this not a calculation or is it a look up? is "zoning" by postcode not just an extension of this calculation / look up? and is the issue confirming that the customer's post code is actually valid?

Of course my knowledge of where and how things are done is limited, i try to run a business and use my website as my showcase to the world. So my humble apologies for my architectural ignorance.

....You are quite correct, i was using SQL as an example of how simple it is to implement, and not inferring that it is used anywhere other than by those of us who whish do get information out of the ActinicCatalog database which resides in the Site file without distroying the information presented in the Actinic GUI (eg, just getting order information out of Actinic in spreadsheet format without having to export files then reinstate orders form complete into pending again etc etc etc)

....The problem with the choice of software is that whilst all companies trumpet their wonderfull advantages, no where do they say things like "if you need to ship weight based products to courier defined zones within the European Community this is not the solution for you" The poor old business user who had diverted resources, both fiscal and personal to creating an online store doesnt get to these hurdles until after committal (yep here come the white coats).

...All in all I think Actinic is a pretty good solution. Unfortunately , unless you are a web developer, you probably dont know what you dont know until you need to know it..... if you get my drift.

...hark .. the sleigh bells are ringing .... must be time for Chrismas Shopping :-)

[Mike Hughes]

Hmmm.

From what I can see (http://www.dataplanning.co.uk/pages/...-data-home.htm) the problem is that while there might only be 124 or so postcode areas (AB, NW, etc) there are about 3,000 postcode districts (AB1, NW2, etc).

So if you need to split PA1-7 from PA14+ then it gets a lot more complicated.

If you really want this it should be relatively easy to use javascript to either validate the shipping zone chosen or even make sure only the correct zone is presented to the customer.

i.e. If "postcodearea" found in "AB-BM-NW-..." then "show Dropdown1", etc.

You can see why postcode districts would be a much bigger job than just the postcode areas.

I think you would need to manually update the dropdowns to keep the displayed prices correct if you ever change shipping costs.

This would rely on the customer running javascript, and they could disable it, but you then have the option of requiring it to run, much like making sure they tick the terms and conditions box.

Shipping by postcode has been asked for before and I have seen people on the forum talk about sharing the development costs. I haven't seen these lead to anything though.

It doesn't look like too big a job to me but there could easily be implementation challenges as the devil is always in the details.

Mike

[leehack]

... I presume that shipping country and zone charges are able to be levied as they are a determined by a selector (If Austria then shipping = £59, If Highlands and Islands zone in the UK then shipping = £50 for example) for a certain weight. Does actinic not do something along the lines of "if weight is between x and y, and shipping zone equals z, levy postal charge AA" if so, is this done server side, and again, If so, is this not a calculation or is it a look up? is "zoning" by postcode not just an extension of this calculation / look up? and is the issue confirming that the customer's post code is actually valid?

There is a shipping matrix, you're right, you have your zones and then within those zones have the tiers of charging, all defined offline. What you want to do is indeed along the same lines, but infinitely more complicated and believe me the shipping choices within actinic are amongst the very best in the marketplace and already very complicated. There is no blanket postcode solution, because every person wants something different in this area and the reality is that a shipping by postcode requirement is very very low on the wanted list of additional functionality to be added to actinic. I've worked on well over 100+ actinic sites now and not once have i ever been asked to give you a rough indication of the need. It would be an inordinate amount of work to do and work that is for the very small minority, that's very hard to justify on a universal package designed to serve the masses.

Of course my knowledge of where and how things are done is limited, i try to run a business and use my website as my showcase to the world. So my humble apologies for my architectural ignorance.

There's no need to apologise, i'm merely pointing out to you the limitations of the system, to try and ease some of your frustration/misunderstanding of why this is not as simple as you wish, although perfectly logical from your angle (which i fully concur with).

....You are quite correct, i was using SQL as an example of how simple it is to implement, and not inferring that it is used anywhere other than by those of us who whish do get information out of the ActinicCatalog database which resides in the Site file without distroying the information presented in the Actinic GUI (eg, just getting order information out of Actinic in spreadsheet format without having to export files then reinstate orders form complete into pending again etc etc etc)

Enterprise is SQL based, perhaps looking into that is an option. If you've seen some of the v11 chats, you'll see that actinic is moving that way with more data online, market forces are undoubtedly forcing this and to some extent it flies in the face of what actinic was first made to do, but that is progress. No doubt what you want will happen at some stage, it's just got a boat load of other more important things ahead of it right now. I've provided feedback on the v11 features in this area and encouraged them to think ahead at least 2-3 years and think about courier integration for example, time slots we get our stuff delivered are getting smaller and smaller now and already we have specified by an hour slot deliveries, it won't be too long before we get down to 20 or maybe even 10 minute slots. It's being thought about, but there is only so much they can realistically do and more important with a global package, it has to be serving the masses and fulfilling the most requested features first.

....The problem with the choice of software is that whilst all companies trumpet their wonderfull advantages, no where do they say things like "if you need to ship weight based products to courier defined zones within the European Community this is not the solution for you" The poor old business user who had diverted resources, both fiscal and personal to creating an online store doesnt get to these hurdles until after committal (yep here come the white coats).

Nobody sells their product on the disadvantages, nor do you, when was the last time you messed up an order and let all customers know via your website that you ballsed up an order last week for Mr Jones. They provide a free 30 day trial so you can test anything you could ever want to. You might find that when you trialled it, you did not have this requirement and that's fully understandable, but if the package you are on does not offer what you now need and you cannot see it being offered in the near future, you probably have to take the tough decision to move away from it.

...All in all I think Actinic is a pretty good solution. Unfortunately , unless you are a web developer, you probably dont know what you dont know until you need to know it..... if you get my drift.

I fully understand you and agree wholeheartedly, but that's why there are professionals out there who specialise in this software, so you have the option to go out and get it or at least find out if possible.

We are all guilty of suffering holes in actinic that we think should not be there or where we just don't understand why it is so complicated to get, we must all bear in mind, it's a global package catering for the masses who do various things with it. It simply cannot cater for everyone's need and all of us are often guilty of getting a bit tunnel visioned on what it should be doing or offering.

[leehack]

Hmmm.

From what I can see (http://www.dataplanning.co.uk/pages/...-data-home.htm) the problem is that while there might only be 124 or so postcode areas (AB, NW, etc) there are about 3,000 postcode districts (AB1, NW2, etc).

So if you need to split PA1-7 from PA14+ then it gets a lot more complicated.

If you really want this it should be relatively easy to use javascript to either validate the shipping zone chosen or even make sure only the correct zone is presented to the customer.

i.e. If "postcodearea" found in "AB-BM-NW-..." then "show Dropdown1", etc.

You can see why postcode districts would be a much bigger job than just the postcode areas.

I think you would need to manually update the dropdowns to keep the displayed prices correct if you ever change shipping costs.

This would rely on the customer running javascript, and they could disable it, but you then have the option of requiring it to run, much like making sure they tick the terms and conditions box.

Shipping by postcode has been asked for before and I have seen people on the forum talk about sharing the development costs. I haven't seen these lead to anything though.

It doesn't look like too big a job to me but there could easily be implementation challenges as the devil is always in the details.

Mike

This sort of thing is possible, i recall a while back now a customer having a requirement for anyone to be able to input their postcode and have a list returned of local suppliers in their area. They put their postcode in and it was looked up in a file, located the page that listed their suppliers and directed them off to it. Something along the lines of that but much more detailed would certainly be possible, the main problem with postcodes is that they are such a huge area and people's requirement would be so diverse, it would be a beast to create on a global package.

I can certainly see the use of PCA somehow linking into the address fields via JS at some stage in the future and indeed it would be nice to have, in the meantime this kind of work is going to be one off bespoke items with a hefty price tag to do, even so still favourable costwise when compared to a fully bespoke system (£5-25k).

[jont]

Think yourself lucky - PayPal Express Checkout removes the shipping all together let alone worry about specific postcodes. Nice.