1. COMP3121 E-Commerce Technologies Richard Henson University of Worcester November 2010

2. Week 7: More on Server-side Shopping Carts n Objectives  Discuss relative merits and problems of server-side shopping carts  Plan and design a relational database for use in storing product and customer data  Use pre-written server behaviours with the VWD environment  Integrate pre-written server behaviours to assemble a server-side shopping cart system

3. Shopping System Processes Extract buying Data for item Create product and order totals Display online order Extract customer details Send relevant details to secure server for online payment Display online invoice including any additional charges Provide fulfilment information to customer via email

4. Possible Data Model with entities/attributes added

5. Which comes first… the chicken or the egg? n Which to develop first… data model or process model?  Much debate… n Generally, it is considered to be a good idea to start with the data…  That means: »identifying the ENTITIES »modelling their relationships »Adding the ATTRIBUTES

6. Possible basic data (entity) model for a Shopping System customer Order line order product No entity relationships shown! Where does Shopping Cart fit?

7. Creating the Physical Database from a Logical Design n Database that can work with SQL required… n Popular options for small(ish) databases:  Microsoft Access »only Access 2000 onwards properly SQL compliant  MySQL »originally shareware for Unix »now available for W2K n Popular options for larger databases:  SQLServer  ORACLE

8. Testing the Logical Design with Physical Data… n It works on paper… n But a practical working model is needed:  create database tables  link them together, according to the Entity model you created  populate the tables with trial data of an appropriate format  make sure all is consistent

9. Typical RAD tool “errors”… n MUCH can go wrong…!!! n Before embarking on shopping cart development…  need to make sure all loca/remote web server settings are correct  screen fields and db fields must use the same format »mustn’t use “reserved words” or punctuation, inc spaces  users must have sufficient access rights to write to the database »this especially includes the “IIS process” user  major adjustments may be needed in response to a minor change in design… »TRUE OF MOST SOFTWARE DEVELOPMENT PROJECTS… »all the more reason to get the design right…

10. Benefits of using a RAD tool  Puts a huge array of asp.net objects and behaviours at your disposal  Provides the local, remote, and application/testing server options to aid development and testing  Helps you set up controls to support the execution of aspx files within the.net framework  Uses objects and behaviours to create GET and PUT HTML pages to interact with the database  Provides for seamless database connectivity  Allows easy ftping to a remote server on the www

11. Role of Server Behaviours in creating Product Pages n After the database has been thoughtfully designed…  it needs to be physically implemented n Server behaviours with appropriate embedded SQL are then required for:  picking the right data out of the remote database  writing data to the appropriate locations in HTML pages on the local client browser

12. Local storage of “remote” data n Asp.net supports local storage of data through the use of datasets  a local copy of various data fields held on one or more data tables on the remote database  simply a local copy of various data fields held on one or more data tables on the remote database  each field becomes a variable in local memory n The dataset fields map directly onto the fields in the remote database  new data can therefore always be stored locally until the appropriate server command is made that writes it to the remote database

13. The Dataset Display (one record) n As you have seen, VWD facilitates the set up of datasets & datagrids n Can then be used to display dataset data on a HTML page, as the shopping cart  a from/further control can be used to create a HTML table for displaying a single record  a navigation bar object can then be added and used to navigate to other records

14. Use of “Repeated Region” n To display Multiple Records from a defined dataset, the following procedure is needed:  highlight the row where data is displayed »data only – not column headings  choose “Repeat Region” from the available Server Behaviours  select the number of records you wish to display (10 is the default)

15. Making the Product Pages Attractive and Usable n All the principles of web page design learned in COMP1141, 2121, 2040, etc. should still apply:  use Templates and CSS if possible to give all the pages a common background layout and that same look and feel  also make use of VWD’s client behaviours, written in various languages  make sure the pages load quickly by using software such as Photo Editor or PhotoShop keeping graphics small, of lower resolution, or both

16. Encouraging Customer Interaction n The next stage of the product pages is the customer interactivity that represents buying n Again, server behaviours must be written/engineered/used to extract the data from various types of HTML forms and store it:  temporarily in the local datasets  permanently in the remote database

17. How to capture “buying” data n Needs to be triggered from the shopping pages  hotlink that passes the product record ID to a newly created session cookie »Known as THE CART…  and extracts other data to the cart from the product table e.g. price n Each new cookie needs an ID  a cookie represents an order… »orderID represents cookieID  each new product ordered creates an orderline »Each orderline needs an ID n In a real shopping systems, orders and orderlines are saved to a remote database  essential for a business to keep transaction records…

18. When to collect customer data n Long standing debate amongst shopping cart designers… n Can either:  make customers “register” when they enter the site  Or… only make customers register when they are ready to buy n The former might be better from a marketing perspective (collecting “intelligence” on potential customers…)  but will put some customers off even browsing the site n Customer registration only when buying is preferable IMHO

19. The Shopping Cart n In Dreamweaver terms, this is a dataset…  extracted from fields from different tables, held on a remote database »products »orders »order-items in a specific order  stored securely in local memory  easily extracted for screen display

20. Displaying the Shopping Cart n A web page needs to be designed to display cart data from the dataset in an appropriate place n A table design tool saves time…  rows and columns as appropriate…  programming code extracts and display data in the cells

21. Display of Shopping Calculations n Expectation that a shopping cart will display… »a line for each product – including line total »and an order total n For the display of line totals and order totals…  calculations need to be included  cart fields needed for results of these calculations n Creation of the cart display is then a simply a matter of:  extracting data from a local recordset/dataset  displaying it on the pre-formatted page

22. Secure storage/Retrieval of Shopping Cart Data n Sensitive and Private Data should be secure  remote storage obviously better! n Cart data is best held locally for quick response – dilemma? n Compromise  use local datasets with high level of local security  only store non-sensitive data in cart fields n Solution: cart data held locally as a “session cookie”…  deleted as soon as the customer logs out…

23. Issues with Customer Data n Not stored with the cart but customer details capture is a crucial part of the shopping SYSTEM n Private Data!!!  MUST (1998 Data Protection Act) be kept up to date, stored and moved securely  better not to store locally  write directly to/from the remote, secure, database  always sent/received using secure http

24. Essential Customer Fields for Purchase n Name & address fields  include postcode n Email address  fulfilment information & messages n Telephone no  in case email fails n Shipping address fields  customer may not want goods delivered to the same address…

25. Handling Customer Data n Added by the customer to a HTML form  extracted by put or get  sent securely using http-s  Processed remotely on a secure server & stored on a secure remote database  sensitive data (e.g. customer’s credit card details) should be sent securely to a specialist provider with an SSL certificate »can only send such data via https over a secure connection to a secure server n Under no circumstances should ANY customer data be dealt with using standard HTTP!

26. On-line Payment Systems n Requires an effective & highly secure method of: 1.authentication of the user 2.authorisation of the amount required for payment (has to follow authentication) n BOTH effectively achieved through an on- line link to the International banking system n Usually a fee required to make this link  makes sense to do authentication & authorisation at the same time  some shopping cart payment systems authenticate NOW, and authorise LATER

27. Authentication (Is the user really who they say they are?) n Will require confirmation of:  name  type of account  account number  other information (e.g. start date, expiry date, issue number), depending on the type of account

28. Authorisation (even if they are that person, can they pay?) n Just because the user has that account with those details, doesn’t mean they have the funds available to pay for the goods… n The account needs to be checked against the invoice amount to make sure that the account has sufficient funds…

29. B2B Payment Systems n B2B systems usually make use of EFT (Electronic funds Transfer) n Both buyer and seller need to contact relevant bank computer:  for authentication purposes  to transfer funds n On-line banking system needs to be very secure:  512 bit encryption  private networks with secure gateway from the Internet

30. B2C Payment Systems n Payment take place through the vendors web site  most popular method - credit or debit card n Relevant bank computer needs to be contacted  uses The Internet to find gateway to bank network  security between bank, server, and browser a major issue - use VPN & secure protocols such as SSL & http-s  Once within the International Banking Network, similar authentication and funds transfer systems as for B2B

31. Security Issues with B2C Payment Systems n Data could technically be intercepted either:  at the user’s browser  at the vendor’s server  at the gateway to the International Banking Network  en-route between any of the above n Correct use of VPNs (Virtual Private Networks), with encryption and secure protocols throughout make it extremely unlikely that data will be intercepted en route

32. Protection of “Data at Rest” n The Internet allows any node to be a potential target…  Some early systems stored credit card details on the vendor’s server »asking for trouble!  Some concern also about the “secure servers” of merchant service providers »must hold e.g. credit card numbers stored in an encrypted format n Client browser only holds screen payment data in computer memory  local hard disk would be a potential security hole…

33. Securing those Merchant Servers n Server security a a matter of:  configuration and management of the server software  setting appropriate user privileges and file security  auditing of all access to confidential data  appropriate monitoring of attempted entry to the system by “invalid” users n Probably a lot safer to have credit details held here than written down by a stranger at the other end of the telephone line…

34. Keeping the Customer Informed! n Relatively easy to produce a system to keep the customer informed about their order n Importance of taking the trouble to do this is paramount, bearing in mind that customers may be from overseas n Easiest way to communicate progress with customer is to use email n Possible to send messages when:  credit details are authenticated  order is paid for  order is picked  order is dispatched

35. Summary of Main Points n Very good reasons for making both product pages and shopping cart client-server n Client-server shopping system must have a well designed database held remotely n Cart & cart fields should be held in local computer whilst user is logged on n Customer data should be held remotely n Standard shopping cart should not handle online payment data at all, just forward it securely

36. Good Planning for Shopping Systems n Develop the data model (database) n Plan the shopping pages n Identify the scripts needed to store customer shopping data, produce the cart and invoice n Plan the datasets that will be used for temporary data storage n Choose an Implementation model for the data model (e.g. IIS, asp, MDAP, Access) n Select a Payment System that works with the Implementation model chosen