Luận văn Giải pháp thương mại điện tử cho thuê bao di động

Tài liệu Luận văn Giải pháp thương mại điện tử cho thuê bao di động: ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ NGUYỄN MINH TÚ GIẢI PHÁP THƯƠNG MẠI ĐIỆN TỬ CHO THUÊ BAO DI ĐỘNG LUẬN VĂN THẠC SĨ Hà Nội - 2009 ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ NGUYỄN MINH TÚ GIẢI PHÁP THƯƠNG MẠI ĐIỆN TỬ CHO THUÊ BAO DI ĐỘNG Ngành: Công nghệ thông tin Chuyên ngành: Truyền dữ liệu và mạng máy tính Mã số: 60 48 15 LUẬN VĂN THẠC SĨ NGƯỜI HƯỚNG DẪN KHOA HỌC TS. Nguyễn Văn Hùng Hà Nội - 2009 \ LỜI CẢM ƠN Đầu tiên, tôi xin được gửi lời cảm ơn chân thành tới TS. Nguyễn Văn Hùng, người thầy đã tận tình hướng dẫn tôi trong quá trình làm luận văn, đến ThS. Nguyễn Nam Hải người đã chỉ bảo và giúp đỡ tôi nhiều về mặt chuyên môn. Tôi cũng xin gửi lời cảm ơn tới các cán bộ tại Trung tâm máy tính, tới các đồng nghiệp tại công ty cổ phần giải pháp thanh toán Việt Nam đã giúp đỡ tạo điều kiện cho tôi trong quá trình làm việc và thực hiện luận văn. Cuối cùng, tôi xin cảm ơn gia đình và bạn bè là những người luô...

pdf67 trang | Chia sẻ: haohao | Lượt xem: 1115 | Lượt tải: 1download
Bạn đang xem trước 20 trang mẫu tài liệu Luận văn Giải pháp thương mại điện tử cho thuê bao di động, để tải tài liệu gốc về máy bạn click vào nút DOWNLOAD ở trên
ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ NGUYỄN MINH TÚ GIẢI PHÁP THƯƠNG MẠI ĐIỆN TỬ CHO THUÊ BAO DI ĐỘNG LUẬN VĂN THẠC SĨ Hà Nội - 2009 ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ NGUYỄN MINH TÚ GIẢI PHÁP THƯƠNG MẠI ĐIỆN TỬ CHO THUÊ BAO DI ĐỘNG Ngành: Công nghệ thông tin Chuyên ngành: Truyền dữ liệu và mạng máy tính Mã số: 60 48 15 LUẬN VĂN THẠC SĨ NGƯỜI HƯỚNG DẪN KHOA HỌC TS. Nguyễn Văn Hùng Hà Nội - 2009 \ LỜI CẢM ƠN Đầu tiên, tôi xin được gửi lời cảm ơn chân thành tới TS. Nguyễn Văn Hùng, người thầy đã tận tình hướng dẫn tôi trong quá trình làm luận văn, đến ThS. Nguyễn Nam Hải người đã chỉ bảo và giúp đỡ tôi nhiều về mặt chuyên môn. Tôi cũng xin gửi lời cảm ơn tới các cán bộ tại Trung tâm máy tính, tới các đồng nghiệp tại công ty cổ phần giải pháp thanh toán Việt Nam đã giúp đỡ tạo điều kiện cho tôi trong quá trình làm việc và thực hiện luận văn. Cuối cùng, tôi xin cảm ơn gia đình và bạn bè là những người luôn ở bên động viên cổ vũ tôi trong suốt quá trình học tập. Hà Nội, ngày 23/10/2009 Nguyễn Minh Tú LỜI CAM ĐOAN Tôi xin cam đoan kết quả đạt được trong luận văn là sản phẩm của riêng cá nhân, không sao chép lại của người khác. Trong toàn bộ nội dung của luận văn, những điều được trình bày hoặc là của cá nhân hoặc là được tổng hợp từ nhiều nguồn tài liệu. Tất cả các tài liệu tham khảo đều có xuất xứ rõ ràng và được trích dẫn hợp pháp. Tôi xin hoàn toàn chịu trách nhiệm và chịu mọi hình thức kỷ luật theo quy định cho lời cam đoan của mình. Hà Nội, ngày 23 tháng 10 năm 2009 Nguyễn Minh Tú MỤC LỤC DANH MỤC CÁC CHỮ VIẾT TẮT DANH MỤC HÌNH VẼ VÀ BẢNG BIỂU MỞ ĐẦU .............................................................................................................................. 1 CHƯƠNG 1: THƯƠNG MẠI ĐIỆN TỬ ............................................................................ 2 1.1. Định nghĩa .................................................................................................................. 2 1.2. Các đặc trưng của thương mại điện tử ......................................................................... 2 1.3. Các cơ sở để phát triển thương mại điện tử.................................................................. 4 1.4. Các mô hình thương mại điện tử ................................................................................. 4 1.5. Các hình thức hoạt động chủ yếu của thương mại điện tử ............................................ 5 CHƯƠNG 2: CÁC KHÁI NIỆM CHUNG ......................................................................... 7 2.1. Giao thức SMPP V3.4................................................................................................. 7 2.1.1. Định nghĩa giao thức SMPP................................................................................. 8 2.1.2. Phiên làm việc SMPP........................................................................................... 9 2.1.3. Tầng kết nối mạng SMPP................................................................................... 10 2.1.4. Gửi tin nhắn SMPP từ ESME tới SMSC ............................................................. 11 2.1.5. Gửi tin nhắn SMPP từ SMSC tới ESME ............................................................. 13 2.1.6. Trao đổi tin nhắn song công giữa SMSC và ESME............................................. 15 2.2. Chuẩn ISO8583........................................................................................................ 17 2.2.1. Thông tin header................................................................................................ 17 2.2.2. Kiểu nhận dạng thông điệp (MTI - Message Type Identifier) .............................. 17 2.2.3. Loại message thực hiện với ngân hàng............................................................... 21 2.2.4. Bitmaps.............................................................................................................. 22 2.2.5. Thông điệp giao dịch 0200/0210 ........................................................................ 22 2.3. Các vấn đề bảo mật trong thương mại điện tử............................................................ 26 2.3.1. Giao thức bảo mật SSL....................................................................................... 27 2.3.2. Mật khẩu OTP.................................................................................................... 28 CHƯƠNG 3: THƯƠNG MẠI ĐIỆN TỬ CHO THUÊ BAO DI ĐỘNG.......................... 29 3.1. Bài toán..................................................................................................................... 29 3.2. Mô hình thẻ trả trước PrepaidCard ............................................................................ 32 3.2.1. Phát hành thẻ..................................................................................................... 32 3.2.2. Kích hoạt thẻ...................................................................................................... 33 3.2.3. Chấp nhận thẻ.................................................................................................... 34 3.2.4. Mô hình cơ sở dữ liệu PrepaidCard ................................................................... 38 3.3. Hệ thống tài khoản Airtime ....................................................................................... 39 3.3.1. Quản lý thông tin khách hàng............................................................................. 39 3.3.2. Quản lý tài khoản............................................................................................... 39 3.3.3. Quản lý hạn mức................................................................................................ 39 3.3.4. Dịch vụ khách hàng............................................................................................ 40 3.3.5. Luồng nạp tiền tài khoản Airtime ....................................................................... 42 3.3.6. Mô hình cơ sở dữ liệu Airtime ............................................................................ 43 3.4. Kết nối doanh nghiệp bán hàng ................................................................................. 44 3.4.1. URL của nhà cung cấp ....................................................................................... 44 3.4.2. URL doanh nghiệp kết nối.................................................................................. 45 3.4.3. Hàm xác thực giữa nhà cung cấp và doanh nghiệp............................................. 45 CHƯƠNG 4: TRIỂN KHAI .............................................................................................. 48 4.1. Phân tích thiết kế....................................................................................................... 48 4.1.1. Các chức năng ................................................................................................... 48 4.1.2. Biểu đồ Use Case ............................................................................................... 49 4.2. Triển khai thực tế ...................................................................................................... 52 KẾT LUẬN ........................................................................................................................ 55 TÀI LIỆU THAM KHẢO PHỤ LỤC DANH MỤC CÁC CHỮ VIẾT TẮT ATM Automated teller machine B2B Bussines to Bussines B2C Bussines to Customer CDMA Code division multiple access ESME External short messaging entity IDEN Integrated digital enhanced network OTP One time password PDU Protocol data unit PIN Personal identification number SMPP Short message peer-to-peer SMS Short message services SMSC Short message service center SSL Secure sockets layer TDMA Time division multiple access TMĐT Thương mại điện tử UML Unified Modeling Language URL Uniform resource Locator USSD Unstructured supplementary service data DANH MỤC HÌNH VẼ VÀ BẢNG BIỂU Hình 2.1 SMPP trong mạng di động ............................................................................8 Hình 2.2 Kết nối SMSC và ESME qua SMPP..............................................................9 Hình 2.3 Mô hình giao tiếp SMPP giứa ESME và SMSC ..........................................10 Hình 2.4 Yêu cầu và phản hồi tuần tự SMPP cho ESME Transmitter ........................12 Hình 2.5 Yêu cầu và phản hồi tuần tự SMPP cho ESME Receiver .............................14 Hình 2.6 Yêu cầu và phản hồi tuần tự SMPP cho ESME Transceiver ........................16 Hình 2.7 Mô tả Bitmaps trong thông điệp ..................................................................22 Hình 2.8 Mô tả Bitmap thứ 1 trong thông điệp ...........................................................22 Hình 3.1 Hệ thống thương mại điện tử cho thuê bao di động......................................31 Hình 3.2 Mô hình cơ sở dữ liệu PrepaidCard .............................................................38 Hình 3.3 Luồng nạp tiền tài khoản Airtime ................................................................42 Hình 3.4 Mô hình cơ sở dữ liệu Airtime.....................................................................43 Hình 4.1 Biểu đồ khách hàng đăng ký dịch vụ Vnmart năm 2009 ..............................53 Hình 4.2 Biểu đồ số giao dịch Vnmart năm 2009 .......................................................53 Hình 4.3 Biều đố số giao dịch(số tiền >= 100.000) Vnmart năm 2009 .......................54 Bảng 2.1 Các loại giao dịch trên ATM.......................................................................21 Bảng 2.2 Các thông điệp mạng hỗ trợ ........................................................................21 Bảng 2.3 Thông điệp tài chính 0200/0210..................................................................26 1 MỞ ĐẦU Cùng với sự phát triển mạnh mẽ của các ngân hàng, các công ty viễn thông tại Việt Nam, người tiêu dùng hầu như ai cũng có thẻ trả trước tại ngân hàng và sử dụng điện thoại di động. Vậy hướng phát triển thương mại điện tử cho các thuê bao di động có tài khoản tại ngân hàng là một hình thức thanh toán mang lại nhiều an toàn và tiện lợi cho người tiêu dùng. Trong phạm vi luận văn “Giải pháp thương mại điện tử cho thuê bao di động”, chúng tôi muốn xây dựng một mô hình thanh toán thương mại điện tử cho thuê bao di động qua tin nhắn SMS hoặc các Website bán hàng. Với mục tiêu như vậy, cấu trúc của luận văn được chia làm 4 chương: Chương 1: Tổng quan về thương mại điện tử, giới thiệu các khái niệm cơ bản về thương mại điện tử, giới thiệu các mô hình thương mại điện tử. Chương 2: Giới thiệu các kiến thức về bảo mật trong thương mại điện tử, chuẩn giao tiếp SMPP với các công ty viễn thông, chuẩn giao tiếp ISO8583 với các ngân hàng. Chương 3: Đưa ra bài toán thương mại điện tử cho thuê bao di động có thể triển khai tại Việt Nam. Các bước xây dựng hệ thống thương mại điện tử thông qua việc kết nối với các ngân hàng, kết nối các công ty viễn thông, xây dựng hệ thống thẻ trả trước, xây dựng hệ thống tài khoản ảo và kết nối với đối tác bán hàng qua mạng. Chương 4: Thực nghiệm, trình bày các nội dung thực nghiệm mà luận văn đã tiến hành dựa trên phân tích ở chương 3. Cuối chương này là các đánh giá về kết quả đạt được và các hướng triển khai trong tương lai. 2 CHƯƠNG 1: THƯƠNG MẠI ĐIỆN TỬ 1.1. Định nghĩa Thương mại điện tử [14] là hình thức mua bán hàng hóa và dịch vụ thông qua mạng máy tính toàn cầu. Thương mại điện tử theo nghĩa rộng được định nghĩa trong luật mẫu về Thương mại điện tử của Ủy ban Liên Hợp quốc về Luật Thương mại Quốc tế: “Thuật ngữ Thương mại cần được diễn giải theo nghĩa rộng để bao quát các vấn đề phát sinh từ mọi quan hệ mang tính chất thương mại dù có hay không có hợp đồng. Các quan hệ mang tính thương mại bao gồm các giao dịch sau đây: bất cứ giao dịch nào về thương mại về cung cấp hoặc trao đổi hàng hóa dịch vụ; thỏa thuận phân phối; đại diện hoặc đại lý thương mại, ủy thác hoa hồng; cho thuê dài hạn; xây dựng các công trình; tư vấn; kỹ thuật công trình đầu tư; cấp vốn; ngân hàng; bảo hiểm; thỏa thuận khai thác hoặc tô nhượng; liên doanh các hình thức khác về hợp tác công nghiệp hoặc kinh doanh; chuyên chở hàng hóa hay hành khách bằng đường biển, đường không, đường sắt hoặc đường bộ”. Như vậy, có thể thấy rằng phạm vi của Thương mại điện tử rất rộng, bao quát hầu hết các lĩnh vực hoạt động kinh tế việc mua bán hàng hóa và dịch vụ chỉ là một trong hàng ngàn lĩnh vực áp dụng của Thương mại điện tử. Theo nghĩa hẹp thương mại điện tử chỉ gồm các hoạt động thương mại được tiến hành trên mạng máy tính mở như Internet. Trên thực tế chính các hoạt động thương mại điện tử qua mạng Internet đã làm phát sinh thuật ngữ Thương mại điện tử. Thương mại điện tử gồm các hoạt động mua bán hàng hóa và dịch vụ qua phương tiện điện tử, giao nhận các nội dung kỹ thuật số trên mạng, chuyển tiền điện tử, mua bán cổ phiếu điện tử, vận đơn điện tử, đấu giá thương mại, hợp tác thiết kế, tài nguyên mạng, mua sắm công cộng, tiếp thị trực tiếp với người tiêu dùng và các dịch vụ sau bán hàng. Thương mại điện tử được thực hiện đối với cả thương mại hàng hóa (ví dụ như hàng tiêu dùng, các thiết bị y tế chuyên dụng) và thương mại dịch vụ (ví dụ như dịch vụ cung cấp thông tin, dịch vụ pháp lý, tài chính); các hoạt động truyền thống (chăm sóc sức khỏe, giáo dục) và các hoạt động mới (ví dụ như siêu thị ảo). Thương mại điện tử đang trở thành một cuộc cách mạng làm thay đổi cách thức mua sắm của con người. 1.2. Các đặc trưng của thương mại điện tử So với các hoạt động thương mại truyền thống, thương mại điện tử có một số điểm khác biệt cơ bản sau: Các bên tiến hành giao dịch trong thương mại điện tử không tiếp xúc trực tiếp với nhau và không đòi hỏi phải biết nhau từ trước. 3 Trong thương mại truyền thống, các bên thường gặp gỡ nhau trực tiếp để tiến hành giao dịch. Các giao dịch được thực hiện chủ yếu theo nguyên tắc vật lý như chuyển tiền, séc hóa đơn, vận đơn, gửi báo cáo. Các phương tiện viễn thông như: fax, telex, … chỉ được sử dụng để trao đổi số liệu kinh doanh. Tuy nhiên, việc sử dụng các phương tiện điện tử trong thương mại truyền thống chỉ để chuyển tải thông tin một cách trực tiếp giữa hai đối tác trong cùng một giao dịch. Thương mại điện tử cho phép mọi người cùng tham gia từ các vùng xa xôi hẻo lánh đến khu vực đô thị lớn, tạo điều kiện cho tất cả mọi người ở khắp mọi nơi đều có cơ hội ngang nhau tham gia vào thị trường giao dịch toàn cầu và không đòi hỏi nhất thiết phải có mối quen biết với nhau. Các giao dịch trong thương mại truyền thống được thực hiện với sự tồn tại của khái niệm biên giới quốc gia, còn thương mại điện tử được thực hiện trong một thị trường không có biên giới (thị trường thống nhất toàn cầu). Thương mại điện tử trực tiếp tác động tới môi trường cạnh tranh toàn cầu. Thương mại điện tử ngày càng phát triển, thì máy tính cá nhân trở thành cửa sổ cho doanh nghiệp hướng ra thị trường trên khắp thế giới. Với thương mại điện tử, một doanh nhân dù mới thành lập đã có thể kinh doanh ở Nhật Bản, Đức, … mà không hề phải bước ra khỏi nhà, một công việc trước kia phải mất rất nhiều năm. Trong hoạt động giao dịch thương mại điện tử đều có sự tham ra của ít nhất ba chủ thể, trong đó có một bên không thể thiếu được là người cung cấp dịch vụ mạng, các cơ quan chứng thực. Trong thương mại điện tử, ngoài các chủ thể tham gia quan hệ giao dịch giống như thương mại truyền thống đã xuất hiện một bên thức ba đó là nhà cung cấp dịch vụ mạng, cơ quan chứng thực … là những người tạo môi trường cho các giao dịch thương mại điện tử. Nhà cung cấp dịch vụ mạng và cơ quan chứng thực có nhiệm vụ chuyển đi, lưu giữ các thông tin giữa các bên tham gia giao dịch thương mại điện tử, đồng thời họ cũng xác định độ tin cậy của các thông tin trong giao dịch thương mại điện tử. Đối với thương mại truyền thống thì mạng lưới thông tin chỉ là phương tiện để trao đổi dữ liệu, còn đối với thương mại điện tử thì mạng lưới thông tin chính là thị trường. Thông qua thương mại điện tử, nhiều loại hình kinh doanh mới được hình thành. Ví dụ: các dịch vụ gia tăng giá trị trên mạng máy tính hình thành nên các nhà trung gian ảo làm dịch vụ môi giới cho giới kinh doanh và tiêu dùng; các siêu thị ảo được hình thành để cung cấp hàng hóa và dịch vụ trên mạng máy tính. Các trang web nổi tiếng như Google hay Yahoo đóng vai trò cung cấp thông tin trên mạng. Các trang web này đã trở thành các khu chợ khổng lồ trên Internet. Với mỗi lần nhấn chuột, khách hàng có khả năng truy cập vào hàng ngàn các cửa hàng ảo khác 4 nhau và khả năng khách hàng vào thăm và mua hàng là rất cao. Người tiêu dùng đã bắt đầu mua trên mạng một số loại hàng hóa trước đây được coi là khó bán trên mạng. Nhiều người sẵn sàng trả thêm tiền để không phải đi tới tận cửa hàng. Một số công ty đã mời khách may đo quần áo trên mạng, tức là khách hàng chọn kiểu, gửi số đo theo hướng dẫn tới cửa hàng rồi sau một thời gian nhất định sẽ nhận được bộ quần áo theo đúng yêu cầu. Điều tưởng như không thể thực hiện được này cũng có rất nhiều người hưởng ứng. Các chủ cửa hàng thông thường ngày nay cũng đưa thông tin lên web để tiến tới khai thác mảng thị trường rộng lớn trên web bằng cách mở cửa hàng ảo. 1.3. Các cơ sở để phát triển thương mại điện tử Hạ tầng kỹ thuật Internet phải đủ nhanh, mạnh đảm bảo truyền tải các nội dung thông tin bao gồm âm thanh, hình ảnh trung thực và sống động. Một hạ tầng Internet mạnh cho phép cung cấp các dịch vụ như xem phim, xem TV, nghe nhạc, … trực tiếp. Chi phí kết nối Internet phải rẻ để đảm bảo số người dùng Internet lớn. Hạ tầng pháp lý: phải có luật về TMĐT công nhận tính pháp lý của các chứng từ điện tử, các hợp đồng điện tử ký qua mạng: phải có luật bảo vệ quyền sở hữu trí tuệ, bảo vệ sự riêng tư, bảo vệ người tiêu dùng, … để điều chỉnh các giao dịch qua mạng. Phải có cơ sở thanh toán điện tử an toàn bảo mật, thanh toán điện tử qua thẻ, qua tiền điện tử. Các ngân hàng phải triển khai hệ thống thanh toán điện tử rộng khắp. Phải có hệ thống cơ sở chuyển phát hàng nhanh chóng, kịp thời và tin cậy. Phải có hệ thống an toàn bảo mật cho các giao dịch, chống xâm nhập trái phép, chống virus, chống giả mạo. Phải có nhân lực am hiểu kinh doanh, công nghệ thông tin, thương mại điện tử để triển khai tiếp thị, quảng cáo, xúc tiến, bán hàng và thanh toán qua mạng. 1.4. Các mô hình thương mại điện tử Trong thương mại điện tử có ba chủ thể tham gia: Doanh nghiệp(B) giữ vai trò động lực phát triển TMĐT, người tiêu dùng(C) giữ vai trò quyết định sự thành công của TMĐT và chính phủ(G) giữ vai trò định hướng, điều tiết và quản lý. Từ các mối quan hệ giữa các chủ thể trên ta có các loại giao dịch: B2B, B2C, … trong đó B2B và B2C là hai loại hình thương mại điện tử quan trọng nhất. Business to Business (B2B): Mô hình TMĐT giữa các doanh nghiệp với doanh nghiệp, TMĐT B2B là việc thực hiện các giao dịch giữa các doanh nghiệp với nhau trên mạng. Ta thường gọi là giao dịch B2B. Các bên tham gia giao dịch B2B gồm: người trung gian trực tuyến, người mua và người bán. Các loại giao dịch B2B gồm: 5 mua ngay theo yêu cầu khi giá cả thích hợp và mua theo hợp đồng dài hạn, dựa trên đàm phán cá nhân giữa người mua và người bán. Bên bán: là mô hình dựa trên công nghệ web trong đó có một công ty bán và nhiều công ty mua. Có 3 phương pháp bán trực tiếp trong mô hình này: bán từ catalog điện tử, bán qua quá trình đấu giá, bán theo hợp đồng cung ứng dài hạn đã thỏa thuận trước. Công ty bán có thể là nhà sản xuất hoặc trung gian thông thường là nhà phân phối hay đại lý. Bên mua: một bên mua – nhiều bên bán. Sàn giao dịch: nhiều bên bán – nhiều bên mua. TMĐT phối hợp: Các đối tác phối hợp nhau ngay trong quá trình thiết kế chế tạo sản phẩm. Business to Customer(B2C): Mô hình TMĐT giữa doanh nghiệp và người tiêu dùng. Đây là mô hình bán lẻ trực tiếp đến người tiêu dùng. Trong TMĐT bán lẻ điện tử có thể là nhà sản xuất, hoặc từ một cửa hàng thông qua kênh phân phối. Hàng hóa bán lẻ trên mạng thường là hàng hóa, máy tính, đồ điện tử, dụng cụ thể thao, đồ dùng văn phòng, sách và âm nhạc, đồ chơi, sức khỏe, và mỹ phẩm,… Mô hình kinh doanh bán lẻ có thể phân loại theo quy mô các loại hàng hóa bán (tổng hợp, chuyên ngành), theo phạm vi địa lý (toàn cầu, khu vực), theo kênh bán (bán trực tiếp, bán qua kênh phân phối). Một số hình thức các cửa hàng bán lẻ trên mạng: Brick and mortar là loại cửa hàng bán lẻ kiểu truyền thống, không sử dụng interrnet, Click and mortar là loại cửa hàng bán lẻ truyền thống nhưng có kênh bán hàng qua mạng và cửa hàng ảo là cửa hàng bán lẻ hoàn toàn trên mạng mà không sử dụng kênh bán truyền thống. Hai loại giao dịch trên là giao dịch cơ bản của TMĐT. Ngoài ra trong TMĐT người ta còn sử dụng các loại giao dịch: G2B là mô hình thương mại điện tử giữa chính phủ và doanh nghiệp, G2C giữa chính phủ và công dân gọi là chính phủ điện tử, C2C giữa các người tiêu dùng và Mobile Commerce là thương mại điện tử thực hiện qua thuê bao di động. 1.5. Các hình thức hoạt động chủ yếu của thương mại điện tử Thư điện tử: Các doanh nghiệp, các cơ quan nhà nước,… sử dụng thư điện tử để gửi thư cho nhau một các trực tuyến thông qua mạng, gọi là thư điện tử (electronic mail, viết tắt là email). Thông tin trong thư điện tử không phải tuân theo một cấu trúc định trước nào. 6 Thanh toán điện tử: Thanh toán điện tử (electronic payment) là việc thanh toán tiền thông qua bức thư điện tử (electronic mesage) ví dụ trả lương bằng cách chuyển tiền trực tiếp vào tài khoản, trả tiền mua hàng bằng thẻ mua hàng, thẻ tín dụng … thực chất đều là dạng thanh toán điện tử đã mở rộng sang các lĩnh vực mới đó là: Trao đổi dữ liệu điện tử tài chính (Financial Electronic Data Interchange, gọi tắt là FEDI) chuyên phục vụ cho việc thanh toán điện tử giữa các công ty giao dịch với nhau bằng điện tử. Tiền lẻ điện tử (Internet Cash) là tiền mặt được mua từ một nơi phát hành (ngân hàng hoặc một tổ chức tính dụng nào đó), sau đó được chuyển đổi tự do sang các đồng tiền khác thông qua Internet, áp dụng trong cả phạm vi một nước cũng như giữa các quốc gia; tất cả đều được thực hiện bằng kỹ thuật số hóa, vì thế loại tiền này có tên gọi “tiền mặt số hóa” (digital cash). Tiền lẻ điện tử đang trên đà phát triển nhanh, nó có ưu điểm nổi bật sau:  Dùng để thanh toán những món hàng hóa có giá trị nhỏ, thậm chí ngay cả tiền mua báo (vì phí giao dịch mua hàng và chuyển tiền rất thấp).  Có thể tiến hành giữa hai người hoặc hai công ty bất kỳ, các thanh toán là vô danh.  Tiền mặt nhận được đảm bảo là tiền thật, tránh được tiền giả. Ví điện tử: Là nơi để tiền mặt Internet, chủ yếu là thẻ thông minh (smart card), còn gọi là thẻ giữ tiền (stored value card), tiền được trả cho bất kỳ ai đọc được thẻ đó; kỹ thuật của ví điện tử tương tự như kỹ thuật áp dụng cho “tiền lẻ điện tử”. Thẻ thông minh, nhình bề ngoài như thẻ tín dụng nhưng ở mặt sau của thẻ, có một chíp máy tính điện tử có thể lưu trữ tiền số hóa, tiền ấy chỉ được “chi trả” khi sử dụng thư yêu cầu (như xác nhận thanh toán hóa đơn) được xác thực là đúng. Giao dịch điện tử của ngân hàng (digital banking): Hệ thống thanh toán điện tử của ngân hàng là một hệ thống lớn gồm nhiều hệ thống nhỏ:  Thanh toán giữa ngân hàng với khách hàng qua điện thoại, tại các điểm bán lẻ, chuyển tiền điện tử, thẻ tín dụng, thông tin hỏi đáp, …  Thanh toán giữa ngân hàng với các đại lý thanh toán (nhà hàng, siêu thị).  Thanh toán nội bộ một hệ thống ngân hàng.  Thanh toán liên ngân hàng. 7 CHƯƠNG 2: CÁC KHÁI NIỆM CHUNG 2.1. Giao thức SMPP V3.4 Giao thức SMPP [6] (giao thức chuẩn gửi nhận tin nhắn giữa các thuê bao di động với các nhà cung cấp dịch vụ viễn thông) là giao thức mở, chuẩn công nghiệp để cung cấp cách thức truyền dữ liệu linh hoạt cho việc truyền tin nhắn giữa các tổng đài, ví dụ như tổng đài dịch vụ tin nhắn (SMSC), Các dịch vụ tin nhắn không cấu trúc (USSD) hoặc các loại tổng đài tin nhắn, tổng đài Wap server, cổng Email hoặc cổng tin nhắn. Giao thức SMPP 3.4 hỗ trợ các công nghệ với mạng viễn thông:  GSM  IS-95(CDMA)  ANSI-136 (TDMA)  IDEN Sử dụng giao thức SMPP, một hệ thống ứng dụng tin nhắn có thể gọi là các thực thể tin nhắn ngắn bên ngoài (ESME) thiết lập các kết nối ứng dụng tới SMSC thông qua giao thức TCP/IP hoặc là giao thức X.25 và có thể truyền và nhận tin nhắn từ SMSC. ESME có thể truy vấn, hủy yêu cầu hoặc thay đổi các tin nhắn với SMPP. SMPP hỗ trợ đầy đủ các chức năng của tin nhắn:  Truyền tin nhắn từ ESME tới một hoặc nhiều điểm qua SMSC.  ESME có thể nhận tin nhắn từ SMSC qua các trạm di động.  Truy vấn trạng thái của tin nhắn trên SMSC.  Từ chối hoặc thay đổi tin nhắn trên SMSC.  Gửi tin nhắn đăng ký.  Lên lịch gửi các tin nhắn theo ngày và thời gian.  Chọn chế độ tin nhắn: datagram hoặc lưu trữ và chuyển tiếp.  Thiết lập các độ ưu tiên của tin nhắn gửi đi.  Định nghĩa các kiểu dữ liệu của tin nhắn.  Thiết lập thời gian hiệu lực của tin nhắn.  Phân loại dịch vụ với từng tin nhắn. 8 Hình 2.1 SMPP trong mạng di động 2.1.1. Định nghĩa giao thức SMPP SMPP được xây dựng dựa trên sự trao đổi yêu cầu và đáp ứng các đơn vị giao thức dữ liệu (PDUs) giữa ESME và SMSC dựa trên kết nối TCP/IP hoặc X.25. Giao thức SMPP định nghĩa:  Tập các thao tác và kết hợp các đơn vị giao thức dữ liệu (PDUs) cho việc trao đổi tin nhắn giữa ESME và SMSC.  Dữ liệu của ứng dụng ESME có thể trao đổi với SMSC thông qua thao tác với giao thức SMPP. Sự trao đổi tin nhắn giữa ESME và SMSC có thể chia thành các nhóm sau:  Tin nhắn gửi từ ESME(Transmitter) tới SMSC.  Tinh nhắn gửi từ SMSC(Receiver) tới ESME.  Tin nhắn gửi từ ESME(Transceiver) tới SMSC và tin nhắn gửi từ SMSC tới ESME(Transceiver). SMSC Mobile Network Wap Proxy Server VMS User ESMEs 9 Hình 2.2 Kết nối SMSC và ESME qua SMPP 2.1.2. Phiên làm việc SMPP Một phiên SMPP giữa SMSC và ESME được thiết lập bới ESME tạo kết nối tới SMSC và sau đó sử dụng giao thức BIND yêu cầu mở một phiên SMPP. ESME đồng ý và nhận tin nhắn yêu cầu thiết lập hai kiểu kết nối (TCP/IP hoặc. X.25) và hai phiên SMPP(Transmitter và Receiver). Giao thức SMPP v3.4 hỗ trợ ESME thiết lập phiên SMPP Transceiver thông qua một kết nối mạng. Trong một phiên SMPP, ESME có thể gửi nhiều yêu cầu gửi tới SMSC và nhận được phản hồi thích hợp với từng yêu cầu từ SMSC. Tương tự SMSC có thể gửi nhiều yêu cầu tới ESME và cũng nhận được các phản hồi phù hợp. Một phiên SMPP được định nghĩa bởi một số trạng thái:  OPEN (Kết nối và chờ Bind): ESME kết nối tới SMSC nhưng chưa yêu cầu BIND để thiết lập phiên làm việc.  BOUND_TX: ESME kết nối thành công tới SMSC sẽ yêu cầu BIND một ESME Transmitter (bằng cách sử dụng bind_transmitter PDU) và nhận được phản hồi từ SMSC để xác thực yêu cầu.  BOUND_RX: ESME kết nối thành công tới SMSC sẽ yêu cầu BIND một ESME Receiver (bằng cách sử dụng bind_receiver PDU) và nhận được phản hồi từ SMSC để xác thực yêu cầu. SMSC SMPP I/F Transceiver Transmitter Receiver Network ESME-001: Wap Proxy Server ESME-003:Email Gateway ESME-002: Mobile Avert 10  BOUND_TRX: ESME kết nối thành công tới SMSC sẽ yêu cầu BIND một ESME Transceiver (bằng cách sử dụng bind_ transceiver PDU) và nhận được phản hồi từ SMSC để xác thực yêu cầu. ESME sử dụng Transceiver được hỗ trợ đầy đủ các thao tác sử dụng trong Transmitter ESME và Receiver ESME.  CLOSED (bỏ bound và ngắt kết nối): ESME bỏ bound từ SMSC và đóng kết nối. SMSC đồng thời tắt bind từ ESME. 2.1.3. Tầng kết nối mạng SMPP Tầng mạng giao tiếp giữa SMSC và ESME dựa trên kết nối TCP/IP hoặc X.25. SMPP là giao thức ở tầng ứng dụng và không có chức năng truyền dữ liệu. Ở tầng truyền dữ liệu sẽ cung cấp các phương thức truyền dữ liệu từ điểm tới điểm bao gồm việc mã hóa gói tin, chế độ cửa sổ, điều khiển luồng và kiểm soát lỗi. Ở mức SMPP, ESME và SMSC chỉ quan tâm đến kết nối mạng đơn thuần để truyền và nhận SMPP PDUs Hình vẽ dưới đây mô tả kết nối mạng SMPP giữa ESME và SMSC: Hình 2.3 Mô hình giao tiếp SMPP giứa ESME và SMSC Nếu cần nó sẽ yêu cầu lớp mạng gửi các thực thể theo segment của SMPP PDUs cho việc truyền phân mảnh các gói tin thông qua kết nối mạng. Lớp mạng sẽ nhận các thực thể, tập hợp các phân mảnh SMPP PDUs trước khi gửi thực thể SMPP PDU đi tới lớp SMPP. SMSC Interface N/W Layer TCP/IP or X.25 N/W Layer TCP/IP or X.25 SMPP SMPP SMSC Interface Packet encoding, Framentation, Windowing & Eror Handling of N/W Layer SMPP Encoding/Decoding by ESME/SMSC 11 2.1.4. Gửi tin nhắn SMPP từ ESME tới SMSC ESME gửi tin nhắn tới SMSC nên kết nối tới SMSC theo ESME Transmitter hoặc ESME Transceivier. Một tin nhắn SMPP PDUs được gửi từ ESME Transmitter tới SMSC bao gồm:  submit_sm  data_sm Trong điều kiện tin nhắn gửi tới SMSC, ESME có thể thực hiện theo các thao tác của SMPP bằng cách sử dụng định danh tin nhắn được trả về bởi SMSC:  query_sm: truy vấn SMSC về trạng thái của tin nhắn đăng ký.  cancel_sm: hủy các tin nhắn đã gửi.  replace_sm: thay đổi tin nhắn đã gửi. SMPP PDUs được gửi tới SMSC bằng ESME, nó nhận được phản hồi PDUs từ SMSC. Tin nhắn SMPP phản hồi từ SMSC tới ESME: SMPP PDU phản hồi cho một tin nhắn gửi từ SMSC bao gồm các tin nhắn định danh và một trạng thái trong trường hợp tin nhắn gửi đi hợp lệ hoặc không hợp lệ. Trong các trường hợp khác SMSC sẽ trả về thông báo lỗi thích hợp.  submit_sm_resp  data_sm_resp  query_sm_resp  cancel_sm_resp  replace_sm_resp Phiên tuần tự SMPP – ESME Transmitter: Hình vẽ dưới đây minh họa các yêu cầu và phản hồi tuần tự SMPP giữa SMSC và ESME với hình thức Transmitter: 12 Hình 2.4 Yêu cầu và phản hồi tuần tự SMPP cho ESME Transmitter  Sự trao đổi yêu cầu và phản hồi PDUs giữa ESME Transmitter và SMSC có thể đồng bộ hoặc không đồng bộ. Như vậy ESME có thể gửi nhiều yêu cầu tới SMSC, mà không cần đồng bộ trong khi chờ các phản hồi PDUs. bind_transmitter(1) ESME bind_transmitter_resp(1) SMSC submit_sm(2) submit_sm_resp(2) submit_sm(3) submit_sm(4) submit_sm(6) submit_sm_resp(3) ) submit_sm_resp(4) ) submit_sm_resp(6) ) query_sm_resp(5) query_sm(5) unbind(7) ) unbind_resp(7) ) 13  Các yêu cầu SMPP thành công được đưa ra không đồng bộ hóa bới ESME sẽ được truyền trong khoảng thời gian ngắn bởi một số các phản hồi từ SMSC.  SMSC thường trả các phản hồi SMPP tới ESME tương ứng với các yêu cầu gốc nhận được từ ESME. Không bắt buộc với ESME và SMPP phải có khả năng nhận các phản hồi không tuần tự. 2.1.5. Gửi tin nhắn SMPP từ SMSC tới ESME SMSC có thể gửi các tin nhắn tới ESME. Trong trường hợp này ESME nên kết nối tới SMSC như là ESME Receiver hoặc ESME Transceiver. Các ứng dụng ESME thao tác SMPP Receiver bao gồm:  Cổng email chấp nhận tin nhắn gửi từ thuê bao di động tới hộp thư Internet.  SMSC còn có thể gửi “delivery receipt” tới ESME chứa trạng thái của tin nhắn gửi trước đấy. SMPP PDUs được gửi từ SMSC tới ESME Receiver bao gồm:  deliver_sm  data_sm Tin nhắn SMPP phản hồi từ ESME tới SMSC SMPP PDU phản hồi từ ESME Receiver nên bảo vệ bởi nhận dạng giao dịch PDU(được lưu trong tham số sequence_number) được gửi bởi SMSC. Tin nhắn phản hồi bao gồm trạng thái câu lệnh được khai báo bởi SMSC để xem các tin nhắn gửi tới ESME là hợp lệ hay không hợp lệ. Trong các trường hợp khác ESME có thể gửi các thông báo lỗi thích hợp. Tin nhắn SMPP phản hồi gửi từ ESME Receiver tới SMSC bao gồm:  deliver_sm_resp  data_sm_resp Phiên tuần tự SMPP - ESME Receiver: Hình vẽ dưới đây minh họa các yêu cầu và phản hồi tuần tự SMPP giữa SMSC và ESME với hình thức Receiver: 14 Hình 2.5 Yêu cầu và phản hồi tuần tự SMPP cho ESME Receiver  Sự trao đổi yêu cầu và phản hồi PDUs giữa ESME Receiver và SMSC có thể đồng bộ hoặc không đồng bộ. Như vậy SMSC có thể gửi nhiều yêu cầu deliver_sm tới ESME, mà không cần đồng bộ trong khi chờ các phản hồi PDUs. bind_receiver(1) ESME bind_receiver_resp(1) SMSC deliver_sm(1) deliver _sm_resp(1) deliver _sm(2) deliver _sm(3) deliver _sm_resp(2) ) deliver _sm_resp(3) ) deliver _sm_resp(4) deliver _sm(4) unbind(2) ) unbind_resp(2) ) 15  Các yêu cầu SMPP thành công được đưa ra không đồng bộ hóa bới SMSC sẽ được truyền trong khoảng thời gian ngắn bởi một số các phản hồi từ ESME.  ESME thường trả các phản hồi SMPP tới SMSC tương ứng với các yêu cầu gốc được nhận từ SMSC. Không bắt buộc với SMSC và SMPP phải có khả năng nhận các phản hồi không tuần tự. 2.1.6. Trao đổi tin nhắn song công giữa SMSC và ESME SMSC và ESME có thể thiết lập phiên tin nhắn song công, tin nhắn có thể truyền đi và nhận về. Trong trường hợp này ESME kết nối tới SMSC theo ESME Transceiver. ESME sử dụng các ứng dụng thao tác với SMPP Transceiver bao gồm:  Tin nhắn được truyền hai chiều giữa thiết bị di động và ESME, ví dụ Wap Proxy Server. Khách hàng di động gửi yêu cầu tới WAP Proxy Server và thông tin phản hồi trả về thiết bị di động thông qua SMSC. Tin nhắn SMPP PDUs được gửi bởi phiên SMPP Transceiver bao gồm:  data_sm  submit_sm  deliver_sm Trong các điều kiện gửi tin nhắn tới SMSC, ESME có thể thực hiện các thao tác SMPP bằng các sử dụng các định danh của tin nhắn được trả bởi SMSC:  query_sm  cancel_sm  replace_sm Phiên SMPP tuần tự - ESME Transceiver: Hình vẽ dưới đây minh họa các yêu cầu và phản hồi tuần tự SMPP giữa SMSC và ESME với hình thức Transceiver: 16 Hình 2.6 Yêu cầu và phản hồi tuần tự SMPP cho ESME Transceiver  Sự trao đổi yêu cầu và phản hồi PDUs giữa SMSC và ESME Receiver có thể đồng bộ hoặc không đồng bộ. Như vậy SMSC có thể gửi nhiều yêu cầu data_sm tới ESME, mà không cần đồng bộ trong khi chờ các phản hồi PDUs. bind_transceiver(1) ESME bind_ transceiver _resp(1) SMSC data_sm(1) data_sm_resp(1) data_sm(2) data_sm_resp(2) data_sm(3) data_sm(3) ) data_sm_resp(3) ) data_sm_resp(3) ) data_sm_resp(2) data_sm(2) unbind(4) ) unbind_resp(4) ) 17  Các yêu cầu SMPP thành công được đưa ra không đồng bộ hóa bới SMSC sẽ được truyền trong khoảng thời gian ngắn bởi một số các phản hồi từ ESME.  ESME thường trả các phản hồi SMPP tới SMSC tương ứng với các yêu cầu gốc được nhận từ SMSC. Không bắt buộc với SMSC và SMPP phải có khả năng nhận các phản hồi không tuần tự. 2.2. Chuẩn ISO8583 Các định dạng thông điệp (message) trong giao dịch tài chính tuân theo chuẩn ISO8583 – 1987[12]. Mỗi thông điệp gồm các trường thông tin được sắp xếp theo thứ tự sau: thông tin header, kiểu nhận dạng thông điệp (message type identifier: MTI), 1 hoặc 2 hoặc 3 Bitmaps và một dãy các trường trong bảng các thành phần dữ liệu (data elements) đã được xác định trong Bitmaps. Hình dưới đây thể hiện thứ tự của các trường thông tin này: Header MTI Bitmaps Data Elements 2.2.1. Thông tin header Gồm 4 byte ký tự ASCII dùng để chỉ rõ độ dài của message, độ dài này không bao gồm phần header. Ví dụ: Nếu một message là 126 byte, thì đoạn “0126” sẽ được thêm vào phần đầu của message. Vì vậy độ dài thực sự của dữ liệu được gửi đi là 130 byte. 2.2.2. Kiểu nhận dạng thông điệp (MTI - Message Type Identifier) Trường đầu tiên của mỗi thông điệp bao gồm 4 ký tự số dùng để xác định các thông tin gồm: phiên bản của thông điệp (message version number), lớp thông điệp (message class), chức năng của thông điệp (message function) và cuối cùng là bên khởi tạo giao dịch (transaction originator).  Vị trí đầu tiên: phiên bản của thông điệp 0 – ISO 8583-1987. 1 – ISO 8583-1993. 2-7 – ISO sử dụng cho mục đích dự trữ. 8 – Được sử dụng cho các tổ chức quốc tế. 18 9 – Sử dụng với các mục đích riêng của từng ngân hàng.  Vị trí thứ hai: lớp thông điệp 0 – Sử dụng cho ISO làm mục đích dự trữ. 1 – Cấp phép chuẩn chi (authorization). 2 – Tài chính (financial). 3 – File action. 4 – Đảo ngược/bồi hoàn (reversal/chargeback). 5 – Đối chứng (reconciliation). 6 – Thủ tục (administrative). 7 – Thu phí (fee collection). 8 – Quản trị mạng (network management). 9 – ISO sử dụng cho mục đích dự trữ.  Vị trí thứ ba: chức năng của thông điệp. 0 – Yêu cầu (request). 1 – Trả lời yêu cầu (request response). 2 – Thông báo, có yêu cầu phản hồi (advice). 3 – Trả lời thông báo (advice response). 4 – Thông báo, không yêu cầu phản hồi (notification). 5-9 – ISO sử dụng cho mục đích dự trữ.  Vị trí thứ tư : bên khởi tạo giao dịch. 0 – Acquirer. 1 – Acquirer repeat. 2 – Card issuer. 3 – Card issuer repeat. 4 – Other. 5 – Other repeat. 6-9 – ISO sử dụng cho mục đích dự trữ. Chú ý: khi thông điệp lặp lại (repeat message) được sử dụng, thông điệp đó sẽ gần như giống hệt thông điệp gốc ngoại trừ một số trường thông tin như: kiểu nhận dạng thông điệp (MTI), thời điểm truyền thông điệp, … 19 Các lớp thông điệp tài chính bao gồm:  Lớp thông điệp cấp phép chuẩn chi (Authorization) – 01xx Lớp thông điệp 01xx được sử dụng cho các yêu cầu cấp phép trong các giao dịch thẻ tín dụng (credit card). Các thông điệp bao gồm: o 0100 Authorization request. o 0110 Authorization request response. o 0120 Authorization advice message. o 0130 Authorization advice response.  Lớp thông điệp tài chính (Financial) – 02xx Lớp thông điệp này được sử dụng cho các giao dịch tài chính. Giao dịch tài chính là các giao dịch mà tài khoản của khách hàng được trừ ngay lúc giao dịch. Do vậy các thông điệp lớp 02xx thường dành cho các giao dịch thẻ ghi nợ (debit card). Các thông điệp bao gồm: o 0200 Financial transaction request. o 0210 Financial transaction request response. o 0220 Financial transaction advice. o 0230 Financial transaction advice response. Thông điệp tài chính 02xx chuẩn chứa một thông điệp yêu cầu và một thông điệp trả lời. Các giao dịch tài chính điển hình gồm: rút tiền, vấn tin số dư, chuyển khoản,…  Lớp thông điệp file action – 03xx Thông điệp file action được sử dụng để thêm, thay đổi, xóa hoặc thay thế một file. Thông điệp này có thể được sử dụng để truy vấn vào một file hay thực hiện việc quản lý thẻ (ví dụ như bản báo cáo các thẻ bị mất). Trường bản ghi dữ liệu (Data Record – thành phần dữ liệu thứ 120 trong bảng các thành phần dữ liệu) được sử dụng để chứa các bản ghi file action hay các file thông tin khi thông điệp được truyền đi. Các thông điệp bao gồm: o 0302 Card issuer file update request. o 0312 Card issuer file update request response. 20 Các thông điệp bảo trì file được bên phát hành thẻ sử dụng để cập nhật hay truy vấn các file.  Lớp thông điệp đảo ngược (Reversal message) – 04xx Thông điệp đảo ngược sử dụng để hủy bỏ một phần hay toàn bộ hiệu lực của một giao dịch tài chính (02xx) hoặc cấp phép chuẩn chi (01xx) trước đó. Lớp thông điệp đảo ngược sẽ được khởi tạo bởi bên chấp nhận thẻ và cũng có thể được dùng cho tái xuất trình trong toàn bộ quá trình đòi bồi hoàn. Các thông điệp bao gồm: o 0420 Reversal request. o 0421 Reversal request repeat. o 0430 Reversal request response. Bên chấp nhận thẻ cũng có thể tạo một thông báo đảo ngược để thông báo cho bên phát hành thẻ về một tình trạng lỗi của một giao dịch tài chính trước đó. Các tình trạng lỗi bao gồm: Một giao dịch đã được chấp thuận bị hủy bỏ tại ATM/POS. Bên chấp nhận thẻ không nhận được phản hồi cho một yêu cầu tài chính. Bên chấp nhận thẻ không thể gửi một phản hồi chấp thuận đến cho ATM/POS. Bên chấp nhận thẻ không nhận được một thông điệp báo cáo hoàn thành từ ATM/POS.  Lớp thông điệp đòi bồi hoàn (chargeback message) – 04xx Thông điệp đòi bồi hoàn được sử dụng để hủy bỏ một phần hay toàn bộ một giao dịch tài chính (02xx) trước đó và lớp thông điệp này được khởi tạo từ bên phát hành thẻ. o 0422 Chargeback advice. o 0423 Chargeback advice repeat. o 0432 Chargeback advice response.  Lớp thông điệp đối chiếu (reconciliation message) – 05xx Thông điệp đối chiếu cung cấp toàn bộ giao dịch tài chính giữa bên chấp nhận thẻ và bên phát hành thẻ. Có hai hình thức đối chiếu: đối chiếu tự động và đối chiếu theo yêu cầu.  Lớp thông điệp thủ tục (administrative message) – 06xx Thông điệp thủ tục được sử dụng khi hai thực thể có nhu cầu trao đổi thông tin với nhau. (Ví dụ như yêu cầu tra soát và khiếu nại - retrieval request). 21  Lớp thông điệp thu phí (fee collection message) – 07xx Thông điệp thu phí được sử dụng để thu hay chi trả phí cho các loại dịch vụ khác nhau. Thông điệp này có thể được gửi từ bên chấp nhận thẻ sang bên phát hành thẻ hoặc ngược lại.  Lớp thông điệp mạng (network management message) – 08xx Thông điệp quản trị mạng được sử dụng để kiểm soát độ bảo mật của hệ thống và điều kiện hoạt động của mạng trao đổi (mạng thanh toán điện tử). Thông điệp quản trị mạng sẽ được khởi tạo khi môi trường mạng có sự thay đổi. Lớp thông điệp quản trị mạng cũng được dùng với các chức năng bảo mật. Các thông điệp kiểm tra kết nối truyền thông hoặc trao đổi khoá gồm: o 0800 Network request. o 0810 Network request response. 2.2.3. Loại message thực hiện với ngân hàng Giao dịch trên ATM: Loại giao dịch Loại message Processing code Rút tiền (Cash Withdrawal) 200/210,420/430 01xx00 Rút tiền nhanh (Fast Cash) 200/210,420/430 010000 Vấn tin số dư (Balance Inquiry) 200/210,420/430 30xx00 In Sao kê (Mini Statement) 200/210,420/430 35xx00 Chuyển khoản (Funds tranfer) 200/210, 420/430 40xxyy Bảng 2.1 Các loại giao dịch trên ATM Trong các bảng trên, các giá trị hợp lệ của xx là:  00 – Tài khoản ngầm định (Default account).  10 – Tài khoản tiết kiệm (Savings account).  20 – Tài khoản vãng lai (Current account). Các thông điệp mạng (network messages) cần được hỗ trợ bao gồm: Mô tả Loại Message Network Code Sign-on (đăng nhập) 800/810 001 Sign-off (đăng xuất) 800/810 002 Key Exchange (trao đổi khoá) 800/810 161 Echo test (kiểm tra kết nối) 800/810 301 Bảng 2.2 Các thông điệp mạng hỗ trợ 22 2.2.4. Bitmaps Thành phần thứ hai của thông điệp là Bitmaps. Bitmaps là một chuỗi dài 64 ký tự gồm các số [0,1] . Theo thứ tự của chuỗi, số 1 thể hiện sự tồn tại của trường dữ liệu tương ứng và số 0 thể hiện không tồn tại trường dữ liệu (thành phần dữ liệu) tương ứng ở vị trí đó. Một thông điệp luôn tồn tại Bitmaps thứ nhất (có thể mở rộng thêm các Bitmaps thứ 2 hoặc thứ 3). Để giảm bớt kích cỡ message khi truyền, người ta thường đổi chuỗi 64 ký tự [0,1] (số nhị phân) đó sang dạng số Hexa thành một chuỗi gồm 16 ký tự số và chữ. Tại điểm xử lý các message sẽ chuyển đổi dãy 16 ký tự đó thành dãy 64 ký tự [0,1] để đọc các thành phần dữ liệu tiếp theo của message. Sau khi chuyển đổi dãy số Hexa sang dãy số nhị phân thì số nhị phân đầu tiên là số 0 thì có nghĩa không có Bitmaps thứ 2, nếu là số 1 có nghĩa là có Bitmaps thứ 2. Hình 2.7 Mô tả Bitmaps trong thông điệp VD Bitmap thứ 1: Hình 2.8 Mô tả Bitmap thứ 1 trong thông điệp 2.2.5. Thông điệp giao dịch 0200/0210 Thông điệp 0200/0210 là thông điệp tài chính để gửi và nhận thông tin với các ngân hàng [13]. 23 Các ký tự viết tắt: 200: Thông điệp giao dịch yêu cầu. 210: Thông điệp giao dịch trả lời. Các giá trị trong cột 200 và 210: M: Mandatory (bắt buộc). O: Optional (không bắt buộc). -: Not Avaiable (không hiển thị). Bit map # Độ dài Kiểu dữ liệu 200 210 Tên trường Mô tả trường Giá trị là 210 4 Số M M Kiểu thông điệp (Message Type Identifier) Là trường đầu tiên của thông điệp và xác định kiểu của thông điệp đang gửi 210 16 Số Hexa M M BIT MAP chính (Primary Bitmap) BIT MAP chính hiển thị dưới dạng 16 chữ số Hexa. Với mỗi chữ số hiển thị thông tin của 4 bit. Do đó 16 chữ số hiển thị thông tin có mặt/vắng mặt của 64 bit là các Bitmap từ 1 đến 64 Phụ thuộc vào thông tin của trường trả về 2 2 M M Độ dài trường (Field Length) Độ dài của số thẻ ghi nợ (PAN Length) Giống 200 nn Số M M Số thẻ (Primary Account Number) Chứa số thẻ của khách hàng Giống 200 3 6 Số M M Mã giao dịch (Processing Code) Mã số xác định loại giao dịch giữa ngân hàng và đối tác kết nối Giống 200 4 12 Số M M Số tiền giao dịch 2 chữ số ngoài cùng bên phải là 2 chữ số Giống 200 24 (Transaction Amount) thập phân Giá trị của giao dịch là 10 chữ số từ trái sang Đơn vị tính là VNĐ 7 10 Số M M Thời gian thông điệp gửi sang ngân hàng (Transaction DateTime) Trường này hiển thị ngày và giờ thông điệp gửi từ đối tác sang ngân hàng hoặc từ ngân hàng sang đối tác. Định dạng của trường này là: Mmddhhmiss theo thứ tự: tháng-ngày- giờ-phút-giây Giờ sẽ tuân theo định dạng 24h Giống 200 11 6 Số M M Số theo dõi của hệ thống khởi tạo giao dịch (System Trace) Là một trường tham chiếu về thứ tự giao dịch đi qua hệ thống trong một khoảng thời gian Giá trị này sẽ do hệ thống của bên khởi tạo giao dịch 200 sinh ra Giống 200 12 6 Số M M Giờ khởi tạo giao dịch (Local Time) Định dạng của trường: hhmmss. Theo định dạng 24 giờ Giống 200 13 4 Số M M Ngày khởi tạo giao dịch (Local Date) Định dạng của trường: mmdd Giống 200 15 4 Số M M Ngày thanh toán (Settlement Date) Ngày giao dịch được thanh toán sau khi đối chiếu thành công giữa ngân hàng và đối tác Định dạng của Giống 200 25 trường: Mmdd 18 4 Số M M Hình thức phát sinh giao dịch (Merchant Type) Trường này hiện thị thông tin về hình thức phát sinh giao dịch ATM: 6011 POS: 6012 SMS: 6013 WEB: 6014 Giống 200 38 6 Số - 0 Số cấp phép của ngân hàng cho giao dịch (Authorization Number) Mã số để xác định giao dịch được ngân hàng cấp phép trong các giao dịch nạp tiền. Con số này do hệ thống ngân hàng điền. Khi giao dịch lỗi thì trường này không bắt buộc. Khi giao dịch thành công thì ngân hàng phải điền số cấp phép. Đặt bởi hệ thống của ngân hàng 39 2 Ký tự - M Mã số trả lời (Response Code) Trường này bắt buộc cho tất cả các thông điệp trả lời và để xác định giao dịch đó thành công hoặc gặp lỗi. Đặt bởi bên khởi tạo 210 41 8 Ký tự M M Mã số thiết bị phát sinh giao dịch Trường này bắt buộc cho tất cả các thông điệp. Đối tác điền thông tin định danh không quá 8 ký tự. Nếu giá trị ngắn hơn 8 ký tự thì điền thêm dấu cách phía trước Giống 200 26 cho đủ 8 ký tự 48 3 O O Độ dài trường (Field Length) nnn Ký tự O O Thông tin bổ sung (Additional Data) Trường này được dùng để cung cấp thông tin từ ngân hàng cho đối tác: đăng ký sử dụng dịch vụ, tài khoản của khách hàng 49 3 Số M M Mã tiền tệ giao dịch Biểu thị mã tiền tệ sử dụng trong giao dịch Giá trị mặc định là 704 ( Việt nam Đồng) Giống 200 54 3 O Độ dài trường (Field Length) nnn Số - O Thông tin số dư (Banlace Information) Chứa số dư tại tài khoản của chủ thẻ Độ dài trường luôn cố định là 20 ký tự Bảng 2.3 Thông điệp tài chính 0200/0210 2.3. Các vấn đề bảo mật trong thương mại điện tử TMĐT chủ yếu qua các Website bán hàng qua mạng. Vậy vấn đề bảo mật trong TMĐT liên quan đến sự an toàn của các Website:  Các trang Web rất dễ bị tấn công hai chiều.  Tấn công Web server sẽ gây tổn hại đến danh tiếng và tiền bạc của công ty.  Web server có thể bị khai thác làm căn cứ để tấn công vào hệ thống máy tính của một tổ chức.  Người dùng thiếu công cụ và kiến thức để đối phó vói các hiểm họa an toàn. Vậy một Web site thương mại điện tử muốn an toàn phải đáp ứng một số tiêu chí sau: tính toàn vẹn, tính bảo mật, từ chối dịch vụ, xác thực. 27 2.3.1. Giao thức bảo mật SSL SSL [5, 10] là giao thức đa mục đích được thiết kế để tạo ra các giao tiếp giữa hai chương trình ứng dụng trên một cổng định trước (Socket 443) nhằm mã hóa toàn bộ thông tin đến đi được sử dụng rộng rãi trong giao dịch điện tử như truyền số liệu thẻ tín dụng, số bí mật cá nhân(PIN) trên mạng Internet. Giao thức SSL được hình thành và phát triển đầu năm 1994 bởi nhóm nghiên cứu Netscape và ngày nay trở thành chuẩn mực bảo mật trên mạng Internet. Phiên bản SSL hiện nay là 3.0 vẫn đang được bổ xung và hoàn thiện. Cách hoạt động của SSL: Điểm cơ bản của SSL được thiết kế độc lập với tầng ứng dụng để đảm bảo tính bí mật, an toàn và chống giả mạo luồng thông tin qua Internet giữa hai ứng dụng bất kỳ, ví dụ như Web server và các trình duyệt khách (browsers), do đó được sử dụng trong nhiều ứng dụng khác nhau trên môi trường Internet. Toàn bộ cơ chế hoạt động và hệ thống thuật toán mã hóa sử dụng trong SSL được phổ biến công khai, trừ khóa chia sẻ tạm thời (session key) được sinh ra tại thời điểm trao đổi giữa hai ứng dụng là tạo ngẫu nhiên và bí mật đối với người quan sát trên mạng máy tính. Giao thức SSL còn yêu cầu Web server phải được chứng thực điện tử (digital certificate) dựa trên mật mã công khai (RSA). Giao thức SSL dựa trên hai nhóm con giao thức là giao thức “bắt tay” (handshake protocol) và giao thức “bản ghi” (record protocol). Giao thức bắt tay xác định các tham số giao dịch giữa hai đối tượng có nhu cầu trao đổi thông tin hoặc dữ liệu, còn giao thức bản ghi xác định khuôn dạng cho tiến hành mã hóa và truyền tin hai chiều giữa hai đối tượng đó. Khi trình duyệt web và máy chủ web, làm việc với nhau, máy chủ và máy khách sẽ trao đổi “lời chào” dưới dạng các thông điệp cho nhau với xuất phát đầu tiên chủ động từ máy chủ, đồng thời xác định các chuẩn thuật toán mã hóa và nén số liệu có thể trao đổi giữa hai ứng dụng. Ngoài ra các ứng ụng còn trao đổi “số nhận dạng, khóa theo phiên” (session ID, session key) duy nhất cho lần làm việc đó. Sau đó ứng dụng khách (trình duyệt) yêu cầu có chứng thực điện tử (digital certificate) xác thực của ứng dụng chủ (web server). Chứng thực điện tử thường được xác nhận rỗng rãi bởi một cơ quan trung gian là CA (Certificate Authority) như RSA Sercurity hay VeriSign Inc, … một dạng tổ chức độc lập, trung lập và có uy tín. Các tổ chức này cung cấp dịch vụ “xác nhận” số nhận dạng của một công ty và phát hành chứng chỉ duy nhất cho công ty đó như là bằng chứng nhận dạng (identity) cho các giao dịch trên mạng, ở đây là các máy chủ Web server. Sau khi kiểm chứng chứng chỉ điện tử của máy chủ (sử dụng thuật toán mật mã công khai, như RSA tại trình máy trạm), ứng dụng máy trạm sử dụng các thông tin 28 trong chứng chỉ điện tử để giải mã hóa thông điệp gửi lại máy chủ mà chỉ có máy chủ đó có thể giải mã. Trên cơ sở đó, hai ứng dụng trao đổi khóa chính (master key) - khóa bí mật hay khóa đối xứng - làm cơ sở mã hóa luồng thông tin dữ liệu qua lại giữa hai ứng dụng khách chủ. Các thuật toán mã hóa và xác thực của SSL được sử dụng bao gồm:  DES: chuẩn mã hóa dữ liệu ra đời năm 1997.  DSA: thuật toán chữ ký điện tử.  KEA: thuật toán trao đổi khóa.  MD5: Thuật toán tạo giá trị băm, phát minh bởi Rivest.  RC2,RC4: mã hóa Rivest, phát triển bởi công ty RSA Data Security.  RSA key exchange: thuật toán trao đổi khóa cho SSL dựa trên thuật toán RSA.  SHA-1: thuật toán hàm băm an toàn.  SKIPJACK: thuật toán khóa đối xứng phân loại.  Triple DES: mã hóa DES ba lần. 2.3.2. Mật khẩu OTP OTP (one time password) [10] là một loại mật khẩu chỉ hợp lệ cho một phiên làm việc hoặc một giao dịch. Vấn đề quan trọng nhất khi sử dụng mật khẩu OTP là nó tránh được tấn công lập lại trong trường hợp sử dụng mật khẩu thông thường. Tạo mật khẩu OTP dựa trên thuật toán sinh ngẫu nhiên. Thuật toán này thực sự cần thiết vì nếu không sẽ dễ dàng đoán được mật khẩu OTP ở các phiên trước. Một số cách sinh mật khẩu OTP:  Lấy từ thời gian đồng bộ hóa giữa xác thực server và client để phân phối mật khẩu (OTP chỉ hợp lệ trong khoảng thời gian ngắn).  Sử dụng thuật toán sinh ngẫu nhiên hoặc một theo một biến đếm để sinh mật khẩu OTP. 29 CHƯƠNG 3: THƯƠNG MẠI ĐIỆN TỬ CHO THUÊ BAO DI ĐỘNG 3.1. Bài toán Hiện nay có rất nhiều hình thức thanh toán thương mại điển tử: khách hàng có thể chuyển khoản qua ATM, gửi mã thẻ cào điện thoại của công ty viễn thông, sử dụng dịch vụ TMĐT của ngân hàng tự cung cấp, sử dụng ví điện tử của các công ty cung cấp giải pháp TMĐT. Một số giải pháp thương mại điện tử đang triển khai tại Việt Nam: A. Chuyển khoản qua ATM:  Doanh nghiệp bán hàng qua mạng mở tài khoản tại nhiều ngân hàng khác nhau.  Khách hàng mua hàng tại Website của doanh nghiệp sẽ thanh toán bằng hình thức chuyển tiền cho doanh nghiệp qua thẻ ATM.  Ví dụ: khách hàng mua tivi tại một Website bán hàng qua mạng: chọn tivi vào giỏ mua hàng, Website sẽ yêu cầu khách hàng nhập các thông tin liên quan đến đơn hàng như số điện thoại, email, địa chỉ giao hàng, … và yêu cầu khách hàng chuyển tiền vào tài khoản tại ngân hàng. Khách hàng ra ATM chuyển tiền vào tài khoản của Website bán hàng. Website bán hàng thấy tài khoản ngân hàng tăng sẽ xác nhận đơn hàng đã được thanh toán. B. Ngân hàng cung cấp dịch vụ TMĐT:  Khách hàng còn có tài khoản tại ngân hàng cung cấp dịch vụ TMĐT.  Khách hàng mua hàng tại Website của doanh nghiệp có chấp nhận thẻ của ngân hàng cung cấp dịch vụ TMĐT sẽ thanh toán bằng cách trừ trực tiếp trong tài khoản ngân hàng.  Ví dụ: khách hàng mua tivi tại một Website bán hàng qua mạng: chọn tivi vào giỏ mua hàng và chọn thanh toán sẽ yêu cầu khách hàng xác thực qua Website của ngân hàng sẽ trừ tiền tài khoản khách hàng và tăng tài khoản của Website bán hàng, Website bán hàng xác nhận giao dịch của khách hàng đã được thanh toán. C. Ví điện tử:  Khách hàng có tài khoản ảo tại công ty cung cấp giải pháp TMĐT.  Khách hàng có tài khoản tại các ngân hàng mà công ty cung cấp giải pháp TMĐT kết nối trực tiếp tới. 30  Qua Website của công ty cung cấp giải pháp TMĐT sẽ chuyển tiền từ tài khoản ngân hàng sang tài khoản ảo.  Khách hàng mua hàng tại Website của doanh nghiệp có chấp nhận tài khoản ảo của công ty cung cấp giải pháp TMĐT sẽ thanh toán bằng cách trừ tiền tài khoản ảo.  Ví dụ: khách hàng mua tivi tại một Website bán hàng qua mạng: chọn tivi vào giỏ mua hàng và chọn thanh toán sẽ yêu cầu khách hàng xác thực qua Website của của công ty cung cấp giải pháp TMĐT sẽ trừ tiền tài khoản ảo khách hàng và tăng tài khoản ảo của Website bán hàng, Website bán hàng xác nhận giao dịch của khách hàng đã được thanh toán. Qua các phân tích các đặc điểm và ví dụ về các mô hình TMĐT đã triển khai ở trên chúng tôi thấy có một số nhược điểm như sau: Chuyển khoản qua ATM:  Doanh nghiệp phải đăng ký tài khoản tại nhiều ngân hàng khác nhau.  Khách hàng phải ra ATM chuyển khoản cho doanh nghiệp.  Thời gian thanh toán giao dịch lâu. Ngân hàng cung cấp dịch vụ TMĐT:  Khách hàng phải có tài khoản tại ngân hàng cung cấp dịch vụ TMĐT.  Không thể mua hàng mọi lúc mọi nơi do phải vào Website bán hàng qua Internet.  Thanh toán qua Website không an toàn do có thể bị lộ mật khẩu. Ví điện tử:  Nạp tiền, chuyển khoản cho tài khoản ảo phải qua Website của công ty cung cấp giải pháp TMĐT.  Không thể mua hàng mọi lúc mọi nơi do phải vào Website bán hàng qua Internet.  Thanh toán qua Website không an toàn do có thể bị lộ mật khẩu. Mục tiêu của luận văn là đưa ra một giải pháp thanh toán thương mại điện tử an toàn, tiện lợi và khắc phục được nhược điểm của các mô hình TMĐT nêu trên. Với mục tiêu như vậy luận văn đề xuất giải pháp sử dụng điện thoại di động để thanh toán TMĐT:  Khách hàng có thuê bao điện thoại di động của các công ty viễn thông. 31  Có tài khoản tại các ngân hàng: Agribank, Vietinbank, Bidv, DongaBank, Techcombank, … hoặc không cần tài khoản ở ngân hàng.  Đăng ký tài khoản ảo tại công ty cung cấp giải pháp TMĐT.  Nạp tiền trực tiếp từ tài khoản ngân hàng sang tài khoản ảo thông qua tin nhắn SMS hoặc qua Website.  Thanh toán thương mại điện tử qua SMS hoặc Website và được xác thực bởi tin nhắn SMS. Với giải pháp nêu trên dẫn đến việc xây dựng mô hình TMĐT cho thuê bao di động: Hình 3.1 Hệ thống thương mại điện tử cho thuê bao di động 32 SMS GATEWAY 8xxx: thuê đầu số giá trị gia tăng của các công ty viễn thông giúp khách hàng có thể gửi tin nhắn SMS tới công ty cung cấp giải pháp TMĐT và nhận tin nhắn phản hồi. BANK GATEWAY: kết nối với các ngân hàng để thực hiện yêu cầu trừ tiền trong tài khoản của khách hàng. Hệ thống thẻ trả trước Prepaidcard: quản lý đại lý phát hành thẻ, quản lý thẻ cho khách hàng. Hệ thống tài khoản ảo Airtime: quản lý tài khoản ảo của khách hàng, doanh nghiệp kết nối, có thể nạp tiền trực tiếp từ tài khoản ngân hàng vào tài khoản ảo. Doanh nghiệp kết nối như đại lý vé máy bay, siêu thị trực tuyến, dạy học trực tuyến,… kết nối vào hệ thống thanh toán qua Internet. Khách hàng mua hàng bằng cách gửi tin nhắn SMS hoặc qua các Website bán hàng. 3.2. Mô hình thẻ trả trước PrepaidCard Thẻ trả trước Prepaid Card là thẻ có một giá trị tiền được ghi sẵn trong thẻ đó và có thể sử dụng để mua hàng hóa và dịch vụ tại các cửa hàng hoặc đại lý của doanh nghiệp. Thẻ có thể được phát hành với một số dư đã đặt sẵn (pre-paid) hoặc sẽ được nạp tiền khi khách hàng mua thẻ (store-value). Đối với thẻ trả trước store-value thì sau khi phát hành, chủ thẻ có thể được nạp tiền vào thẻ trong các lần tiếp theo. Trong mô hình dự kiến thẻ sẽ được áp dụng theo mô hình store-value và có thể nạp tiếp bằng chính tài khoản của khách hàng tại ngân hàng. Thẻ trả trước được thanh toán qua kênh Internet hoặc SMS. 3.2.1. Phát hành thẻ Để đáp ứng nhu cầu thanh toán không dùng tiền mặt cũng như gia tăng tiện ích thanh toán trên các kênh bán hàng mới (Internet, Mobile), các doanh nghiệp bán lẻ thực hiện phát hành thẻ trả trước cho khách hàng. Thông qua ký kết các thỏa thuận hợp tác với nhà cung cấp, nhà cung cấp và doanh nghiệp thực hiện việc hợp tác phát hành thẻ trả trước cho khách hàng thông qua các bước sau:  Doanh nghiệp đăng ký một số mã số phát hành trên hệ thống của nhà cung cấp. Mã số phát hành sẽ là duy nhất và được dùng để phân biệt thẻ trả trước phát hành thuộc doanh nghiệp nào. 33  Xác định số lượng thẻ sẽ phát hành: thông qua nhu cầu thực tế và từng thời điểm thì doanh nghiệp sẽ xác định thông số để phát hành thẻ cho khách hàng của mình: số lượng, ngày phát hành, ngày kích hoạt.  Nhà cung cấp sẽ tạo ra trong hệ thống các số thẻ tương ứng theo yêu cầu của doanh nghiệp. Khái niệm thẻ trong hệ thống của nhà cung cấp sẽ được phân loại theo: o Loại thẻ: áp dụng cho từng doanh nghiệp phát hành. o Sản phẩm thẻ: hỗ trợ Store – Value. o Tính năng sản phẩm: Cài đặt các tính năng có sẵn cho từng loại thẻ (có giới hạn trong tài khoản). o Loại hình thẻ: Thẻ in và phân phối qua doanh nghiệp hoặc thẻ điện tử phân phối qua Internet.  Tùy theo điều kiện thỏa thuận giữa các doanh nghiệp và nhà cung cấp thì thẻ sẽ do nhà cung cấp in hoặc doanh nghiệp tự in thẻ cho khách hàng của mình thông qua file do nhà cung cấp gửi.  Doanh nghiệp nhận file dữ liệu thẻ và phân phối cho khách hàng thông qua hệ thống đại lý của mình. 3.2.2. Kích hoạt thẻ Các thẻ do doanh nghiệp và nhà cung cấp phát hành cho khách hàng trước khi sử dụng phải qua bước kích hoạt. Mục đích của việc kích hoạt là khách hàng đăng ký thẻ đang có với số điện thoại và cung cấp thông tin các nhân cho nhà cung cấp và doanh nghiệp (Tên, Địa chỉ, Số chứng minh nhân dân) để thuận tiện trong việc gửi hàng và xác thực tính hợp lệ giao dịch. Các hình thức kích hoạt thẻ khách hàng:  Kích hoạt qua Internet: o Khách hàng truy cập vào Website của nhà cung cấp. o Khách hàng chọn mục kích hoạt thẻ. Trên màn hình kích hoạt khách hàng nhập thông tin cá nhân, số thẻ và số series để kích hoạt thẻ. o Hệ thống của nhà cung cấp sẽ tạo thông tin khách hàng trên cơ sở dữ liệu, tạo thông tin về tài khoản của khách hàng. Sau khi khởi tạo thành công hệ thống gửi mật khẩu về điện thoại khách hàng 34 (Trong lần sau khách hàng có thể truy cập vào trang web để kiểm tra thông tin tài khoản thẻ trả trước của mình).  Kích hoạt qua tin nhắn SMS: o Khách hàng gửi tin nhắn tới đầu số để kích hoạt. o Hệ thống của nhà cung cấp tạo thông tin khách hàng trong hệ thống tài khoản ảo (Airtime) và gửi mật khẩu thanh toán về cho khách hàng. o Khách hàng có thể truy cập vào Website nhà cung cấp để cập nhật thông tin và kiểm tra tài khoản bằng số điện thoại và mật khẩu do nhà cung cấp gửi.  Kích hoạt qua hệ thống Call Center: o Khách hàng gọi điện đến tổng đài để nhờ tổng đài hỗ trợ kích hoạt từ xa. o Khách hàng đọc thông tin cá nhân cho nhân viên chăm sóc khách hàng nhập thông tin. o Hệ thống của nhà cung cấp tạo thông tin khách hàng và gửi mật khẩu thanh toán về điện thoại cho khách hàng. o Khách hàng có thể đang nhập vào Web site để cập nhật các thông tin khác và kiểm tra tài khoản của mình bằng số điện thoại và mật khẩu thanh toán do nhà cung cấp gửi. 3.2.3. Chấp nhận thẻ Thẻ trả trước do các doanh nghiệp phát hành được chấp nhận thanh toán tại chính các Website hoặc các cửa hàng của doanh nghiệp phát hành tại Website hoặc cửa hàng trong cùng dịch vụ do nhà cung cấp khởi tạo. Trong hệ thống doanh nghiệp kết nối vào nhà cung cấp, thẻ trả trước được thanh toán qua nhà cung cấp hoặc qua kênh thanh toán SMS. Để tham gia vào hệ thống chấp nhận thẻ, doanh nghiệp phải ký hợp đồng chấp nhận thẻ, các doanh nghiệp gọi tắt là đại lý chấp nhận thẻ. Đại lý có thể cài đặt các kênh chấp nhận thanh toán do đại lý lựa chọn(SMS hoặc Internet).  Thiết lập đại lý chấp nhận thẻ: 35 o Bộ phận quản lý của nhà cung cấp sẽ quản lý tất cả các đại lý chấp nhận thẻ trả trước do nhà cung cấp và doanh nghiệp phát hành. o Khi một doanh nghiệp hoặc một Website muốn đăng ký làm đại lý chấp nhận thẻ trả trước thì bộ phận quản lý sẽ soạn hợp đồng đại lý, phí gia nhập, phí trên giao dịch, v.v … o Đại lý phân loại theo ngành nghề và lĩnh vực kinh doanh. o Sau khi ký hợp đồng nhà cung cấp và bộ phận kỹ thuật của đại lý sẽ khảo sát hạ tầng thanh toán và tư vấn mô hình kết nối chấp nhận thanh toán qua SMS và được nhà cung cấp gửi một mã số địa điểm chấp nhận duy nhất trên toàn hệ thống. Mỗi địa điểm chấp nhận nhà cung cấp sẽ cho phép thực hiện các giao dịch với hệ thống trả trước.  Cấp phép thanh toán từ đại lý: o Thanh toán với đại lý xuất phát từ hai kênh chính: Internet và SMS. o Đối với các hình thức từ Internet:  Đại lý kết nối trực tiếp vào hệ thống nhà cung cấp bằng đường lease-line hoặc Internet vpn để gửi nhận các thông điệp thanh toán theo chuẩn do hai bên định nghĩa SOAP hoặc ISO8583.  Doanh nghiệp chỉ dẫn khách hàng đến trang thanh toán của nhà cung cấp. o Đối với hình thức thanh toán từ SMS:  Đại lý thanh toán hóa đơn của khách hàng qua Website của nhà cung cấp và khách hàng nhận tin nhắn xác nhận bằng SMS.  Khách hàng gửi tin nhắn thanh toán cho hóa đơn bằng tin nhắn SMS. 36  Khi giao dịch xẩy ra thì tiền sẽ chuyển trực tiếp từ tài khoản khách hàng sang tài khoản đại lý. Đồng thời hệ thống sẽ khởi tạo phí giao dịch của đại lý chuyển sang nhà cung cấp. o Quản trị hệ thống theo dõi được các giao dịch tức thời đi qua hệ thống.  Đối chiếu và thanh toán cho đại lý: o Đại lý đăng nhập vào Website dành cho đại lý xem chi tiết các giao dịch. Nếu có sai lệch đại lý đánh dấu các giao dịch nghi vấn. o Thực hiện thanh toán với các giao dịch thành công. o Trong trường hợp đối chiếu số tổng không thành công, số liệu sẽ được chấp nhận theo số nhỏ nhất. Các giao dịch nghi vấn sẽ được xủ lý bên ngoài. o Quá trình thanh toán sẽ tính tổng các giao dịch thành công xẩy ra và hạnh toán phí giữa nhà cung cấp và đại lý theo từng giao dịch. o Kết quả thanh toán ngày hôm trước sẽ là cơ sở để chuyển tiền tại tài khoản ngân hàng giữa nhà cung cấp và đại lý. o Cho phép thanh toán thủ công khi quá trình tự động không hoạt động. o Cho phép in sao kê đại lý. o Cho phép hiển thị nhiều tài khoản trong một bảng sao kê.  Xử lý giao dịch và hỗ trợ đại lý: o Đại lý có thể đăng nhập trực tiếp và tra cứu thông tin tài khoản đại lý. o Tra cứu giao dịch của khách hàng đi qua đại lý. o Cho phép đại lý thực hiện hủy giao dịch thanh toán đã xẩy ra trước đấy khi giao dịch chưa được thanh toán. Không thu phí khách hàng. 37 o Cho phép đại lý thực hiện giao dịch mua lại hàng (Refund) đối với khách hàng trả lại hàng sau khi thanh toán. o Khi có khách hàng khiếu kiên và giao dịch không được thực hiện ở đại lý thì nhà cung cấp sẽ gửi yêu cầu sang đại lý để xác minh giao dịch có xẩy ra ở đại lý hay không. o Trong trường hợp giao dịch không xẩy ra thì kiểm tra và bồi hoàn lại tài khoản khách hàng. o Trong trường hợp giao dịch có xẩy ra thì phối hợp cùng đại lý xử lý giao dịch cho khách hàng khiếu kiện. 38 3.2.4. Mô hình cơ sở dữ liệu PrepaidCard Hình 3.2 Mô hình cơ sở dữ liệu PrepaidCard 39 3.3. Hệ thống tài khoản Airtime Khách hàng có nhiều tài khoản tại các ngân hàng khác nhau và nhiều khách hàng không có tài khoản trong ngân hàng. Vậy phải thiết lập một hệ thống tài khoản ảo dùng chung: có thể chuyển tiền từ tài khoản ngân hàng khác nhau vào tài khoản ảo vào hoặc chuyển tiền từ tài khoản ảo này sang tài khoản ảo khác. Các chức năng chính của hệ thống tài khoản ảo (Airtime): 3.3.1. Quản lý thông tin khách hàng  Xem danh sách khách hàng.  Đăng ký một khách hàng mới.  Thông tin khách hàng được quản lý theo từng chi nhánh của nhà cung cấp bao gồm: Mã chi nhánh đăng ký, mã khách hàng, loại khách hàng (theo cá nhân hoặc theo tổ chức), loại định danh của khách hàng (theo số điện thoại, theo chứng minh nhân dân, số hộ chiếu, giấy phép đăng ký kinh doanh).  Tìm kiếm thông tin đến khách hàng theo tiêu chí: họ tên, chi nhánh đăng ký, ngày đăng ký, loại khách hàng, tình trạng.  Cập nhật các thông tin về khách hàng. 3.3.2. Quản lý tài khoản  Đăng ký tài khoản cho một khách hàng sau khi đã đăng ký thông tin của khách hàng.  Thông tin của tài khoản gồm có: mã chi nhánh tạo tài khoản, mã số khách hàng, số tài khoản, loại tài khoản, mã tiền tệ, trạng thái tài khoản. Các thông tin hạnh toán: tổng phát sinh năm, tổng phát sinh tăng trong năm, tổng phát sinh giảm trong tháng, tổng phát sinh nợ trong tháng, tổng phát sinh giảm trong ngày, số dư, …  Một tài khoản có thể được gắn nhiều hạn mức khác nhau.  Đăng ký tài khoản qua hai mức: đăng ký thông tin và duyệt.  Cho phép vấn tin tài khoản theo mã tài khoản, mã khách hàng.  Khóa mở tài khoản.  Đóng tài khoản. 3.3.3. Quản lý hạn mức  Xem danh sách hạn mức. 40  Thêm hạn mức mới.  Cập nhật thông tin hạn mức.  Thông tin về hạn mức bao gồm: Mã hạn mức, Mô tả thông tin cấp phép.  Các thông tin cấp phép trên hạn mức: loại cấp phép theo ngày, tháng hoặc khác; Số lượng giao dịch tối đa trong ngày/tháng; Số phát sinh giảm/tăng tối đang trong ngày/tháng; Số dư tối thiểu, mức độ ưu tiên của hạn mức, ngày bắt đầu hiệu lực, ngày kết thúc hiệu lực.  Với mỗi tài khoản có thể gắn nhiều hạn mức. Hạn mức có mức độ ưu tiên cao sẽ được xem xét trước, nếu hai hạn mức cùng độ ưu tiên thì hạn mức nào có ngày cập nhật gần nhất sẽ được xét. 3.3.4. Dịch vụ khách hàng  Tra cứu thông tin giao dịch.  Tra cứu thông tin của các giao dịch qua hệ thống: Mã giao dịch, loại giao dịch, ngày chờ giao dịch, số tài khoản nguồn, số tài khoản đích, mã đại lý chấp nhận.  Các thông tin giao dịch bao gồm: o Mã giao dịch. o Loại giao dịch. o Số tài khoản ghi giảm. o Số tài khoản ghi tăng. o Số tiền. o Ngày giao dịch. o Giờ giao dịch. o Ngày xuất phát giao dịch. o Giờ xuất phát giao dịch. o Ngày thanh toán. o Kênh chấp nhận: SMS, Internet o Mã đại lý chấp nhận giao dịch. o Thông tin bổ xung. o Mã số cấp phép giao dịch. o Mã trả lời giao dịch. 41 o Tình trạng giao dịch. o Giờ đảo giao dịch. o Ngày đảo giao dịch. o Tình trạng đối chiếu: đã đối chiếu, chưa đối chiếu.  Thực hiện giao dịch gửi tiền vào tài khoản: o Nhận giấy gửi tiền tài khoản của khách hàng. o Chỉnh sửa thông trên giấy gửi tiền khi chưa gửi duyệt. o Gửi duyệt giấy gửi tiền. o Tra cứu và xem thông tin các giấy gửi tiền đã lập trước đó.  Thực hiện giao dịch rút tiền từ tài khoản: o Nhận giấy rút tiền từ tài khoản của khách hàng. o Chỉnh sửa thông tin trên giấy rút tiền khi chưa gửi duyệt. o Gửi duyệt giấy rút tiền. o Tra cứu và xem thông tin các giấy rút tiền đã lập trước đó.  Duyệt giao dịch từ dịch vụ khách hàng: o Xem các giấy giao dịch đang chờ duyệt. o Duyệt giấy điều chỉnh và gửi thông tin giao dịch và hệ thống cấp phép. o Tra cứu và xem thông tin các giấy đã duyệt trước đó. 42 3.3.5. Luồng nạp tiền tài khoản Airtime Hình 3.3 Luồng nạp tiền tài khoản Airtime Khách hàng Nhà cung cấp Airtime Ngân hàng Gửi sms nạp tiền tới nhà cung cấp Kiểm tra số giao dịch và số tiền được nạp tiền tối đa Chấp nhận SMS nạp tiền Kiểm tra khách hàng có hợp lệ Khách hàng hợp lệ Ghi nợ thành công Ghi nợ tài khoản khách hàng Nạp tiền thành công Nạp tiền tài khoản khách hàng Nạp tiền thành công, thông tin tài khoản khách hàng 43 3.3.6. Mô hình cơ sở dữ liệu Airtime Hình 3.4 Mô hình cơ sở dữ liệu Airtime 44 3.4. Kết nối doanh nghiệp bán hàng Khi có một doanh nghiệp mới muốn tham gia cộng đồng thương mại điện tử thì họ phải đăng ký với nhà cung cấp để công nhận là doanh nghiệp kết nối tới cộng đồng thương mại điện tử. Doanh nghiệp sẽ nhận được khóa và tài khoản ảo từ nhà cung cấp. Khi có yêu cầu thanh toán từ Website của doanh nghiệp: doanh nghiệp sẽ ký trên một số trường thông tin và gửi sang Website của nhà cung cấp được xác thực bởi VeriSign, đảm bảo thông tin không bị thay đổi trên đường truyền. các thông tin được gửi tới Website của nhà cung cấp để thanh toán, nhà cung cấp sẽ gửi SMS chứa mật khẩu OTP tới khách hàng, khác hàng nhập mật khẩu xác thực thanh toán giao dịch. Khi thanh toán xong nhà cung cấp sẽ gửi thông báo thành công về cho khách hàng và doanh nghiệp. 3.4.1. URL của nhà cung cấp Nhà cung cấp đưa ra địa chỉ URL để doanh nghiệp có thể thanh toán giao dịch: https://www.nhacungcap.vn/xxxxx/?page=pay&vnmtc=Parameter1&vnmpid=Par ameter2&vnmam=Parameter3& vnmdt=Parameter4&vnmsig=Parameter5 Trong đó:  xxxxx: sẽ được thông báo trực tiếp cho doanh nghiệp.  vnmtc: mã điểm chấp nhận thanh toán (Terminal Code). Trước khi gửi phải sử dụng hàm UrlEncode để tránh bị trình duyệt thay đổi thông tin.  vnmpid: số đơn hàng cần thanh toán (ReferenceNo). Trước khi gửi phải sử dụng hàm UrlEncode để trách bị trình duyệt thay đổi thông tin.  vnmam: tổng tiền phải thanh toán (Amount) cho đơn hành tại điểm chấp nhận thanh toán.  vnmdt: thời gian phát sinh giao dịch tại điểm chấp nhận thanh toán, theo định dạng: yyyyMMddHHmmss.  vnmsig: chữ ký điện tử của doanh nghiệp trên các thông tin: TerminalCode – ReferenceNo – Amount – Localdatetime. Chữ ký được ký theo thuật toán RSA 1024 bits, bằng Private Key do doanh nghiệp tạo ra và bảo quản. Sau khi ký xong chuyển về dạng Hexa. Trước khi gửi sang phải được sử dụng hàm UrlEncode để tránh bị trình duyệt thay đổi thông tin. Nhà cung cấp sẽ dùng khóa Public Key do doanh nghiệp cung cấp để chứng thực tính toàn vẹn của thông tin được doanh nghiệp chuyển sang. 45 3.4.2. URL doanh nghiệp kết nối Xây dựng chứng năng chuyển thông tin cần thanh toán theo định dạng mà nhà cung cấp yêu cầu ở mục 3.4.1. Xây dựng một đường dẫn URL đón nhận dữ liệu với các tham số như sau:  Tham số 1: Dữ liệu về đơn hàng sau khi thanh toán. Theo cấu trúc: NHACUNGCAP-RC-AuthorizationNumber-ReferenceNo- TraceInNhaCungCap-NhaCungCapDateTime-TerminalCode. Trước khi gửi sang được sử dụng hàm UrlEncode để tránh bị trình duyệt thay đổi thông tin. Khi lấy về cần sử dụng hàm UrlDecode để lấy thông tin. Trong đó: o RC – 00: Thanh toán thành công. xx – Tham chiếu bảng mã lỗi. o ReferenceNo – Mã đơn hàng tại điểm chấp nhận thanh toán. o AuthorizationNumber – Mã số cấp phép trong hệ thống tài khoản. o ReferenceNo – Mã đơn hàng cần yêu cầu thanh toán. o TraceInNhaCungCap – Số Trace duy nhất tại hệ thống VnMart. o NhaCungCapDateTime – Thời gian phát sinh giao dịch tại NhaCungCap theo định dạng yyyyMMddHHmmss. o TerminalCode – Mã điểm chấp nhận thanh toán.  Tham số 2: Chữ ký của nhà cung cấp trên thông tin Tham số 1, bằng thuật toán RSA 1024 – Private Key (Base64) [10] và chuyển sang mã Hexa. Trước khi gửi được sử dụng hàm URLEncode để tránh trình duyệt thay đổi thông tin. Khi doanh nghiệp lấy dữ liệu về cần sử dụng hàm UrlDecode để lấy thông tin. Doanh nghiệp dùng khóa PublicKey của nhà cung cấp để chứng thực tính toàn vẹn của các thông tin mà nhà cung cấp chuyển sang cho doanh nghiệp 3.4.3. Hàm xác thực giữa nhà cung cấp và doanh nghiệp 1. SignData: Mục đích: Tạo chữ ký điện tử trên các thông tin cần ký, theo khóa Private. Đầu vào: p_Input: Dữ liệu cần ký. p_PrivateKey: Khóa Private. 46 Đầu ra: Chữ ký điện tử của doanh nghiệp trên các thông tin đã ký, Chữ ký này đã được chuyển sang mã Hexa. 2. VerifyData: Mục đích: Kiểm tra tính hợp lệ của chữ ký. Đầu vào: p_SignInput: Chữ ký điện tử (Chữ ký đã được chuyển sang mã Hexa). p_OriginInput: Dữ liệu gốc, dữ liệu này dùng để ký bằng khóa Private theo thuật toán RSA. p_PublicKey: Khóa công khai . Đầu ra: True/False: - Tính toàn vẹn của thông tin. 3. GenerateKey: Mục đích: Tạo cặp khóa Private, Public theo thuật toán RSA. Đầu vào: p_KeySize: Độ dài của khóa (Ở đây chúng ta sẽ dùng là 1024 bit). Đầu ra: Cặp khóa công khai, bí mật. 4. Save: Mục đích: Save 2 cặp khóa Private, Public được tạo ra ở hàm GenerateKey vào 2 file khóa. Đầu vào: p_PathKey: Đường dẫn lưu 2 file khóa. p_KeySize: Độ dài của khóa (Ở đây chúng ta sẽ dùng là 1024 bit). Đầu ra: Save vào thư mục lưu 2 file khóa 2 file netPublicKey.rsa và netPrivateKey.rsa. 5. Read: Mục đích: Đọc 2 file khóa được save bằng hàm Save (4) được tạo ở trên. Đầu vào: p_PathPubKey: Đường dẫn file khóa Public Key. p_PathPriKey: Đường dẫn file khóa PrivateKey. 47 Đầu ra: Cặp khóa công khai (PublicKey) và bí mật (PrivateKey). 6. ReadPublicKey: Mục đích: Đọc file khóa công khai (PublicKey) của nhà cung cấp. Đầu vào: p_PathKey: Đường dẫn file khóa Public Key. Đầu ra: Khóa công khai (PublicKey) của nhà cung cấp. 48 CHƯƠNG 4: TRIỂN KHAI Trong chương này luận văn sẽ trình bầy các nội dung triển khai thực tế thương mại điện tử cho các thuê bao di động như đã đề xuất ở chương 3. Nội dung của chương được chia làm hai phần: phân tích thiết kế và triển khai thực tế tại một công ty cung cấp dịch vụ cho viễn thông và ngân hàng. 4.1. Phân tích thiết kế Trên mô hình đề xuất ở chương 3, chúng ta phân tích thiết kế hai hệ thống: quản lý thẻ trả trước (Prepaidcard) và hệ thống tài khoản ảo (Airtime) theo ngôn ngữ mô hình hóa thống nhất UML [1,9]. 4.1.1. Các chức năng Hệ thống quản lý thẻ trả trước (Prepaidcard): A.1. Phát hành thẻ: A.1.1. Phát hành thẻ. A.1.2. Xuất dữ liệu thẻ. A.1.3. In thẻ. A.2. Quản lý thẻ: A.2.1. Xem thông tin thẻ. A.2.2. Tra cứu giao dịch. A.2.3. Đổi thẻ. A.2.4. Gia hạn thẻ. A.2.5. Ngừng sử dụng thẻ. A.2.6. Kích hoạt thẻ. A.2.7. Tạo PIN mới. A.3. Quản lý đại lý: A.3.1. Xem thông tin đại lý. A.3.1 Tra cứu giao dịch đại lý. A.3.1. Chấp nhận thẻ. A.3.1. Từ chối thẻ. A.4. Quản lý hệ thống: A.4.1. Doanh nghiệp phát hành thẻ. 49 A.4.2. Loại sản phẩm thẻ. A.4.3. Trạng thái thẻ. A.4.4. Đại lý. A.4.5. Điểm chấp nhận thanh toán đại lý. A.4.6. Quản lý người dùng. A.4.7. Phân quyền chức năng. A.4.8. Nhật ký sử dụng. Hệ thống quản lý tài khoản ảo (Airtime): B.1. Quản lý khách hàng: B.1.1. Quản lý khách hàng. B.1.2. Quản lý đại lý. B.2. Quản lý tài khoản: B.2.1. Quản lý tài khoản. B.2.2. Giới hạn tài khoản. B.3. Quản lý dịch vụ: B.3.1. Tra cứu giao dịch khách hàng. B.3.1. Quản lý giao dịch khách hàng. B.3.2. Chứng từ nạp tiền cho khách hàng. B.4. Quản lý hệ thống: B.4.1. Loại tài khoản. B.4.2. Loại kinh doanh. B.4.3. Loại giao dịch. B.4.4. Đơn vị tiền tệ. B.4.5. Quản lý người dùng. B.4.6. Phân quyền chức năng. B.4.7. Nhật ký sử dụng. 4.1.2. Biểu đồ Use Case Hệ thống quản lý thẻ trả trước (Prepaidcard): Xác định các tác nhân tham gia vào hệ thống: quản trị hệ thống, doanh nghiệp phát hành thẻ, đại lý, khách hàng 50 1. Phát hành thẻ: 2. Quản lý thẻ: 3. Quản lý đại lý: 51 4. Quản lý hệ thống: Hệ thống quản lý tài khoản ảo (Airtime): Xác định các tác nhân tham gia vào hệ thống: quản trị hệ thống, kế toán, đại lý, khách hàng. 1. Quản lý khách hàng: 2. Quản lý tài khoản: 52 3. Quản lý dịch vụ 4. Quản lý hệ thống: 4.2. Triển khai thực tế Hiện nay mô hình thanh toán thương mại điện tử cho thuê bao di động đang được triển khai thực tế tại công ty cổ phần thanh toán Việt Nam (VNPAY) với dịch vụ ví điện tử Vnmart. Đã kết nối trực tiếp tới các ngân hàng: Agribank, Vietinbank, Bidv, Techcombank, Dongabank, Sacombank, Navibank, Vpbank, Lienvietbank, Eximbank, Indovinabank, Vibbank. Đã thuê đầu số tin nhắn 8x49 kết nối tới các công ty viễn thông: Vinaphone, Mobifone, Viettel, Sfone, Evntelecom, Vietnamobile, Beeline. 53 54 82 272 717 389 2147 1744 1479 1063 891 834 0 500 1000 1500 2000 2500 1 2 3 4 5 6 7 8 9 10 11 65 77 238 4344 6211 11541 25730 38651 51810 56558 64007 0 10000 20000 30000 40000 50000 60000 70000 1 2 3 4 5 6 7 8 9 10 11 Các doanh nghiệp đã kết nối: Vinaphone, Mobifone, Viettel, Sfone, Vietnamobile, Beeline, Công ty cổ phần truyền thông năng động, Công ty truyền thông tương tác không dây – Megaonline, Công ty cổ phàn Chọn và Mua, Công ty Hà Linh, Công ty cổ phần dịch vụ vé trực tuyến, Công ty cổ phần VietNet, … Sau đây là một số các biểu đồ thống kê cho dịch vụ ví điện tử Vnmart: Hình 4.1 Biểu đồ khách hàng đăng ký dịch vụ Vnmart năm 2009 Hình 4.2 Biểu đồ số giao dịch Vnmart năm 2009 54 33 20 42 809 1414 2692 6680 14170 11471 9600 11859 0 2000 4000 6000 8000 10000 12000 14000 16000 1 2 3 4 5 6 7 8 9 10 11 Hình 4.3 Biều đố số giao dịch(số tiền >= 100.000) Vnmart năm 2009 Qua các biểu đồ thống kê trên chúng tôi thấy số lượng khách hàng kích hoạt tài khoản ví điện tử Vnmart, số lượng giao dịch tăng nhanh theo từng tháng (trong đó các giao dịch với số tiền >= 100.000 cũng tăng cao). Vậy hệ thống ví điện tử Vnmart đã đáp ứng được yêu cầu với số lượng khách hàng và số giao dịch ngày càng lớn. 55 KẾT LUẬN Luận văn đã tìm hiểu các mô hình thương mại điện tử đang có tại Việt nam: cách thức hoạt động, phân tích các nhược điểm. Với các nhược điểm của các mô hình thương mại điện tử đã triển khai luận văn đã đề xuất giải pháp thương mại điện tử cho thuê bao di động với cách thức thanh toán thương mại điện tử an toàn, nhanh chóng và tiện lợi thông qua tin nhắn SMS hoặc Website bán hàng. Luận văn đã xây dựng và triển khai các thành phần của hệ thống thương mại điện tử cho thuê bao di động: kết nối các ngân hàng, kết nối các công ty viễn thông, hệ thống thẻ trả trước, hệ thống tài khoản ảo, kết nối tới các doanh nghiệp bán hàng. Giải pháp thương mại điện tử cho thuê bao di động đã được triển khai thực tế tại một công ty cung cấp giải pháp cho ngân hàng và viễn thông. Qua thực tế triển khai thấy được giải pháp đã mang lại hiệu quả cao với số lượng khách hàng và số giao dịch tăng nhanh mang lại một dịch vụ có nhiều tiện ích cho khách hàng. Phương hướng tiếp theo của luận văn là hoàn thiện các chức năng của hệ thống thương mại điện tử cho thuê bao di động đồng thời nghiên cứu các giải pháp mới để hệ thống có thể chấp nhận thanh toán với các thẻ quốc tế như Master Card, Visa Card. TÀI LIỆU THAM KHẢO Tài liệu Tiếng Anh [1] Doug Rosenberg, Matt Stephens (2007), Use Case Driven Object Modeling with UML, Springer Verlag, New York. [2] Emma Anamuah, Mensah Georgia Marfo (2009), E-Business Adoption in the Banking Industry in Ghana, Master Thesis, Lulea University of Technology Sweden. [3] Garcia-Bobia Alvarez, Luis – Garcia Cesa, Victor Jose (2008), A Mobile Web 2.0 Community Service based on Near-Field Communication, Master Thesis, Lulea University of Technology Sweden. [4] Julie Mariga (2003), Managing E-Commerce and Mobile Computing Technologies, Irm Press, United States of America. [5] Man Young Rhee (2003), Internet Security: Cryptographic principles, algorithms and protocols, John Wiley & Sons, New York. [6] SMPP Developers Forum (1999), Short message peer to peer protocol specification v3.4. [7] Vesna Hassler (2000), Security Fundamentals for E-Commerce, Artech House, Boston. [8] Warren D.Raisch (2001), The E-Marketplace Strategies for Success in B2B Ecommerce, McGraw-Hill,New York. [9] Wendy Boggs, Michael Boggs (2002), Mastering UML with Rational Rose 2002, Sybex, San Francisco. [10] William Stallings (2005), Crytography and Network Sercurity Principles and Practices Fourth Edition, Prentice Hall, United States of America. [11] William S.Davis, John Benamati (2003), E-Commerce Basics: Technology Foundations and E-Business Applications, Prentice Hall, United States of America. Tài liệu Tiếng Việt [12] Công ty cổ phẩn chuyển mạch tài chính quốc gia Việt Nam (2007), Tiêu chuẩn kỹ thuật kết nối BANKNETVN, Hà Nội. [13] Công ty cổ phẩn giải pháp thanh toán Việt Nam (2007), Tài liệu đặc tả giao diện kết nối với ngân hàng công thương Việt Nam, Hà Nội. [14] Nguyễn Đăng Hậu (2004), Kiến thức thương mại điện tử, Viện đào tạo Công nghệ và Quản lý quốc tế, Hà Nội. PHỤ LỤC A- CÁC WEBSITE CỦA HỆ THỐNG VNMART: Trang web của hệ thống Vnmart: Trang web quản lý hệ thống thẻ Prepaid: Trang web quản lý tài khoản ảo Airtime: B-ỨNG DỤNG JAVA CHO HỆ THỐNG VNMART Xây dựng ứng dụng cho dòng điện thoại có hỗ trợ java giúp cho thuê bao di động có thể tra cứu số dư, vấn tin giao dịch, chuyển khoản, nạp tiền điện thoại, mua thẻ game,…

Các file đính kèm theo tài liệu này:

  • pdfLUẬN VĂN- GIẢI PHÁP THƯƠNG MẠI ĐIỆN TỬ CHO THUÊ BAO DI ĐỘNG.pdf