homepage Welcome to WebmasterWorld Guest from 23.20.28.193
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Pubcon Platinum Sponsor 2014
Visit PubCon.com
Home / Forums Index / WebmasterWorld / Ecommerce
Forum Library, Charter, Moderators: buckworks

Ecommerce Forum

    
Credit Card Processing
Any Clues?
mnorton




msg:651085
 12:56 pm on Oct 10, 2002 (gmt 0)

Does anyone know of any reasonable sites which offer credit card posting for a reasonable price preferably in the UK as that is where I am based? If any anyone has any ideas please let me know

Regards

Mike

 

txbakers




msg:651086
 5:43 pm on Oct 10, 2002 (gmt 0)

No such thing as a reasonably priced credit card processor. Unless you expect big volume, the cost is steep.

I use PayPal for my shopping cart and processor. I like it very much.

quiet_man




msg:651087
 6:41 pm on Oct 10, 2002 (gmt 0)

WorldPay, which is UK-based, seems to get most plaudits in threads like these. However, it depends what you mean by 'reasonable' in terms of cost. For the little guy, its not cheap. You may also find you have to pay for outside technical help to get your system integrated, as their 'support' is abysmal.

Crazy_Fool




msg:651088
 1:34 am on Oct 11, 2002 (gmt 0)

hi mike
i keep saying this - don't start off thinking in terms of cost, think in terms of getting the most suitable system. if you get the system right, the cost won't matter.

the wrong system could prevent or deter people from paying (inability to accept certain cards, cumbersome to use etc). the wrong system could cost more in the long run. the right system can generate more sales and therefore more profit. the right system can allow more automation, leaving you free to promote your business or take a day out to enjoy yourself.

each card / payment processor has different features, hence the different costs. take a look at the features available with each company. decide what features you need and those you think may be useful as well, then take your pick from the many payment processing companies that do what you want and need.

i'd also advise you to compare costs properly - work out the transaction costs of X number of transactions per month at Y% each and add any monthly or annual fees. you'll find there's a point at which a low sign up cost company is more expensive than a higher sign up cost company. a 1% difference can be a huge difference once the volume increases.

and no matter what the costs, you simply build them into your pricing. 4.5% on a 10 transaction is 45p. 8% on a 10 transaction is 80p. if you assume 100 transactions per month, then a 150 annual fee is about 0.13 per transaction. (this is very simplified so you'll need to work out everything yourself).

for the uk, there are worldpay and netbanx, and several others. worldpay is actually very good and highly flexible with a lot of useful features (virtual terminal, repeat billing, deferred payments etc etc). the integration is fairly simple but the huge Docs make it seem considerably more difficult (big docs are required to cover the range of features). integration with worldpay and others is easy if you use one of the shopping cart services that is built to integrate with them.

quiet_man




msg:651089
 9:42 am on Oct 11, 2002 (gmt 0)

>>the [WorldPay] integration is fairly simple but the huge Docs make it seem considerably more difficult<<

If you can write your own Perl scripts (as I've been told I need to do) then yes, it would be fairly simple. But I'm not a Perl programmer.

They do have huge Docs, but what happens when you follow the instructions to the letter and it still doesn't work? I've been waiting 9 days now for a reply to a simple email question (yes, I have sent a reminder). If you think that's good tech support, then go with WorldPay. But that's nine days of lost revenue because of their inability to offer support.

Don't get me wrong Mike, I will persevere with WorldPay because they seem the best of the bunch, but I have to speak as I find and I'm not impressed so far.

Dreamquick




msg:651090
 9:48 am on Oct 11, 2002 (gmt 0)

I find it hard to believe you can only perform the task in question with Perl -we used worldpay in conjunction with ASP + SQL and find that it works flawlessly 99% of the time.

Realistically if you don't have a site which uses dynamic server-side code you will lose a number of the benefits of having the ability to take credit card payments online.

Also if you have a dynamic site and don't have at least one person who you can call and get the site code changed ASAP then you have bigger problems than the CC processor not working correctly.

<added>
Let's see if I can't be more helpful than that!

If you want a script you cant write yourself why not just ask on the relevant board - you might find that someone has a canned one or some kind soul might just write one - I know I've gone to some lengths before now for ASP questions.
</added>

- Tony

quiet_man




msg:651091
 11:27 am on Oct 11, 2002 (gmt 0)

>>Let's see if I can't be more helpful than that! ...<<

Thanks for the offer Tony. Actually I (think I) have found a workaround for what I needed to achieve (if they ever get back to me I can confirm it). Also - for reference - yes, it is a flat HTML site.

My point is not that I have personal difficulty or need help from WebmasterWorld. It is that if people are considering WorldPay as a PSP, they should be aware that - in my experience - WorldPay's tech support has been no help at all - they couldn't even point me to any resources for cut and paste Perl scripts.

gsx




msg:651092
 2:35 pm on Oct 11, 2002 (gmt 0)

I have found WorldPay' support to be quite good. Unless you email. You will get no response. Guaranteed.

Use that old technology called the telephone (I know we shouldn't have to) and almost any query will be answered in minutes.

mnorton




msg:651093
 2:49 pm on Oct 11, 2002 (gmt 0)

I could bang together a script in perl that is no problem It is just cost's involved does anyone know of how much worldpay charge per month/transaction and whether there are any setup fees?

Regards

Mike

quiet_man




msg:651094
 5:24 pm on Oct 11, 2002 (gmt 0)

Mike - the costs of WorldPay are fairly clearly signalled on their web site. Don't be fooled by their seasonal 'offers' - they seem to run concurrently, so there's always some 'offer' available. Commission fees may depend on whether you already have a merchant account you want to use. Otherwise its about 4.5%. Plus a remittance fee (about 35p for UK users). Also, there is a five week delay in getting your money from them.

>>Use that old technology called the telephone
gsx - maybe I'll have to bite the bullet and pay for the international phone calls then (they sell to us here in Ireland, but don't offer Irish-based support).

Crazy_Fool




msg:651095
 5:47 pm on Oct 11, 2002 (gmt 0)

>>If you can write your own Perl scripts (as I've been told I need to
>>do) then yes, it would be fairly simple. But I'm not a Perl
>>programmer.

and

>>WorldPay's tech support has been no help at all - they couldn't
>>even point me to any resources for cut and paste Perl scripts.

i think you somewhat misunderstand things here. worldpay (and others) are payment processors. they provide the payment facilities. when you sign up to a payment processing company, you are paying for the payment processing, not for web development or scripting services. it is your responsibility to provide and build the website and to integrate it with the payment processor (whatever company that may be).

for worldpay and most other payment processors, the bare minimum you need is a few lines of simple HTML in a plain HTML page. this will allow you a single BUY NOW button. you can put lots of single BUY NOW buttons on a page or on several pages. however, this does generally limit customers to only purchasing single items.

if you want to sell multiple items, you can get a shopping cart. there are literally thousands of free carts ready to download and install on your site. your cart can be written in PHP, ASP, Java, Javascript, Perl, ColdFusion, or whatever the whizzbang sooper dooper server side language comes along, just so long as the final page (normally the checkout page) that links to the payment page contains those few lines of HTML. this is true of most payment processing companies, including worldpay, although how this is done will differ with each payment processing company.

many of the free (and paid) shopping carts available have "integration modules" for the different processing companies. worldpay lists a large number of carts and modules in their support pages. if the cart you use doesn't have an integration module, or if you have created your own cart, you need to modify the final page of the cart to include those lines of HTML. (you may also need to modify the HTML for how the product information is sent to the payment processing company).

if you need to do some programming and don't know the languages used, you can either learn the languages or employ someone to do it for you. alternatively you can use one of the many remotely hosted shopping carts like mals-e - these are fairly easy to set up and use and require no programming skills at all. i have my own remote cart for my e-commerce customers and they love it because it's so easy to use.

>>They do have huge Docs, but what happens when you follow the
>>instructions to the letter and it still doesn't work? I've been
>>waiting 9 days now for a reply to a simple email question (yes, I
>>have sent a reminder). If you think that's good tech support, then
>>go with WorldPay. But that's nine days of lost revenue because of
>>their inability to offer support.

if the support question was about how to do perl coding (ie, to integrate your site), then you probably won't get a reply - it's not their job. what you need to do is employ someone or ask on forums etc.

yes, i know this isn't an ideal situation, but it's the way things are. it's not just worldpay that do this, many other companies do it to - not just payment processing companies, but web hosts, domain registrars etc etc etc.

as a general observation, there is something of a "freebie culture" on the internet. everyone wants everything "for free" and "if it isn't free, it's no good". nobody wants to pay anyone for anything unless they absolutely have to. why should they pay someone to build a website when they can build it themselves for free? all they need is a copy of frontpage. the trouble is, it takes time and they have to learn quite a lot to do it right. given a pile of bricks and a few bags of cement, they could also build their houses for free, but how many actually do that?

if you have a question about something else, ask in here and i'll answer as and when i can (unless someone beats me to it) - i'm an accredited partner of worldpay so i know quite a bit more than they normally tell everyone else.

topr8




msg:651096
 5:56 pm on Oct 11, 2002 (gmt 0)

funnily enough barclays merchant services (part of the high street bank) contacted me today.

i haven't tried it but what they are offering sounds reasonable although you would need a merchant account with them too (this is not too expensive)

one thing they are offering is recurring billing and no chargeback fees for fraud (of course you don't get the money back - just don't pay extra)

they also will do foreign currency transactions with a turnover of 20k a year, which is pretty low - in my experience you must charge in US$ if you want US customers

quiet_man




msg:651097
 6:43 pm on Oct 11, 2002 (gmt 0)

>>i think you somewhat misunderstand things here. worldpay (and others) are payment processors. they provide the payment facilities. when you sign up to a payment processing company, you are paying for the payment processing, not for web development or scripting services.<<

I'm not asking for web development. I'm not asking for scripting services. In the course of enquiring exactly what is required to integrate my system with WorldPay, it was suggested that I could use a Perl script. That's all. I'm not saying everyone needs to integrate that way. I've already said that I've found an alternate route anyway (without help from WorldPay). My exact words to Mike were "You may also find you have to pay for outside technical help to get your system integrated". This refers to the fact that not all customers will have Perl programming experience. No misunderstanding there, and in fact you obviously agree with me: >>if you need to do some programming and don't know the languages used, you can either learn the languages or employ someone to do it for you<<

>>it is your responsibility to provide and build the website and to integrate it with the payment processor (whatever company that may be).<<

My responsibility to build my own web site? Really? Thanks for the tip. My responsibility to integrate it with WorldPay? Well shouldn't I expect a modicum of direction from them, or do I just guess how to integrate? And when I say direction, I don't mean do my job for me, I mean at the very least tell me what I should expect to work during the trial stage and what won't work until it 'goes live'.

>>if the support question was about how to do perl coding (ie, to integrate your site), then you probably won't get a reply - it's not their job. what you need to do is employ someone or ask on forums etc.

The question was nothing to do with perl coding. I don't expect them to do my job. I just want them to do theirs. My specific question was whether I could expect a callback to be initiated during the trial stage, or whether it would only work once I have 'gone live' (since having followed their documented instructions, the callback was not initiated for me). Thats not even a technical question. The fact that I'm still waiting for a response after nine days is, in my opinion, abysmal.

I don't know what you were trying to say with your comments about 'freebie culture'. Perhaps you'd like to explore that in another thread? If its aimed at me, then I've just paid a lot of money to a company to provide me with a service (yes, payment processing, not web development or scripting) and they won't give me any useful direction on how to initiate this service. I'm not asking for anything for free.

Peace.

Dreamquick




msg:651098
 9:09 pm on Oct 11, 2002 (gmt 0)

quiet_man,

for what it's worth I seem to remember that we *could* get callbacks during the test/setup period but can't remember if this was on by default or whether it had to be enabled either in the form data, through their management interface or by phone.

console yourself with one fact : the only time anyone at netbanx is helpful is when they realise that you have moved to another cc processor - they are almost falling over themselves to be helpful then, but any other scenario and they don't seem to understand what customer support is.

- tony

Crazy_Fool




msg:651099
 10:26 pm on Oct 11, 2002 (gmt 0)

>>I'm not asking for web development. I'm not asking for scripting
>>services.

sorry, but you were slating worldpay because they won't give you help with perl code. quote:
WorldPay's tech support has been no help at all - they couldn't
even point me to any resources for cut and paste Perl scripts.

your words, not mine. my message was in reply to that comment. you were asking for help with your site (ie, web development or scripting services or whatever you want to call it).

>>My responsibility to build my own web site? Really? Thanks for the
>>tip.

that attitude won't encourage others to help you.

>>My responsibility to integrate it with WorldPay? Well shouldn't I
>>expect a modicum of direction from them, or do I just guess how to
>>integrate?

worldpay kindly wrote a manual and a lot of support pages. everything you need to know, and more, is in the manual and the support pages.

>>The question was nothing to do with perl coding. I don't expect
>>them to do my job. I just want them to do theirs. My specific
>>question was whether I could expect a callback to be initiated
>>during the trial stage, or whether it would only work once I
>>have 'gone live' (since having followed their documented
>>instructions, the callback was not initiated for me). Thats not
>>even a technical question. The fact that I'm still waiting for a
>>response after nine days is, in my opinion, abysmal.

the answer to whether or not you can expect a callback during the "trial stage" is in the manual. might also be in the extensive support pages although i havent read them for a long time. the answer is that everything works in testmode, except transactions will only be tests and no money will be taken from cards.

but the real question is, if you are expecting the callback to work, then why isn't it working? i could tell you why right now ... but i got a funny feeling that my efforts wouldn't be appreciated ....

>>I don't know what you were trying to say with your comments
>>about 'freebie culture'. Perhaps you'd like to explore that in
>>another thread? If its aimed at me, then I've just paid a lot of
>>money to a company to provide me with a service (yes, payment
>>processing, not web development or scripting) and they won't give
>>me any useful direction on how to initiate this service.

it was not aimed at you or anyone else, hence the words "as a general observation" at the start of the paragraph.

yes, you've paid for a service, and yes they have given you useful direction on how to initiate (integrate) the service - the manual and the support pages.

>>I'm not asking for anything for free.

that was the whole point of my previous message - you're expecting more than you've paid for and more than they provide. you've paid for the use of their systems and they've given you instructions for using them (including for integrating your site). you have not paid for an integration service or help finding code (which you did ask them for).

the same thing applies to all service providers, whether domain names, web hosting, ecommerce or anything else: you get the service you pay for. by all means ask for more for free, but it's no good getting narked at the service provider if you don't get it. it doesn't help you and it doesn't help them.

it's a bit late for you as you've already signed up, but for anyone else thinking of using worldpay, there are hundreds of worldpay partners, many of which will offer free integration or free shopping carts or free web hosting etc or other services to anyone signing up to worldpay through them.

seek and ye shall find.

Crazy_Fool




msg:651100
 11:02 pm on Oct 11, 2002 (gmt 0)

>>does anyone know of how much worldpay charge per month/transaction
>>and whether there are any setup fees?

for the basic internet merchant facilities for a business without a bank merchant account:
150 p/a (no monthly fees)
75 one time set up fee
4.5% credit cards transaction fees
50p debit card transaction fees
35p settlement

this includes 3 currencies. other fees will apply for other services, more currencies etc. uk businesses with bank merchant accounts get credit card transactions at 1.6% and debit cards at 25p. corporates may be able to get even lower rates.

gsx




msg:651101
 11:15 am on Oct 12, 2002 (gmt 0)

To add to Crazy_Fool:

6p per transaction for fraud prevention information (not opt-in/opt-out)

10 admin charge for any chargeback requests that any customer makes - whether proven true or false (except some Visa card with passwords).

Tax goes on top of all the above figures (including 4.5% - so if you are not tax registered you will pay more).

1.6% is about correct for standard card processing, corporations can get down to around 0.8%. But if you want to process company cards and enter the amount of VAT separately, the fee will shoot back up (worthwhile if a large customer requests VAT on their credit card statements - the card issuer cannot calculate the VAT amount because some items are at different rates).

quiet_man




msg:651102
 11:52 am on Oct 12, 2002 (gmt 0)

>>I'm not asking for web development. I'm not asking for scripting
>>services.
sorry, but you were slating worldpay because they won't give you help with perl code. quote:
WorldPay's tech support has been no help at all - they couldn't
even point me to any resources for cut and paste Perl scripts. <<
your words, not mine. my message was in reply to that comment. you were asking for help with your site (ie, web development or scripting services or whatever you want to call it).

When the tech support of a major service provider tells a customer he could use a Perl script to achieve what he needs to do, is it so over-the-top for that customer to respond by asking whether they have sample scripts or if they can direct me to a resource that does? I mean, I can't be the first person to ask. There's a huge difference between asking if they know of any suitable resources, and asking them to find a script for me.

but the real question is, if you are expecting the callback to work, then why isn't it working? i could tell you why right now ... but i got a funny feeling that my efforts wouldn't be appreciated ....

Actually I'd love to get this thing working and I'd shake hands with the devil to do so. But that's not what I was posting about. I'm not here asking for help. I'm simply trying to illustrate that - in my experience - WorldPay's tech support haven't been able to help me. I've followed their extensive support pages to the letter (I think. I'm sure I may done something wrong, but I can't for the life of me see what) and the callback won't work. And they won't tell me why. If you (Crazy_Fool) know right now, then presumably its a common mistake/issue? Shouldn't that be flagged in their tech support then?

>> ... freebie culture ...
it was not aimed at you or anyone else, hence the words "as a general observation" at the start of the paragraph.

It was contained in a posting that was directed primarily at me. The words 'general observation' could be general to the specifics of your post, or general to the world at large. Thanks for clarifying that it was the latter.

yes, you've paid for a service, and yes they have given you useful direction on how to initiate (integrate) the service - the manual and the support pages.

How can it be useful if it doesn't work?

>>I'm not asking for anything for free.
that was the whole point of my previous message - you're expecting more than you've paid for and more than they provide. you've paid for the use of their systems and they've given you instructions for using them (including for integrating your site). you have not paid for an integration service or help finding code (which you did ask them for).

So what this boils down to is that you think I'm asking for more than I've paid for by expecting an answer to a straightforward email question within nine days (an answer that is apparently obvious to people like you who are familiar with WorldPay). You also think I'm asking for more than I've paid for by enquiring, when told I need a Perl script, whether they have a sample library or know of any. So it looks like we have differing expectations of customer service then.

Crazy_Fool




msg:651103
 10:17 pm on Oct 12, 2002 (gmt 0)

>>6p per transaction for fraud prevention information (not opt-in/opt-out)
>>10 admin charge for any chargeback requests

better point out that neither of these are applicable if you have your own bank merchant account. (wouldn't life be so much easier if all service providers worked to the same standard system - an annual or monthly fee and a % of each transaction - so users could work out charges etc more easily?)

>>if you want to process company cards and enter the amount of VAT
>>separately, the fee will shoot back up

you can calculate tax (VAT or otherwise) in the shopping cart and process just the one total amount, saving any additional costs and hassle. pass the net cost and the VAT or other tax through the system and use the callback to create your own company VAT invoices.

Crazy_Fool




msg:651104
 1:12 am on Oct 13, 2002 (gmt 0)

>>When the tech support of a major service provider tells a customer
>>he could use a Perl script to achieve what he needs to do, is it so
>>over-the-top for that customer to respond by asking whether they
>>have sample scripts or if they can direct me to a resource that
>>does? I mean, I can't be the first person to ask.

did you need to ask when the answers have already been given?

on the subject of how much support you should expect etc, you might think it's perfectly reasonable to ask for this. others will too. but put yourself in the position of a service provider (any service provider, whether domains, hosting, ecommerce or whatever) and you might see things differently. lots of people asking lots of questions on a very wide range of topics, technologies, skill levels and so on. to answer them all you will need people with a lot of knowledge and you will need to pay them. and the cost of providing this extra level of support has to be passed on the end user - you, the customer.

worldpay, like many other systems, is "platform independent". you can build your site any way you want. you can use any scripting languages you want (if you want to use them that is). you can use any web server you want. imagine the range and diversity of questions that might be asked: questions about perl, asp, php, coldfusion, javascript, jsp and other scripting languages, shopping carts, hosting, and the list goes on and on and on. where does a service provider draw the line at which no further additional support will be provided?

and if you are a service provider and you start giving additional help, you soon find that once you've answered one question, the customer tends to come back with another. then another. and another ....

in this case, as with almost all service providers, the support service is for the service provided and paid for. there are docs and support pages that give a vast amount of information above and beyond the this. the simple rule (as applicable to virtually all service providers, whether domains, hosting, ecommerce or whatever) is that if you cannot do it yourself using the information given, then you need to employ someone to do it for you. sometimes you'll get lucky and get extra help, but more often than not, you won't.

now on the subject of the technical help:
[support.worldpay.com...] - guide to select junior and includes some basic example code for sending items to the worldpay system. how you create this code (or any variation on it such as to send multiple items through the system using M_) is up to you. you could just have a static HTML page with the code in it to allow purchase of single items. you could use a shopping cart to allow purchase of multiple items. if you use a shopping cart, it can be written in any virtually programming language you like - the system is platform independent. the only requirement is that the HTML your cart generates contains those lines of code (and any others you may need).

the callback can also be written in any language you like and can do anything you want it to do. you could use one language for your shopping cart and another for your callback if you want. you could use your callback to display a pretty thank you page, or maybe to send you an email with customer and order details, or maybe to save details into a database, or to generate your own invoices or your own shipping information sheets to be stuck on boxes you send out, or if you are a domain registrar your callback could automatically register domain names, or if you are a web host, your callback could automatically set up web hosting accounts, or maybe all of the above and more. you can do absolutely anything with a callback script.

because there are so many uses for callback scripts and because they can be in any of several programming languages and can use any databases or email delivery systems, and because of the infinite variety of information you can pass through the system using M_, there is no way to realistically provide one standard callback. if you want to use a callback, you generally need to write your own to do what you want with the system you have. they have given you the parameters that are passed as standard - you just need to write your script to receive these and deal with them (see below as well).

if you can't write your own shopping carts and callback scripts, you have the choice of several shopping carts from this page:
[support.worldpay.com...]
these will often include callback scripts. (at least one of my carts will be added there sometime in the next couple of months)

you can also try the search engines and scripting sites for shopping carts - if you find one you like, just make sure the final page includes the HTML code as above. if the cart doesn't have a callback, you need to write one or employ someone to write one.

>>I'm simply trying to illustrate that - in my experience -
>>WorldPay's tech support haven't been able to help me.

but you are also blaming them, when in fact what you are blaming them for is *your* responsibility.

>>I've followed their extensive support pages to the letter (I think.
>>I'm sure I may done something wrong, but I can't for the life of me
>>see what) and the callback won't work. And they won't tell me why.

their part of the callback (sending the response to your server) is probably working fine. the most likely causes for callbacks failing are that:
- you have set the wrong URL in the worldpay CMS, or
- you have not ticked the checkboxes in the CMS, or
- your callback is suspended because of previous failures, or
- you have set a password and your script is not checking it properly, or
- your callback script is broken

if the worldpay system detects an error response from your callback script, rather than displaying the error (which not only looks unprofessional but causes customers to panic and chargeback), it will display the standard worldpay payment completion page. you may also get a callback failure email when the callback first fails. i *think* that when it fails the first time, you get the email and callbacks are suspended and you then have to "unsuspend" the callback to try it again.

if you are sure that your CMS is set up with the correct URL and the relevant checkboxes are ticked or unticked as necessary, and you are either not using the password or you have definitely used the correct password, then the problem is with your code.

one easy way to check whether you code is working or not is to bypass the worldpay system and call the callback script directly from the final page in your shopping cart. go on your site and add a few products to the cart then proceed to the final page in your cart. then view the source, copy it, paste it into your text editor and save it as something like "callbacktest.html". then edit the code slightly. you will need to change the <form> tag to use the URL of your callback script and add the following line:
<input type="hidden" name="transStatus" value="Y">
you may need to delete any lines that are not passed back from the worldpay system - this includes but is not limited to testMode, accId1, authMode, instId, currency. then save the file and open it in your browser.

now click your submit button and you should go straight to the callback script, which should behave exactly as it does when called by worldpay. if you get an error then you will see what the error is instead of seeing the default worldpay completion page. when you've fixed all the errors, you should be able to run a test transaction through the worldpay system and the callback should work just fine.

>>If you (Crazy_Fool) know right now, then presumably its a common
>>mistake/issue? Shouldn't that be flagged in their tech support
>>then?

the docs say how to set up the worldpay system to use the callback and what parameters will be sent back to your server in the callback. if you set up the system correctly and write your code correctly, then everything will work correctly. in very simple terms, if it doesn't work, you've done something wrong. no real need to flag that. you just need to go back and fix whatever is wrong.

>>So what this boils down to is that you think I'm asking for more
>>than I've paid for by expecting an answer to a straightforward
>>email question within nine days (an answer that is apparently
>>obvious to people like you who are familiar with WorldPay). You
>>also think I'm asking for more than I've paid for by enquiring,
>>when told I need a Perl script, whether they have a sample library
>>or know of any. So it looks like we have differing expectations of
>>customer service then.

did you really need to send that email? and did you really need to wait 9 days and then complain about it in these forums?

the necessary information has already been provided. additional information has already been provided. anyone with the necessary skills can set their sites up. anyone without those skills *may* be able to set their sites up, but if not, alternatives have been provided in terms of links to a number of ready made shopping carts. and if they are not suitable, a quick search on google will find plenty more shopping carts with callbacks for use with worldpay. and if that isn't enough, there are plenty of web developers willing and able to write scripts or bespoke shopping carts, or to integrate sites with systems like worldpay's.

quiet_man




msg:651105
 9:45 am on Oct 14, 2002 (gmt 0)

Crazy_Fool - everything you have said actually supports the central point made in my very first post here, which is that when considering the costs and features of a PSP you may have to factor in the costs of integration. Specifically, I said - and you have confirmed - that you may have to factor in the costs of outside technical help.

Our only differences arise from the reasons for this state of affairs. Personally I thought I was paying for a payment service AND help with integration. You believe that I paid only for a service and am not entitled to assistance with integration. My expectations about WorldPay's tech support are based purely on WorldPay itself - their sales pitch, the fact that they encourage new customers to use their email support service. If only they were upfront and honest about it and just admitted that customers had not paid for help with integration, then no-one would be justified in their frustration or disappointment. Don't claim to offer what you don't provide.

I appreciate the time you took to share a lot of technical knowledge about WorldPay in your previous post. It looks like it may be of great help both to me and anyone else reading this thread. But - and I hope this doesn't sound ungrateful - the quality and depth of this one posting only goes to highlight the paucity of WorldPay's tech support to me. Now here's the thing - if I should only expect that sort of quality from a paid-for integrator, then they should be upfront and say so. If WorldPay were to say to new customers, "here's where you'll find our integration docs. If you have trouble with these, we suggest you consult a programmer/integrator. (And by the way, here's a list of our accredited partners who are available for hire)", then we'd all know where we stand. Just don't go through the charade of claiming to offer help and support and then not bother answering customer emails.

Shakil




msg:651106
 10:24 am on Oct 14, 2002 (gmt 0)

mnorton, not sure what line of business you are in, however if its NOT Adult/Gambling etc etc, then the following would be best in my opinion:

Barclaycard Merchant Services for the merchant account.....

combeined with SecPay or SecureTrading for the payment processing.

both companies are very reliable and competetive.

Shak

Crazy_Fool




msg:651107
 12:35 am on Oct 15, 2002 (gmt 0)

>>Our only differences arise from the reasons for this state of
>>affairs. Personally I thought I was paying for a payment service
>>AND help with integration. You believe that I paid only for a
>>service and am not entitled to assistance with integration.

not quite. you are entitled to assistance with integration and you will get it. where we differ in opinions is on how far this assistance extends.

integration support will generally start from the point at which you have generated the HTML code to send to the system. how you generate that HTML code is up to you - it's entirely your responsibility. typical problems i've seen are people missing required fields out, setting field names incorrectly and so on. support will generally end with the details that are sent out to your server in the callback. what you do with it once it's sent out is up to you - it's entirely your responsibility. all of this support is given in the documents and the support pages. support staff are available to help with all of this.

you might like to think of it like this: a bus driver may help you get on the bus, but you need to get to the bus stop yourself - he won't get you there. the bus driver might also help you get off the bus, but he won't help you across the road or carry your shopping home for you. nobody ever expects anything more than this from the bus driver.

you need to get to the point of integration yourself using whatever means you can. that may be writing your own shopping cart, using a pre-written shopping cart with the code included, or employing someone to do this for you. likewise you need to make your own way out of the integration - you are given the information you need and you need to deal with it in whatever way suits you.

>>If only they were upfront and honest about it and just admitted
>>that customers had not paid for help with integration, then no-one
>>would be justified in their frustration or disappointment. Don't
>>claim to offer what you don't provide.

there is no dishonesty involved whatsoever - it's just that you expect more than you should. over-expection of services isn't a worldpay thing, it applies to virtually every internet based service. personally i blame this on the internet media for generating and promoting the "freebie culture" which leads to people expecting more than they should.

service provision on the internet is no different to any non-internet service provision - you pay for a service and you get that service. when you get on a bus, you pay to travel from one bus stop to another, no more. you might need help getting on and off the bus, and you should get it. what you won't get is help getting to or from the bus stop.

>>the quality and depth of this one posting only goes to highlight
>>the paucity of WorldPay's tech support to me.

worldpay are doing nothing different to any other service provider anywhere - they provide a service and they provide support for that service. their support is pretty damn good actually. what they don't provide is what you need - scripting and web development for your site. there is nothing unusual in any service provider providing support only for their own services. there is nothing unusual in expecting people to employ web developers when web development is required.

i will quite happily defend any service provider in situations where someone expects far more than they should. i have done so a number of times for various types of service.

>>Now here's the thing -
>>if I should only expect that sort of quality from a paid-for
>>integrator, then they should be upfront and say so.

quite why you expect so much for so little is beyond me. scripting takes time. time costs money. if you can expect worldpay to provide all this additional help for free, then surely you can expect other companies to do the same? if so, then surely you could have saved yourself (and others) a lot of time and effort simply by employing a web developer? after all, it wouldn't cost anything to do so.

>>If WorldPay were to say to new customers, "here's where you'll find
>>our integration docs. If you have trouble with these, we suggest
>>you consult a programmer/integrator.

just as with virtually all service providers, you are given the docs and the information you need. it's just plain old common sense that if you can't do everything yourself, you have to employ someone to do it for you or do something else instead. if you can't build an extension to your house, you employ a builder. if you can't cut your grass, you employ a gardener. if you can't build your website, you employ a web developer. what on earth is wrong with common sense?

they have lists of loads of ready made shopping carts you can use if you can't build your own and integrate it with their systems. some of these come with support from the shopping cart authors. what's wrong with that?

>>Just don't go through the charade of claiming to offer help and
>>support and then not bother answering customer emails.

there is no charade. there is help and support available, good quality support at that, but only for the services provided and not for scripting and web development - that's what web designers and developers are for.

at this point, i'm going to stop discussing this. continuing will only bore people (those that aren't bored already) and could lead to the thread being removed. i'm hoping (but doubtful) that i've got the message(s) across:
- you have paid for a service and you are getting that service
- you are also getting the support for that service
- there is no deceit
- you are simply expecting too much
- you need to rethink your expectations of service / support levels for every type of service

quiet_man




msg:651108
 9:53 am on Oct 15, 2002 (gmt 0)

Crazy_Fool: You're right, it is getting boring. So I'll only repeat one point: my expectations of WorldPay's tech support are based only on WorldPay's own assurances, not some general freebie culture. So don't tell me I don't feel misled by their salesperson, and don't tell me I need to rethink my expectations of support for every type of service - I will continue to base my expectations on what I am led to believe by each individual provider.
Now lets all get back to work.

gsx




msg:651109
 9:59 pm on Nov 19, 2002 (gmt 0)

"you can calculate tax (VAT or otherwise) in the shopping cart and process just the one total amount, saving any additional costs and hassle. pass the net cost and the VAT or other tax through the system and use the callback to create your own company VAT invoices."

CrazyFool, this wont work with some companies, for example:

I had a customer who gave every department their own credit cards. A large company. They could place 40-50 seperate orders per day. They did not want 40-50 invoices. No invoices were printed for the customer any more, but the VAT was added into the credit card machine (this is the extra cost). The customers credit card bill was then split up like a standard invoice and could be used legally for the taxman to VAT claims.

This meant they had just one figure to work with per month rather than several thousand invoices per month, and that was just from our company, think of all the others on top of that!

Talking to them, they saved tens of thousands of pounds worth of accountancy fees every year because of the saved time.

(Having said that - this was a multi-billion pound company).

Global Options:
 top home search open messages active posts  
 

Home / Forums Index / WebmasterWorld / Ecommerce
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved