uShop English (U.S.) for 179!

uStorekeeper English (U.S.) for 149!

 Tech Support
       Support Policy
       Knowledge Base
       Reference Sites
       Software Piracy
       Legal Notices
       Privacy Policy
       Reseller Info
       Contact Us
       Site Map

Knowledge Base Lobby : uShop Support Conference : Programmer Tips
Jul-17-18 11:06 AM EST
Original Message
Author Ben Muis on 03-29-2002 at 16:17 (EST)
Barclays bank in the UK uses a system called Epdq to process credit cards. They need all the order details transferred to their server via a html page that is static and in a non-secure environment.

This would be a 'jump' page, that only functions to transfer information.

The customer details and sensitive details would only be taken on their site. This is the only way they will accept this.

Mandatory information:
epdqdata (encrypted string that is generated by ePDQ PRIOR to sending the complete data, this is done via a perl script and returned by ePDQ)
merchantdisplayname (store name that will be displayed during processing)
returnurl (where to send the customer to afterwards)
clientid (this is our merchant number)
oid (this is the order number)
chargetype (autorize or pre-authorize)
currencycode (in our case 826 which is sterling)
total (value of purchase formatted 1.00)

What is the best way to achieve this? Does anyone have experience with linking uShop to ePDQ? If so, can we share experiences?

Thanks and regards,
Ben Muis


Table Of Contents
  Additional info Ben Muis, 2002-03-29 16:31:45 (1)
            RE: Additional info Bill Weiner, 2002-04-01 06:40:28 (2)
                 Some details Ben Muis, 2002-04-07 14:25:03 (3)
                      RE: Some details Bill Weiner, 2002-04-07 22:01:39 (4)
                           OK then....just one more thing Ben Muis, 2002-04-08 02:40:47 (5)
                                RE: OK then....just one more thing Bill Weiner, 2002-04-09 05:23:02 (6)

Messages In This Discussion
         1. Additional info
        Author Ben Muis on 03-29-2002 at 16:31 (EST)
Will ePDQ work with any "off the shelf" Internet shop packages?

ePDQ should work with most Internet shopping baskets. The storefront must at least be capable of sending order details (the minimum being total value plus your ePDQ store data) using the HTTP "POST" protocol from a known fixed URL to the server. The storefront must also be capable of handling data returned from ePDQ via the HTTP "POST" protocol.
                 2. RE: Additional info
                Author Bill Weiner on 04-01-2002 at 06:40 (EST)
You may want to look into uShop's "CUSTOM" payment option and implementing the "get_custom_payment_button_html" subroutine that is located in the script. The "get_custom_payment_button_html" subroutine was designed/commented to allow for easy customization to POST data to an external payment processing system. Unfortunately, that information gets POSTed after uShop collects the customers billing/shipping information... and it sounds like ePDQ collects all that information too... and that ePDQ only needs the shopping cart information? If that's the case, it sounds like the uShop CGI script is not needed at all... and instead you just need a way to POST the shopping cart data from the Java applets to the ePDQ. That is not really an easy thing to do... but you may want to look at how this PAYPAL interface example does it... See the 1/25/2001 posting here for some ideas:
                         3. Some details
                        Author Ben Muis on 04-07-2002 at 14:25 (EST)
I have had a look at the Paypal interface. This is helpful, thanks.

To get me on the way with this could you help with the following information?

What is the variable for the total amount (after adding of handling / shipping / tax) called?

How do I add location related shipping, tax & handling if the customer does not use the checkout facility?

Thanks and regards,
                                 4. RE: Some details
                                Author Bill Weiner on 04-07-2002 at 22:01 (EST)
The variable corresponding to the grand total is called $totals_total. You can see other global variables that may be of use at the top of the script.

In regard to adding location related tax, shipping & handling information... as you can probably guess, if those values are based on the customer's location, then you'll have to determine the customer's location somehow. There's no way of getting around that.
                                         5. OK then....just one more thing
                                        Author Ben Muis on 04-08-2002 at 02:40 (EST)

Is there anyone that you know of that already has an applet available that is effectively a cut down version of the checkout applet, stripping it from credit card and other personal information fields but only asking the customer their country / state and the preferred shipping method?

I can then ad a 'view cart' applet underneath so they can see the total before proceeding.

If not, can you recommend anyone that has the relevant javascript experience to fix this?

Thanks and regards,
Ben Muis
                                                 6. RE: OK then....just one more thing
                                                Author Bill Weiner on 04-09-2002 at 05:23 (EST)
If you're still using the uShop CGI script... then you should just be able to modify the order_template.html to only show the fields you want. (Just cut out the other fields)

Otherwise, if you are trying to do everything on the Java-side of things, then there are uShop JavaScript Inteface (uShopJSI) functions to:

public void setBillingState(String newValue);
public void setBillingCountry(String newValue);
public void setShippingMethodName(String newValue);

So maybe you could utilize that API in correlation to a custom HTML form for collecting the information that you want.

Refer to the uShop Programmer's Guide for more information about interfacing uShop with JavaScripts:

Also see the "JavaScript Examples" in the uShop Applet Reference:

And possible see the example form in the 12/12/2000 posting at:

© 2003 Microburst Technologies, Inc.