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

g 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,…