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ô...
67 trang |
Chia sẻ: haohao | Lượt xem: 1189 | Lượt tải: 1
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:
- LUẬN VĂN- GIẢI PHÁP THƯƠNG MẠI ĐIỆN TỬ CHO THUÊ BAO DI ĐỘNG.pdf