Java applet parameters / stand-alone payments.

[doml]

Hi,

First time here. I've tried Googling, reading the Actinic guides, and searching the community here but haven't yet found anything relevant.

We have a client currently using Actinic 8.5 multi-user. Payments are handled by the Java applet; as I understand it the card details are encrypted by the applet and sent along with details of the order to an Actinic server. Later our client logs on to the Actinic server collects details of the order and runs the credit card details through his PDQ machine.

When I look at the source code of the page the Java applet sits in I see that a large number of parameters are passed to it, and therefore we could in principle create a page ourselves with a correct set of parameters and thereby set up a payment independently of the Actinic shopping cart.

Is there any documentation for the applet parameters? Or is the only way of finding out to examine the source code that puts this page together?

The client wishes to stick with the current system of accepting payments as it is the most cost-effective from his point of view. He says that the percentage he is charged for a credit card transaction is the standard cardholder-not-present charge, rather than the higher "internet transaction" charge that other payment providers ask for.

But on the other hand there is a requirement for generating orders / accepting payments independently of the actinic cart.

I hope I've explained the situation well enough to make sense.

[brian.mc]

Firstly, the Java applet in Actinic is rarely used these days.

If your client wants to continue processing payments manually, then they should get an SSL certificate, which will encrypt the card details before forwarding to them, thus offering a higher level of security to the customer.

Actinic offer a shared SSL certificate for £100 per year.

However, the trend is now moving towards online card processing, and there are several good reasons for going this way.

1. As your client already has a merchant account in place, they should be able to negotiate a good rate for online transactions - we get 0.01% above our manual rate for Visa & Mastercard, and 1p per transaction above for Maestro/Delta.

2. Much higher level of trust from customers, as trader does not get card details - these are held by the bank.

3. If you include Verified by Visa and 3D secure on your online processing package, the bank will pick up any chargebacks resulting from verified transactions.

4. You don't have to pay staff to manually enter card details - might not seem much, but if you consider that it probably takes about 2 minutes to process a card transaction through a PDQ machine, if you employ someone at minimum wage rate to do this it will cost you around 15p per transaction after you factor in holiday pay, NI Contributions etc.

5. No need to worry about security re customer card details held.

6. If you do not process payments online using Mastercard 3D Secure, you can not legally display the Maestro Logo on your website.

[doml]

Brian,

thanks. I think we were inclined to move towards using a payment provider anyway (I'm thinking Protx) but it makes it a lot easier if I can tell the client that the Java applet is on the way out. The cost of processing is not such an issue here (typical orders will be £500 upwards) but he was convinced that any online system would be significantly more expensive than the current manual system.

I'm not sure what you mean by the comments about getting an SSL certificate. As I understand it the Java applet encrypts the card details etc on the purchaser's computer and then sends this securely encrypted data direct to the Actinic server (i.e. not the site server). I'm not familiar with the rest of the process but I understand that Actinic use some sort of secure mechanism for getting the card details to the person actually plugging them into a machine. At no point do the credit card details exist on the webserver that's running the shop, encrypted or unencrypted.

But I could have misunderstood the mechanism.

[pinbrook]

You should really forget all about the Java Applet, it is only there for legacy reasons. See this post I wrote a week or so ago http://community.actinic.com/showpos...53&postcount=4

You can still do manual processing with Actinic's shared SSL service or your own SSL cert. the advantage of SSL is that you get the padlock.

If you measure things in trends, then the java applet was the trend in 1999.

SSL became more popular in the early 2000s pretty well killing off the Applet

but now the trend is to use a PSP. Most banks are now pushing www shops to PSP and soon with all the PCI DSS compliance you won't have a choice.