BAN CƠ YẾU CHÍNH PHỦ

HỌC VIỆN KỸ THUẬT MẬT MÃ

¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

BÁO CÁO BÀI TẬP LỚN

TÌM HIỂU VỀ HỆ THỐNG VÍ THANH TOÁN ĐIỆN TỬ

Ngành: An toàn thông tin

Giảng viên hướng dẫn:

Bùi Việt Thắng
Khoa An toàn thông tin – Học viện Kỹ thuật mật mã

Sinh viên thực hiện:

Nguyễn Chí Bình – AT14A
Trần Nguyệt Chi – AT14B
Quách Ngọc Quảng – AT14A

Hà Nội, 2021

i
ii
 MỤC LỤC
MỤC LỤC................................................................................................................ii
DANH MỤC HÌNH VẼ.........................................................................................iii
LỜI NÓI ĐẦU........................................................................................................iv
CHƯƠNG 1. TỔNG QUAN VỀ VÍ ĐIỆN TỬ.....................................................5
1.1. Khái niệm về ví điện tử..................................................................................5
1.2. Dịch vụ ví điện tử..........................................................................................5
1.2.1. Hoạt động cung ứng Ví điện tử............................................................6
1.2.2. Hồ sơ mở ví điện tử..............................................................................6
1.3. Những chức năng của ví điện tử.........................................................................7
1.4. Lợi ích của ví điện tử.....................................................................................8
CHƯƠNG 2. HỆ THỐNG VÍ ĐIỆN TỬ.............................................................10
2.1. Wallet Entities..................................................................................................10
2.2. Wallet Accounting Structure............................................................................11
2.3. Technical overview..........................................................................................13
2.3. Multi-Subsidiary...............................................................................................14
2.4. Balance Transactions........................................................................................15
2.5. Fee Handling....................................................................................................20
2.6. Wallet and Payment Module Interaction..........................................................22
2.7. User Module.....................................................................................................27

DANH MỤC HÌNH V

iii
Hình 1. Ví điện tử.....................................................................................................4
Hình 2. Wallet Entities.............................................................................................9
Hình 3. Technical Overview..................................................................................12
Hình 4. Giao dịch ở một công ty con.....................................................................13
Hình 5. Giao dịch ở nhiều công ty con...................................................................13
Hình 6. Giao dịch số dư khác nhau........................................................................15
Hình 7. Biểu đồ hoạt động giao dịch bằng ví điện tử.............................................16
Hình 8. Biểu đồ hoạt động liên kết ví điện tử với thẻ ngân hàng...........................17
Hình 9. Usecase tổng quát......................................................................................19
Hình 10. Biểu đồ hoạt động nạp tiền vào ví điện tử...............................................32

iv
 LỜI NÓI ĐẦU

Ngày càng nhiều doanh nghiệp nhận thức được lợi ích to lớn của việc tiến
hành hoạt động thương mại bằng những phương tiện điện tử. Thông qua các
phương tiện điện tử, mọi hoạt động kinh doanh đều được tiến hành nhanh chóng,
hiệu quả và tiết kiệm hơn, không phụ thuộc vào thời gian và khoảng cách địa lí.
Với việc ứng dụng ngày càng cao về công nghệ thông tin, việc phi vật chất
hoá các trung gian thanh toán ngày càng được thực hiện tốt hơn, điều đó cho phép 
tăng độ tin cậy của quá trình thanh toán.
Ví điện tử là một phương tiện thanh toán trung gian, nó như một ví tiền trên
mạng Internet và điện thoại di động mà người tiêu dùng có thể sử dụng để mua bán
hàng hóa tại các trang web hoặc thanh toán chi phí điện, nước, điện thoại… Tương
tự như ở các nước có nền thương mại điện tử phát triển, người sử dụng ở Việt Nam
hiện cũng có thể nạp tiền từ tài khoản ngân hàng vào ví điện tử hoặc ngược lại,
hoặc chuyển tiền dễ dàng.
Thị trường ví điện tử ở Việt Nam mặc dù mới trong giai đoạn phát triển ban
đầu nhưng đang trở nên sôi động với sự tham gia của cả nhà cung cấp dịch vụ
nước ngoài,  điều này góp phần tạo cho người tiêu dùng nhiều cơ hội hơn trong
việc lựa chọn một phương thức thanh toán điện tử phù hợp.
Nhận thức được những lợi ích cũng như tiềm năng phát triển của loại hình
thanh toán không dùng  tiền mặt này, nhóm chúng em đã chọn đề tài “Tìm hiểu về
hệ thống ví thanh toán điện tử”.
Sau thời gian thực hiện bài tập lớn, các mục tiêu về cơ bản đã đạt được. Rất
mong được sự góp ý của các thầy cô, cũng như các bạn bài tập lớn này được hoàn
thiện hơn.
SINH VIÊN THỰC HIỆN
Nguyễn Chí Bình
Trần Nguyệt Chi
Quách Ngọc Quảng

v
 CHƯƠNG 1. TỔNG QUAN VỀ VÍ ĐIỆN TỬ

1.1. Khái niệm về ví điện tử

Ví số, hay ví điện tử, là một thuật ngữ dùng trong giao dịch thương mại điện tử.
Thực chất ví điện tử còn được biết đến là ví số. Đây là một tài khoản điện tử online
thường được xây dựng trong ứng dụng điện thoại, website máy tính.  Loại ví này
có vai trò thanh toán trực tuyến các khoản tiền mà không cần mang theo tiền mặt.
Trong đó chẳng hạn như mua sắm, thanh toán tiền điện nước, chuyển tiền, mua
hàng online.

Hình 1. Ví điện tử

1.2. Dịch vụ ví điện tử

Dịch vụ ví điện tử là dịch vụ cung cấp cho khách hàng một tài Khoản điện tử
định danh do các tổ chức cung ứng dịch vụ trung gian thanh toán tạo lập trên vật
mang tin (như chip điện tử, sim điện thoại di động, máy tính...), cho phép lưu giữ
một giá trị tiền tệ được đảm bảo bằng giá trị tiền gửi tương đương với số tiền được
chuyển từ tài Khoản thanh toán của khách hàng tại ngân hàng vào tài Khoản đảm
bảo thanh toán của tổ chức cung ứng dịch vụ ví điện tử theo tỷ lệ 1:1.
Theo quy định tại Điều 2 Thông tư 39/2014/TT-NHNN Dịch vụ ví điện tử là
một dịch vụ thuộc dịch vụ hỗ trợ dịch vụ hỗ trợ thanh toán.
Dịch vụ ví điện tử là dịch vụ cung cấp cho khách hàng một tài Khoản điện tử
định danh do các tổ chức cung ứng dịch vụ trung gian thanh toán tạo lập trên vật
mang tin (như chip điện tử, sim điện thoại di động, máy tính...), cho phép lưu giữ
một giá trị tiền tệ được đảm bảo bằng giá trị tiền gửi tương đương với số tiền được
chuyển từ tài Khoản thanh toán của khách hàng tại ngân hàng vào tài Khoản đảm
bảo thanh toán của tổ chức cung ứng dịch vụ ví điện tử theo tỷ lệ 1:1.” (khoản 8
Điều 1 Nghị định 80/2016/NĐ-CP)
6
1.2.1. Hoạt động cung ứng Ví điện tử 
Tại Điều 9 Thông tư 39/2014/TT-NHNN quy định về Hoạt động cung ứng Ví
điện tử như sau:
Tổ chức cung ứng dịch vụ Ví điện tử không được phép:
 Phát hành hơn 01 (một) Ví điện tử cho một tài khoản thanh toán của khách
hàng tại một ngân hàng;
 Cấp tín dụng cho khách hàng sử dụng Ví điện tử, trả lãi trên số dư Ví điện tử
hoặc bất kỳ hành động nào có thể làm tăng giá trị tiền tệ trên Ví điện tử.
Tổ chức cung ứng dịch vụ Ví điện tử phải có công cụ để Ngân hàng Nhà nước
kiểm tra, giám sát theo thời gian thực tổng số tiền của khách hàng trên các Ví điện
tử và tổng số tiền trên tài khoản đảm bảo thanh toán của tổ chức cung ứng dịch vụ
Ví điện tử tại các ngân hàng.
Việc nạp tiền vào Ví điện tử, rút tiền ra khỏi Ví điện tử của khách hàng phải
thực hiện thông qua tài khoản thanh toán của khách hàng tại ngân hàng.
1.2.2. Hồ sơ mở ví điện tử
Hồ sơ mở Ví điện tử theo quy định tại khoản 3 Điều 1 Thông tư 23/2019/TT-
NHNN gồm những giấy tờ sau:
a) Đối với Ví điện tử của cá nhân:
 Thông tin của cá nhân mở Ví điện tử theo yêu cầu của tổ chức cung ứng dịch vụ
Ví điện tử và phù hợp với quy định tại khoản 2 Điều này;
 Căn cước công dân hoặc chứng minh nhân dân hoặc hộ chiếu còn thời hạn, giấy
khai sinh (đối với cá nhân là công dân Việt Nam chưa đủ 14 tuổi); thị thực nhập
cảnh hoặc giấy tờ chứng minh được miễn thị thực nhập cảnh của cá nhân mở Ví
điện tử (đối với cá nhân là người nước ngoài);
b) Đối với Ví điện tử của tổ chức:
 Thông tin của tổ chức mở Ví điện tử theo yêu cầu của tổ chức cung ứng dịch vụ
Ví điện tử và phù hợp với quy định tại khoản 2 Điều này;
 Một trong các giấy tờ chứng minh việc tổ chức mở Ví điện tử được thành lập và
hoạt động hợp pháp như: Quyết định thành lập, giấy chứng nhận đăng ký doanh
nghiệp, giấy chứng nhận đầu tư hoặc các giấy tờ khác theo quy định của pháp
luật;
 Các giấy tờ chứng minh tư cách đại diện của người đại diện theo pháp luật hoặc
đại diện theo ủy quyền (gọi là người đại diện hợp pháp) của tổ chức mở Ví điện
tử kèm theo căn cước công dân hoặc chứng minh nhân dân hoặc hộ chiếu còn
thời hạn của người đó;

7
c) Khách hàng đăng ký mở Ví điện tử có thể xuất trình các tài liệu quy định tại
điểm a(ii), b(ii) và b(iii) khoản này dưới hình thức bản chính hoặc bản sao hoặc
bản quét (scan) từ bản gốc hoặc hình thức khác theo quy định của tổ chức cung
ứng dịch vụ Ví điện tử;
d) Khách hàng có thể đăng ký và gửi Hồ sơ mở Ví điện tử trực tiếp tại trụ sở, chi
nhánh, phòng giao dịch của tổ chức cung ứng dịch vụ Ví điện tử hoặc các kênh
giao dịch trực tuyến của tổ chức cung ứng dịch vụ Ví điện tử hoặc các phương
thức khác theo quy định của tổ chức cung ứng dịch vụ Ví điện tử và phù hợp với
quy định của pháp luật.
Ví điện tử ra đời nhằm thúc đẩy chủ trương thanh toán không dùng tiền mặt
của chính phủ. Nhiều chuyên gia tài chính cũng khá e ngại trước tình trạng thời
gian qua hàng loạt đơn vị đua nhau ra mắt các loại ví điện tử để giúp khách hàng
thuận tiện trong các giao dịch điện tử lại cho sử dụng các hình thức nạp, rút tiền
ngoài ngân hàng. Nhưng một trong những nguy cơ của nạn rửa tiền của tội phạm
chính là tìm cách đưa dòng tiền bất hợp pháp vào lưu chuyển trong hệ thống kinh
tế tài chính. Đây là giai đoạn khó khăn của tội phạm rửa tiền vì tiền và tài sản bất
hợp pháp sẽ được cơ quan điều tra theo dõi. Hơn nữa, các cơ quan chức năng sẽ
đặt ra các quy chế, quy định pháp luật để khống chế tội phạm rửa tiền thông qua
việc quy định lượng tiền mặt được chuyển qua biên giới, số tiền được thanh toán,
khai báo ngân hàng. Quy chế này được cụ thể hóa thông qua Điều 9 Thông tư
39/2014/TT-NHNN quy định về hoạt động ví điện tử như sau:
1. Tổ chức cung ứng dịch vụ Ví điện tử không được phép:
 Phát hành hơn 01 (một) Ví điện tử cho một tài khoản thanh toán của khách
hàng tại một ngân hàng;
 Cấp tín dụng cho khách hàng sử dụng Ví điện tử, trả lãi trên số dư Ví điện tử
hoặc bất kỳ hành động nào có thể làm tăng giá trị tiền tệ trên Ví điện tử.
2. Tổ chức cung ứng dịch vụ Ví điện tử phải có công cụ để Ngân hàng Nhà nước
kiểm tra, giám sát theo thời gian thực tổng số tiền của khách hàng trên các Ví điện
tử và tổng số tiền trên tài khoản đảm bảo thanh toán của tổ chức cung ứng dịch vụ
Ví điện tử tại các ngân hàng.
3. Việc nạp tiền vào Ví điện tử, rút tiền ra khỏi Ví điện tử của khách hàng phải
thực hiện thông qua tài khoản thanh toán của khách hàng tại ngân hàng.

1.3. Những chức năng của ví điện tử

Như định nghĩa về ví điện tử là gì thì ví sẽ hoạt động khi có sự liên kết với tài
khoản ngân hàng. Từ đó, ví điện tử sẽ có những chức năng cụ thể như sau:

8
  Thanh toán: Dùng ví điện tử để thanh toán các loại hoá đơn dịch vụ, mua
sắm như: tiền điện, tiền nước, mua vé xem phim, đóng phí bảo hiểm… 
 Chuyển và nhận tiền: Ví điện tử có thể chuyển và nhận tiền từ các tài khoản
ví điện tử với nhau cũng như từ ví đến tài khoản ngân hàng hoặc ngược lại.
 Lưu trữ: Ví điện tử có thể giữ tiền với số lượng khá lớn, giúp bạn dễ dàng
mua hàng, nhận thanh toán, tiết kiệm…
Đặc biệt cần lưu ý, tất cả chức năng của ví điện tử được áp dụng trong môi trường
trực tuyến.

1.4. Lợi ích của ví điện tử

Ví điện tử hiện nay được sử dụng phổ biến trên toàn Thế giới với các thương
hiệu như Moneybooker, WebMoney,…Còn ở Việt Nam, hình thức thanh toán này
cũng đang dần trở nên bùng nổ hơn. Các đơn vị tham gia phát triển và khách hàng
đang ngày càng tin tưởng, tin dùng nhiều hơn. Bởi lẽ ví tiền điện tử mang đến cho
chủ nhân sở hữu nhiều lợi ích vô cùng đặc biệt. Trong đó chẳng hạn như:
 Đảm bảo sự tiện lợi cho người tiêu dùng : lý do là vì ví điện tử khi mang theo
có thể giúp người dùng hạn chế số lượng thẻ và tiền mặt. Tất cả những gì người
dùng cần làm là sử dụng ví điện tử để thanh toán cho các mặt hàng. Chỉ cần
người dùng quét thẻ hoặc chạm vào các thiết bị thanh toán là được. Vì vậy mà
quá trình thanh toán nhanh gọn, tiện lợi và tiết kiệm tối đa thời gian chờ đợi.
Hơn nữa người dùng cũng có thể hạn chế tình trạng trộm cắp tiền mặt hay khó
khăn khi thanh toán. 
 Cung cấp quyền truy cập cho nhiều loại thẻ khác nhau: ví điện tử là tổ hợp lưu
trữ thẻ tín dụng cũng như thẻ ghi nợ. Loại ví này có thể ứng dụng đa dạng cho
nhiều loại thẻ khác nhau. Đặc biệt nếu nhà cung cấp tương thích cùng với loại
ví điện tử chúng ta đang dùng còn ấn tượng hơn. Chúng ta được phép lưu trữ
thẻ tích điểm hay thẻ khách hàng khi thanh toán. Thậm chí chúng ta còn được
nhận các phiếu giảm giá cho phép bạn tận hưởng cuộc sống mà không cần giấy
tờ. 
 Bảo mật tốt hơn: cụ thể ví tiền điện tự giống một chiếc thẻ ghi trợ trong quá
trình giao dịch. Ngay khi thực hiện bất kỳ thanh toán nào, người dùng cũng
phải cần nhập mã PIN để ủy quyền thanh toán. Một số thiết bị tích hợp sinh trắc
học người dùng cần có dấu vân tay thì mới thanh toán được.Hơn hết ví điện tử
còn được xác minh qua nhà cung cấp bên thứ 3. Ngay cả khi người dùng mất ví
điện tử thì vẫn có thể truy cập vào tài khoản bằng một thiết bị mới. Vì vậy khi
sử dụng ví tiền điện tử bạn hoàn toàn an tâm về các rủi ro mất cắp tiền bạc.
Đồng thời hạn chế tối đa tình trạng  mượn danh tính thanh toán hoặc rút tiền.
Đây là một lợi thế lớn so với việc chúng ta sử dụng tiền mặt hay các loại tài
khoản ngân hàng khác. 

9
 Dễ dàng theo dõi thói quen chi tiêu: đây là một trong những điều đáng chú ý
khi nhắc đến lợi ích dùng ví điện tử là gì. Bởi lẽ ví điện tử có thể tạo các báo
cáo chi tiết loại chi tiêu cụ thể của người dùng trong ngày, tháng. Từ đó người
dùng có thể kiểm soát tài chính của mình một cách hiệu quả. Mặt khác ví điện
tử cũng có thể giúp người dùng quản lý các chi tiêu một cách có logic. Chỉ cần
khi sử dụng, chúng ta cố định ngân sách cho các danh mục chi tiêu là được.
Điều này sẽ giúp chúng ta mua sắm đúng với khoản chi tiêu đề ra và không
vượt quá mức quy định.  Tuy nhiên trong trường hợp nếu mua mặt hàng quá lớn
thì có thể vô hiệu quá tính năng quản lý. Như vậy chúng ta sẽ có đủ số tiền để
thực hiện thanh toán trong những lúc cần thiết. 

10
 CHƯƠNG 2. HỆ THỐNG VÍ ĐIỆN TỬ

2.1. Wallet Entities

Hình 2. Wallet Entities

Subsidiary đại diện cho pháp nhân hệ thống là đối tác hợp đồng hợp pháp
cho mọi Người dùng. Nó có bộ tài khoản kế toán (đóng) riêng và là cơ sở cho hầu
hết các cấu hình.
User đại diện cho một pháp nhân khách hàng là đối tác hợp đồng hợp pháp
cho Công ty con. Người dùng có thể có các thuộc tính như tên / địa chỉ, có thể có
số nhận dạng (chẳng hạn như địa chỉ email hoặc số điện thoại được sử dụng để
đăng nhập / nhận dạng) và dữ liệu xác thực (ví dụ: mật khẩu hoặc thông tin đăng
nhập API và vai trò bảo mật). Người dùng là chủ sở hữu của một chiếc ví. Người
dùng có mức xác minh tương ứng với quy trình KYC được thực thi.
Wallet đại diện cho hợp đồng giữa Công ty con và Người dùng, đồng thời là
nơi chứa tài khoản ví và công cụ thanh toán.
WalletAccount đại diện cho một tài khoản trong ví với một loại tiền tệ duy
nhất và một mục đích xác định, tùy thuộc vào loại tài khoản-ví. Thông thường, ít
nhất một tài khoản ví chính tồn tại trong một ví hoặc nhiều tài khoản trong trường
hợp ví hỗ trợ nhiều loại tiền tệ. Tài khoản ví có thể lưu trữ tiền và khả năng sử
dụng phụ thuộc vào cấu hình kế toán và giao dịch trong hệ thống.

11
 WalletAccountItem đại diện cho một hoạt động trên tài khoản ví, có thể
hoặc không ảnh hưởng đến số dư tài khoản ví. Ví-tài-khoản-mục từ bảng sao kê tài
khoản. Thông thường, mỗi giao dịch có một hoặc nhiều ví-tài khoản-mục. Ví-tài-
khoản-mục tổng hợp tất cả các-chuyển-kế-toán có thể được yêu cầu cho một sự
kiện giao dịch.
PaymentIusalment đại diện cho tài khoản ngân hàng, thẻ tín dụng hoặc ví
tiền điện tử được sử dụng để nạp tiền hoặc rút tiền từ tài khoản ví.
Transaction là loại chung cho bất kỳ thực thể / quy trình nào ảnh hưởng đến
số dư tài khoản ví, chẳng hạn như thanh toán, hóa đơn hoặc mua hàng. Một giao
dịch luôn tham chiếu đến một hoặc nhiều tài khoản ví và có thể có bất kỳ số lượng
ví-tài khoản-mục nào.
EmoneyAccount là tài khoản trong cấu phần kế toán, lưu trữ tiền của một
loại nhất định cho một tài khoản ví. Một tài khoản ví có thể có nhiều tài khoản
emoney, ví dụ: cho các loại tiền khác nhau (không hạn chế hoặc mã MCC bị hạn
chế).

2.2. Wallet Accounting Structure

Accounting concept

Subsidiary Đại diện cho một pháp nhân chính mà ví thuộc về. Tất cả các kết
chuyển kế toán đều nằm trong một công ty con, do đó mỗi công ty con được coi là
một phạm vi kế toán riêng biệt. Như vậy, mỗi công ty con có bộ tài khoản hệ
thống, định nghĩa VAT, v.v.
Wallet Đại diện cho thực thể ví chính, có thể có 0 hoặc nhiều Tài khoản
WalletAccount. Một hoặc nhiều người dùng có thể có quyền truy cập vào ví. Vì nó
chỉ là một vùng chứa cho WalletAccounts, nó không có số dư hoặc đơn vị tiền tệ,
ngoài số dư tổng hợp của tất cả các Tài khoản WalletAccount được sở hữu.

12
 WalletAccount Đại diện cho thực thể tài khoản chính hiển thị cho người
dùng, bằng một đơn vị tiền tệ duy nhất. Không có hoặc nhiều Giao dịch thay đổi số
dư tài khoản. Không có hoặc nhiều WalletAccountItems, đại diện cho hoạt động
trên WalletAccount, có thể ảnh hưởng hoặc không ảnh hưởng đến số dư.
WalletAccountItem Trình bày một hoạt động hiển thị trên WalletAccount
cho người dùng. Có thể được coi là một dòng trên bảng sao kê tài khoản, luôn nằm
trong WalletAccount-tiền tệ. Tuy nhiên, WalletAccountItem không cần phải có
hiệu lực tài chính, ví dụ: nó có thể thể hiện trong Thanh toán 'đang chờ xử lý', chưa
được xử lý. Thường thuộc về một Giao dịch. Chứa thông tin trao đổi tiền tệ trong
trường hợp Giao dịch nhiều loại tiền tệ.
Transaction Đại diện cho một quy trình ví, chẳng hạn như Hóa đơn, Mua
hàng, Chuyển khoản P2P, Thanh toán, Giao dịch. Thuộc về một Tài khoản Wallet,
không có hoặc nhiều WalletAccountItems tùy thuộc vào quy trình. Có thể bằng
đơn vị tiền tệ khác với đơn vị tiền tệ của WalletAccount, trong trường hợp đó, quy
trình trao đổi tiền tệ được áp dụng.
AccountingAccount Đại diện cho một tài khoản tài chính đơn giản bằng
một loại tiền tệ duy nhất. Chứa các Mục tài khoản tạo nên số dư tài khoản. Có thể
là nguồn hoặc đích cho Chuyển khoản.
AccountItem Thể hiện số tiền ghi có hoặc ghi nợ trên Tài khoản Kế toán.
Chứa số dư tài khoản và chuyển khoản tại thời điểm của mục tài khoản cho các
mục đích lịch sử, được thiết lập bởi một công việc không đồng bộ (do đó có một số
độ trễ).
Transfer Đại diện cho việc chuyển giao giữa hai Tài khoản Kế toán, với
một Mục tài khoản ghi nợ và ghi có. TransferType xác định, trong số những thứ
khác, việc chuyển tiền ảnh hưởng như thế nào đến TurnOver của tài khoản ghi nợ
và tín dụng, ví dụ: Không có, Tăng, Giảm.
Account Balance Số dư tài khoản là số tiền hiện có trong tài khoản, có thể
là số âm hoặc số dương. Nó là tổng của tất cả các mục tài khoản thuộc về tài
khoản.
Vì lý do hiệu suất, chúng tôi lưu vào bộ nhớ cache số dư tài khoản tổng hợp (nếu
không, việc tính toán số dư tài khoản sẽ kém hiệu quả hơn với số lượng mục tài
khoản ngày càng tăng). Số dư tài khoản tại một thời điểm nhất định được xác định
bằng cách kiểm tra mục tài khoản mới nhất trước thời điểm đó.
Account TurnOver Doanh thu tài khoản là một giá trị được tính toán dựa
trên các quy tắc kinh doanh và các khoản mục tài khoản. Nhìn chung, đó là một
con số ngày càng tăng, nhưng một số chuyển khoản cũng có thể làm giảm lượt
chuyển của một tài khoản, ví dụ như việc hủy mua hàng. Loại chuyển khoản xác
định cách một mục tài khoản ảnh hưởng đến việc chuyển giao tài khoản, ví dụ:
13
hoàn toàn không (Không có), tăng (Tăng) hoặc giảm (Giảm). Loại chuyển giao nào
được sử dụng trong tình huống nào hoàn toàn là một định nghĩa về sản phẩm.
Thông thường, chuyển khoản được sử dụng để giới hạn hoạt động tài khoản cho
khách hàng, ví dụ: bằng cách giới hạn số tiền có thể được nạp vào ví bằng thanh
toán / tín dụng thương gia /… Lượt đi trong một khoảng thời gian nhất định được
tính bằng cách trừ lượt đi tại t0 cho lượt đi tại t1.

2.3. Technical overview

Hình 3. Technical Overview

Sơ đồ trên cho thấy khái niệm kỹ thuật chung. Có nhiều dịch vụ quản lý
khác nhau cho Ví, Tài khoản và Giao dịch trên Wallet (ví dụ: Hóa đơn, Mua hàng,
Thanh toán), thực hiện các quy trình công việc và hành động cho các mục tương
ứng (ví dụ: tạo ví, tạo hóa đơn, xác nhận hóa đơn, hủy hóa đơn,…). Các dịch vụ
này không có ý kiến về việc đại diện kế toán hoặc hậu quả của các hành động của
họ. Mọi hành động quan trọng đều được báo cáo cho AccountingHandler tương
ứng, cung cấp logic cho thành phần kế toán. Mỗi Accounting Handler sử dụng
Wallet Transfer Service để thực hiện các hành động kế toán, chẳng hạn như lấy /
tạo tài khoản hoặc chuyển một số tiền giữa các tài khoản. Wallet Transfer Service
sử dụng Cấu hình Wallet Accounting Configuration để xác định loại tài khoản /
chuyển khoản nào áp dụng tại sự kiện nào. Ví dụ. nó xác định Tài khoản Kế toán
nào được tạo khi Tài khoản Wallet được tạo và xác định tài khoản nào trong số
những tài khoản đó được sử dụng để tính số dư Tài khoản Wallet. Ngoài ra,
Accounting Handler chịu trách nhiệm tạo và cập nhật Wallet AccountItems cho
các sự kiện cụ thể.
Account types : Hệ thống chứa nhiều loại tài khoản cho AccountAccounts:
System accounts (per subsidiary)
14
  Expense / Income accounts
 VAT accounts
 Currency exchange accounts
 Inter-subsidiary accounts (aggregation accounts for transfers between
subsidiaries)
 Payment method accounts (e.g. for a specific payment contract)

Wallet accounts (per WalletAccount)

 Main accounts (unrestricted available balance)
 Restricted accounts (e.g. bound to specific MCC codes)
 Reserve accounts (e.g. for escrow, reservations, ...)
 Deposit accounts (for Deposit wallet-accounts)
 Loyalty accounts (for LoyaltyProgram/Member wallet-accounts)
Payment instrument accounts (e.g. for a specific bank account or card)
 Main account

2.3. Multi-Subsidiary
Các giao dịch có thể diễn ra trong cùng một công ty con hoặc trong các công
ty con khác nhau (nếu được cấu hình cho phép đối với loại giao dịch cụ thể).
Giao dịch mua trong một công ty con có thể trông giống như sau:

Hình 4. Giao dịch ở một công ty con

Một giao dịch mua ở nhiều công ty con có thể giống như sau:

15
 Hình 5. Giao dịch ở nhiều công ty con
Tổng số dư tài khoản của 'Tài khoản cửa hàng phụ' và 'Tài khoản người tiêu
dùng phụ' cuối cùng phải luôn bằng 0 (ngay lập tức luôn luôn nếu cả hai công ty
con nằm trong cùng một DB). Các tài khoản này phản ánh các khoản nợ phải trả
nội bộ giữa cả hai công ty con.

2.4. Balance Transactions

Tính năng Giao dịch số dư cung cấp một API đột biến số dư chung có thể
được sử dụng để xây dựng quy trình giao dịch theo sản phẩm cụ thể. API cung cấp
các hoạt động cân bằng chi tiết với hành vi kế toán mặc định (nhưng có thể tùy
chỉnh).
Điều quan trọng là các quy trình làm việc sử dụng BalanceTransactions phải
áp dụng kiểm soát truy cập thích hợp! Các phương thức BalanceTransaction cho
phép đột biến số dư yêu cầu bối cảnh hệ thống và không cung cấp bất kỳ kiểm soát
truy cập cụ thể nào, bởi vì điều này luôn dành riêng cho quy trình kinh doanh sử
dụng nó.
Đây là một tính năng chính để cung cấp sự phân tách phù hợp của quy trình
giao dịch tùy chỉnh và các đột biến số dư nhất quán. Mỗi BalanceTransaction có
một Chủ sở hữu giao dịch, đề cập đến một giao dịch tùy chỉnh sử dụng TypedID
(tham chiếu yếu).
Các thao tác sau có sẵn trong dịch vụ BalanceTransactionService:
Reserve  dự trữ một số tiền trên WalletAccount và tạo một Wallet Account
Item nếu cần
AdjustReservation điều chỉnh số lượng Dự trữ hiện có (cao hơn hoặc thấp
hơn), bao gồm cả WalletAccountItem được liên kết. Giao dịch Cân bằng Dự trữ
được cập nhật (không có Giao dịch Cân bằng mới nào được tạo)
Authorize chuyển trực tiếp một số tiền từ Tài khoản Wallet sang tài khoản
khác (Tài khoản Wallet hoặc tài khoản hệ thống) và tạo Mục nhập
WalletAccountItem nếu cần
Capture giải phóng một số tiền Dự trữ và chuyển nó sang một tài khoản khác
(Tài khoản Wallet hoặc tài khoản hệ thống), đồng thời tạo một WalletAccountItem
nếu cần. Một BalanceTransaction mới được tạo cho mỗi Capture, được liên kết với
Dự trữ BalanceTransaction. Có thể nắm bắt toàn bộ số tiền hoặc một phần số tiền.
Các chế độ sau xác định cách xử lý Khoản dự trữ:
 ReleaseFullReservation - đặt trước đầy đủ sẽ được giải phóng, ngay cả khi
chỉ thu được một phần
16
  KeepRemainingReservation - chỉ số tiền đã chiếm được mới được giải
phóng, mọi khoản tiền còn lại vẫn được giữ lại
Cancel - hủy Giao dịch Cân bằng hiện có và hoàn nguyên tất cả các giao dịch
chuyển tiền được liên kết với nó. Một BalanceTransaction không thể bị hủy bỏ,
nếu có bất kỳ khoản Hoàn trả không bị hủy nào liên quan đến nó.
Refund hoàn lại số tiền Đã nắm bắt hoặc Được ủy quyền và chuyển tiền trở lại
Tài khoản WalletAccount ban đầu và tạo một WalletAccountItem nếu cần. Một
Giao dịch Cân bằng mới được tạo cho mỗi Khoản tiền hoàn lại, được liên kết với
Giao dịch Nắm bắt hoặc Ủy quyền Giao dịch Cân bằng.
Credit  - chuyển một số tiền từ tài khoản khác (tài khoản WalletAccount hoặc
tài khoản hệ thống) sang tài khoản WalletAccount và tạo WalletAccountItem nếu
cần. Tham số kiểu cho BalanceTransaction xác định trình xử lý kế toán nào sẽ
được sử dụng cho các lần chuyển tiền. Loại phụ có thể được sử dụng để xác định
nhiều biến thể, ví dụ: cho các mục tài khoản ví. Cấu hình kế toán ví phải được thiết
lập đúng cách để hỗ trợ từng Giao dịch Cân bằng dựa trên loại / loại phụ. Loại giao
dịch tương ứng bao gồm như sau: BalanceTransaction / {type}/{subtype}
Sơ đồ sau đây cho thấy các giao dịch số dư khác nhau có liên quan như thế nào.

Hình 6. Giao dịch số dư khác nhau

Một số tham số tùy chọn cho phép tinh chỉnh hành vi thực tế:
 MinimumainBalance - xác định số dư dự kiến còn lại trên WalletAccount
sau khi tiền được chuyển. Nếu không được chỉ định, không có giới hạn số
dư (do đó số dư cũng có thể trở thành số âm). Nếu được chỉ định, người xử
lý kế toán sẽ sử dụng kiểm tra số dư độc quyền để đảm bảo việc hạn chế số
dư được thực thi.
 MinimumainReservedAmount: - được sử dụng đặc biệt cho các yêu cầu nắm
bắt, cho phép thu thập nhiều hơn số tiền dự trữ.
 Mặc định là 0 cho phép chúng tôi lấy tối đa số tiền dự trữ.

17
  Khi giá trị là null cho phép chúng tôi thu được nhiều hơn số tiền đã đặt
trước.
 Nếu giá trị là dương thì số tiền đặt trước còn lại không được vượt quá giá
trị quy định.
 Nếu giá trị là âm thì cho phép ghi quá mức tối đa là số tiền được chỉ định,
số âm sẽ xác định số lượng ghi quá mức tối đa được phép
 CategoryCode - xác định loại tiền có thể được sử dụng cho việc chuyển tiền
cụ thể này. Nếu không được chỉ định, nó sẽ mặc định là Không hạn chế, để
có thể sử dụng tất cả các loại tiền.
 externalId - nếu được cung cấp, thực thi tính duy nhất của externalId này
trong phạm vi của chủ sở hữu giao dịch. Điều này có thể được sử dụng để
ngăn chặn việc bắt giữ / hoàn lại tiền hai lần ngẫu nhiên, ví dụ: do lỗi kỹ
thuật, thử lại, v.v.
Có một triển khai mặc định cho Accounting Handler (Default Balance
Transaction Accounting Handler), có thể định cấu hình ở một mức độ nào đó:
 transferModeDebit - xác định chế độ chuyển mặc định cho các giao dịch ghi
nợ, mặc định là ErrorOnOverdraw
 transferModeCredit - xác định chế độ chuyển mặc định cho các giao dịch tín
dụng, chế độ này mặc định là ErrorOnOverdraw
 transactionType - xác định loại BalanceTransaction này AccountingHandler
sẽ được sử dụng, mặc định là 'BalanceTransaction.Default'
Luồng thanh toán

Hình 7. Biểu đồ hoạt động giao dịch bằng ví điện tử

18
 Đặc tả:
 Tác nhân: người dùng
 Mô tả: cho phép người dùng giao dịch thông qua ví điện tử
Luồng sự kiện:
1. Người dùng click vào nút thanh toán, hệ thống hiển thị hộp thoại yêu cầu
xác nhận tạo giao dịch
2. Người dùng click chọn xác nhận, giao dịch được tạo thông qua hệ thống
của ví điện tử.
3. Ví điện tử yêu cầu hệ thống SMS gửi OTP đến cho người dùng
4. Hệ thống tự nhận diện đc OTP gửi đến thiết bị và tự động điền
5. Người dùng click vào nút xác nhận gửi OTP đến hệ thống
6. Hệ thống kiểm tra và tiến hành giao dịch, sau đó gửi lại thông báo cùng
với chi tiết giao dịch cho người dùng
Điều kiện: Người dùng đã đăng ký ví điện tử và OTP được nhập chính xác

Hình 8. Biểu đồ hoạt động liên kết ví điện tử với thẻ ngân hàng
Luồng sự kiện:
Bước 1: Đăng nhập và liên kết ví điện tử với Ngân hang

19
  Khách hàng mở ứng dụng ví điện tử của tổ chức trung gian thanh toán
 Khách hàng lựa chọn tính năng liên kết ngân hàng theo các bước. Chọn
thêm liên kết. Chọn ngân hàng cần liên kết.
Bước 2: Ví hiển thị màn hình nhập thông tin liên kết ví điện tử.
Bước 3: Khách hàng nhập thông tin liên kết (Thông tin thẻ nội địa/tài khoản
ngân hàng – Active Plus)
 Khách hàng nhập thông tin thẻ bao gồm: (1) Số thẻ, (2) tháng và năm
phát hành thẻ, (3) Tên dập nổi của thẻ.
 Hệ thống ví điện tử của tổ chức trung gian thanh toán chuyển thông tin
liên kết sang ngân hàng, thông tin gửi sang ngân hàng bao gồm: (1) Số
thẻ, (2) tháng & năm phát hành thẻ, (3) tên dập nổi của thẻ, (4) Số điện
thoại KH, (5) CMND /Căn cước/Passport.
Bước 4: Ví điện tử gửi thông tin liên kết ví sang ngân hàng.
Bước 5: Hệ thống MB kiểm tra tính hợp lệ của thông tin hệ thống tổ chức
trung gian thanh toán gửi sang:
 Nếu số thẻ không hợp lệ hoặc trạng thái của thẻ bị khóa hoặc thẻ hết hạn,
ngân hàng trả thông báo số thẻ không hợp lệ về Tổ chức trung gian thanh
toán, ứng dụng của Tổ chức trung gian thanh toán hiển thị thông báo tới
khách hàng.
 Nếu tháng & Năm phát hành thẻ không đúng với thông tin của thẻ, ngân
hàng trả thông báo tháng&năm phát hành thẻ không hợp lệ về Tổ chức trung
gian thanh toán, Ứng dụng Tổ chức trung gian thanh toán hiển thị thông báo
tới khách hàng.
 Nếu tên dập nổi của khách hàng không hợp lệ, ngân hàng trả thông báo tên
khách hàng không hợp lệ về Tổ chức trung gian thanh toán, Ứng dụng Tổ
chức trung gian thanh toán hiển thị thông báo tới khách hang.
 Nếu tài khoản khách hàng gắn với thẻ bị đóng, ngân hàng trả thông báo “Tài
khoản của khách hàng đã bị đóng”, ứng dụng của Tổ chức trung gian thanh
toán hiển thị thông báo tới khách hang.
 Nếu số thẻ đã đăng ký liên kết ví với tổ chức trung gian thanh toán của đơn
vị kết nối với ngân hàng, ngân hàng trả thông báo “Thẻ đã liên kết với ngân
hàng”, Ứng dụng của Tổ chức trung gian thanh toán hiển thị thông báo lỗi
tới khách hàng.
Bước 6: Gửi mã OTP cho khách hàng.
Bước 7: Khách hàng nhập mã OTP.
Bước 8: Hệ thống trung gian thanh toán chuyển thông tin mã OTP tới ngân
hàng để xác thực mã OTP.
20
 Bước 9: Ngân hàng kiểm tra mã OTP:
 Nếu mã OTP không hợp lệ, ngân hàng thông báo mã OTP không hợp lệ tới
Tổ chức trung gian thanh toán, Tổ chức trung gian thanh toán hiển thị thông
báo tới khách hàng và yêu cầu khách hàng nhập lại mã OTP. Lưu ý: Số lần
nhập sai OTP không quá 3 lần .
 Nếu mã OTP hợp lệ:
o Lưu thông tin liên kết Tài khoản ví điện tử của Tổ chức trung gian thanh
toán thành công; Thông tin liên kết tối thiểu bao gồm các trường sau: Số
ví điện tử - Số tài khoản thanh toán – Số thẻ.
o Gửi thông báo liên kết Tài khoản Tổ chức trung gian thanh toán thành
công, Tổ chức trung gian thanh toán thông báo tới khách hàng.
Bước 10: Thông báo liên kết Tài khoản của Tổ chức trung gian thanh toán
thành công.
 Tổ chức trung gian thanh toán lưu thông tin liên kết tài khoản ví điện tử.
 Tổ chức trung gian thanh toán thông báo khách hàng liên kết Tài khoản ví
điện tử của Tổ chức trung gian thanh toán thành công.

Hình 9. Usecase tổng quát

2.5. Fee Handling

21
 Fee Groups : Các định nghĩa phí có thể được nhóm lại trong Nhóm phí, do
đó, đối với các ví cụ thể, bạn có thể xác định các khoản phí không chuẩn. Có thể
tùy chọn chỉ định ví cho một Nhóm phí cụ thể, thay vì sử dụng Nhóm phí mặc định
của công ty con.
Fee Definitions : Các tham số sau được sử dụng để xác định xem Định
nghĩa phí có áp dụng cho một ngữ cảnh nhất định hay không:
Fee Definitions : Mô-đun phí cung cấp các định nghĩa phí xác định cách
tính phí cho một ngữ cảnh nhất định. Các tham số sau được sử dụng để xác định
xem Định nghĩa phí có áp dụng cho một ngữ cảnh nhất định hay không:
 Công ty con - nếu được thiết lập, phí sẽ chỉ áp dụng cho các ví / tài khoản
thuộc về công ty con nhất định
 Nhóm phí - nếu được đặt, phí sẽ chỉ áp dụng khi ví / tài khoản thuộc Nhóm
phí nhất định
 Loại tùy chỉnh - nếu được đặt, phí sẽ chỉ áp dụng cho các giao dịch với loại
tùy chỉnh đã cho (là một điểm mở rộng)
 Bối cảnh phí - xác định bối cảnh giao dịch mà phí áp dụng, ví dụ: tài trợ một
ví tiền. Tập hợp các giá trị ngữ cảnh phí có thể được mở rộng để cho phép
xác định phí cho các quy trình giao dịch theo sản phẩm cụ thể.
 Phạm vi số tiền - nếu được đặt, phí sẽ chỉ áp dụng cho một giao dịch trong
phạm vi số tiền nhất định
 Đơn vị tiền tệ - nếu được đặt, phí sẽ chỉ áp dụng cho các giao dịch bằng đơn
vị tiền tệ nhất định Quốc gia của ví - nếu được đặt, phí sẽ chỉ áp dụng cho ví
ở quốc gia nhất định
 Loại ví - nếu được đặt, phí sẽ chỉ áp dụng cho các ví có loại đã cho (ví dụ:
đầy đủ hoặc khách)
 Cấp độ xác minh của người dùng - nếu được đặt, phí sẽ chỉ áp dụng cho
những người dùng có cấp độ xác minh nhất định (ví dụ: chưa được xác minh
hoặc đã xác minh)
 Phương thức thanh toán - nếu được đặt, phí sẽ chỉ áp dụng cho các giao dịch
với phương thức thanh toán nhất định
 Phạm vi dấu thời gian - nếu được đặt, phí sẽ chỉ được áp dụng nếu dấu thời
gian hiện tại nằm trong phạm vi nhất định
Mỗi Định nghĩa Phí chỉ định các thông số tính phí theo cách tuyến tính (số tiền
cơ bản và tỷ lệ, với số tiền phí tối thiểu và tối đa cũng như mức phí chi tiết).
Fee calculation : FeeCalculationService lấy các thông số này và tính phí dựa
trên số tiền giao dịch. Tổng phí được xác định bằng cách cộng số phí đã tính cho
từng định nghĩa phí áp dụng. FeeCalculationService có 2 phương pháp riêng biệt:

22
  calculateFees() để tính phí, nhưng không lưu trữ bất kỳ Phiên bản Phí nào.
Điều này thường được thực hiện để xem trước các khoản phí cho một giao
dịch mà không thực sự chuẩn bị chúng để đặt trước trong mô-đun kế toán.
 calculateAndStoreFees() để tính toán các khoản phí và lưu trữ một Phiên
bản Phí cho mỗi Định nghĩa Phí được áp dụng. Điều này thường được sử
dụng khi giao dịch được xác nhận và phải được đặt trước trong mô-đun kế
toán.
Khi đặt một giao dịch trong mô-đun kế toán thông qua Trình xử lý kế toán, các
Trường hợp phí được FeeAccountingHandler sử dụng để tạo các chuyển khoản
thích hợp.
Adding a new Fee : Cần thực hiện các bước sau để thêm Phí mới, ví dụ: trong
quy trình giao dịch dành riêng cho sản phẩm (ví dụ: mua Bitcoin trong giao dịch có
tên 'ExchangeDeal'):

 Define the Fee context e.g. as 'ExchangeDeal' - this makes sure that the Fee
Definitions can be defined for this context
 Adjust the ExchangeDealService to call the
FeeCalculationService.calculateAndStoreFees() to determine the fees and
store Fee Instances, based on the following data:
o Wallet Account - the Wallet Account that the ExchangeDeal is taking
place on
o Fee context - equal to 'ExchangeDeal' here
o Transaction amount - equal to '1 Bitcoin'
o Payment method - not applicable here
 Ensure ExchangeDeal DB entity implements the
FeeInstanceOwner interface, and store the fee-amount and fee-amount-lead-
currency after calculation
 Adjust the ExchangeDealAccountingHandler to book the fees when the
ExchangeDeal reaches the appropriate state using
FeeAccountingHandler.createFeeTransfers(), which also takes care of
transferring the applicable VAT amounts to the proper accounts.
 Ensure the fee-amount is set in any applicable WalletAccountItem that
is created, so that the user is properly informed about what fees have been
applied.
 Create Fee Definitions via the Admin UI or via a DB script

2.6. Wallet and Payment Module Interaction

Module definitions : Mô-đun Wallet chịu trách nhiệm chính để xử lý tất cả

các luồng kinh doanh liên quan đến tiền tài khoản, nhưng cũng chứa các luồng
khác liên quan đến ví. Mô-đun Thanh toán chịu trách nhiệm thực hiện các quy
trình cần thiết để xử lý các giao dịch thanh toán chuyển tiền trong và ngoài lĩnh
23
vực tiền tệ thông qua các cổng thanh toán, đồng thời cung cấp phương thức thanh
toán và xử lý công cụ thanh toán.
Thuật ngữ "Dịch vụ thanh toán" được sử dụng cả trong Ví và Mô-đun thanh
toán. Trong mô-đun Wallet, Dịch vụ thanh toán chịu trách nhiệm triển khai các
quy trình nghiệp vụ để cho phép người dùng / hệ thống tăng (Đến / Nạp tiền) hoặc
giảm (Đi / Rút tiền) số dư tài khoản ví (Dịch vụ WPayment). Trong Mô-đun thanh
toán, Dịch vụ thanh toán chịu trách nhiệm xử lý các tương tác với các cổng (Dịch
vụ PPayment) thông qua bộ xử lý giao dịch.
Thuật ngữ "thanh toán" được sử dụng trong Mô-đun Wallet để đại diện cho một
quy trình làm tăng hoặc giảm số dư tài khoản ví, trong đó trong Mô-đun thanh
toán, chúng ta thường nói về "giao dịch thanh toán", thể hiện trạng thái của một
tương tác với PSP / của một giao dịch trong PSP.
High-level process: Điểm quan trọng để hiểu các hành động thanh toán và lệnh
gọi lại là suy nghĩ về chuyển đổi mô-đun. Bỏ qua các chi tiết, quá trình này rất đơn
giản:
 Dựa trên nhu cầu giao dịch kinh doanh, mô-đun Wallet hướng dẫn Phân hệ
thanh toán thực hiện giao dịch thanh toán trực tiếp hoặc thông qua hành
động thanh toán (các mũi tên màu xanh lam).
 Mô-đun Thanh toán thông báo cho mô-đun Wallet về thay đổi đối với giao
dịch thanh toán và mô-đun Wallet sẽ xử lý thay đổi này thông qua một lệnh
gọi lại thanh toán (các mũi tên màu đỏ).
Các mô-đun khác có thể tương tác với mô-đun Thanh toán theo cách tương tự.
Detailed process
 Invoking the Payment module : Hiện tại, có hai cách có thể để hướng dẫn
mô-đun Thanh toán xử lý giao dịch thanh toán: Một dịch vụ ví gọi cam kết
dịch vụ phiên thanh toán, trong đó dịch vụ phiên có thể gọi trực tiếp Dịch vụ
PPayment (mũi tên màu xanh lam đậm) Một dịch vụ ví tạo mục nhập hành
động thanh toán trong cơ sở dữ liệu, sẽ được xử lý bởi công việc mô-đun ví
và sau đó gọi Dịch vụ PPayment mà không có phiên (mũi tên màu xanh
nhạt), Mục đích của dịch vụ phiên thanh toán chủ yếu là cải thiện trải
nghiệm của người tiêu dùng trong bất kỳ luồng thanh toán nào mà người
dùng đang trải qua, cho phép tổng quan về phương thức thanh toán và xử lý
công cụ thanh toán. Liên quan đến điều này, một cam kết phiên thanh toán
có thể được chuyển trực tiếp đến cổng chịu trách nhiệm, không có công việc
thanh toán / hành động ở giữa. Nó được thực hiện trong các trường hợp yêu
cầu phản hồi trực tiếp kết quả cổng cho người tiêu dùng (UX đẹp hơn, tránh
lưu trữ dữ liệu quan trọng như CVV, hỗ trợ luồng OTP, ...) và nếu không có
quy trình phê duyệt có thể. Điều đó về cơ bản chỉ đúng với tiền đến (Thế
24
 giới thực-> Góc độ ví). Mục đích của Hành động thanh toán là cải thiện
hiệu suất và tách thời gian phản hồi lệnh gọi API của quy trình kinh doanh
liên quan khỏi lệnh gọi PSP bên ngoài. Các dịch vụ kinh doanh (ví) sẽ chỉ
tạo một mục nhập cơ sở dữ liệu đại diện và việc xử lý hành động thanh toán
này sẽ được thực hiện bởi một công việc. Trong quá trình xử lý hành động
thanh toán, mô-đun Wallet gọi trực tiếp Dịch vụ PPayment mà không cần
Dịch vụ phiên thanh toán, vì không có tương tác của người dùng sẽ yêu cầu
thêm bất kỳ đầu vào nào.
 Handling payment transaction changes : Trong cả hai trường hợp, sau khi
lệnh gọi cổng trong mô-đun Thanh toán đã được xử lý, sẽ có một cuộc gọi
đến nhà xuất bản giao dịch thanh toán để công bố thay đổi giao dịch thanh
toán với trạng thái được cung cấp bởi cổng (thành công / đang chờ xử lý /
thất bại / không xác định) cho tất cả người nghe giao dịch thanh toán đã
đăng ký. Việc triển khai trình xử lý giao dịch thanh toán mặc định trong mô-
đun Wallet đang sử dụng xử lý không đồng bộ dựa trên công việc, như đối
với các hành động thanh toán. Việc triển khai sản phẩm cũng phải làm như
vậy. Điều đó có nghĩa là, thay vì trực tiếp kích hoạt các quy trình nghiệp vụ
trong mô-đun Wallet để phản ứng về thay đổi giao dịch thanh toán, sẽ có
một lệnh gọi lại thanh toán mới được ghi vào cơ sở dữ liệu. Một công việc
sẽ nhận các lệnh gọi lại đang chờ xử lý và xử lý chúng bằng cách sử dụng
triển khai theo trình nghe. Logic nghiệp vụ được đề cập thường sẽ là một số
loại thuật toán đối sánh, để gán giao dịch thanh toán cho đúng đối tượng
kinh doanh (ví, mua hàng, ...) và áp dụng logic của quy trình liên quan dựa
trên trạng thái giao dịch thanh toán (ví dụ: tạo một loại Thanh toán Đến để
ghi có vào tài khoản ví trong trường hợp trạng thái giao dịch Mua hàng và
thanh toán "thành công").
Diagram with flow description
1.1 Khách hàng gọi một API đang triển khai một dịch vụ giao dịch kinh doanh
yêu cầu một giao dịch thanh toán
1.2. Khách hàng gọi trực tiếp API của WPaymentService (ví dụ: g. Nạp tiền /
Rút tiền)
2.1 Cả giao dịch kinh doanh và dịch vụ thanh toán cần phải cam kết phiên thanh
toán nếu được sử dụng
2.2 Trong trường hợp không có cam kết phiên thanh toán nào với cuộc gọi Dịch
vụ PPayment trực tiếp hoặc không có phiên thanh toán nào, một hành động
thanh toán sẽ được tạo

25
3.1 Trong trường hợp một hành động thanh toán đã được sử dụng, công việc xử
lý sẽ gọi bộ xử lý hành động thanh toán cũng gọi hoạt động Dịch vụ PPayment
như được xác định bởi hành động thanh toán
3.2 Trong trường hợp một phiên thanh toán đã được cam kết và đó là tiền đến,
hoạt động tương ứng của Phiên thanh toán sẽ được gọi (Auth / capture / ..)
4. Định tuyến giao dịch thanh toán nội bộ đến bộ xử lý giao dịch thanh toán có
trách nhiệm chứa thông tin về giao dịch và cổng
5. Bộ xử lý ủy quyền cho cổng thanh toán
6. Bộ xử lý gọi điện cho nhà xuất bản giao dịch thanh toán để thông báo về
trạng thái nhận được từ cổng
7. Nhà xuất bản gọi tất cả người nghe giao dịch thanh toán đã đăng ký
8. Tích hợp trình xử lý giao dịch thanh toán trong mô-đun Wallet tạo mục nhập
db gọi lại thanh toán
9. Công việc gọi lại thanh toán đọc các lệnh gọi lại thanh toán đang chờ xử lý
và yêu cầu xử lý
10. Trình xử lý giao dịch thanh toán ví ủy quyền cho trình xử lý thay đổi giao
dịch thanh toán. Những người xử lý này có trách nhiệm triển khai logic nghiệp
vụ thực tế sẽ kết thúc (hoặc không thành công) giao dịch kinh doanh.

26
 Asynchronous payment execution mode
Các lợi ích chính của việc thực hiện thanh toán không đồng bộ là:
 Khả năng mở rộng tốt hơn: không có kết nối cơ sở dữ liệu nào được sử dụng
trong khi chờ kết quả cổng thanh toán (thường liên quan đến việc gọi một
dịch vụ từ xa, chẳng hạn như PSP)
 Điều chỉnh PSP tốt hơn: có một số luồng giới hạn chịu trách nhiệm cho việc
gọi cổng thanh toán, do đó ngăn chặn quá tải cổng thanh toán
 Mạnh mẽ hơn: các dịch vụ từ xa hoạt động sai (ví dụ: mất> 5 giây để phản
hồi) có tác động hạn chế đến CoreWallet
o Tối đa số luồng không đồng bộ tối đa bị chiếm dụng (cộng với bất kỳ
luồng yêu cầu API đang chờ nào)
o Không có kết nối cơ sở dữ liệu nào bị chiếm dụng

Những nhược điểm chính là:

 Có nhiều tương tác cơ sở dữ liệu hơn, bởi vì những gì từng là một giao dịch
cơ sở dữ liệu bây giờ là một vài giao dịch cơ sở dữ liệu riêng biệt. Tuy
nhiên, độ trễ của cơ sở dữ liệu thường thấp hơn nhiều so với độ trễ của PSP
và có thể được kiểm soát chặt chẽ hơn.
 Trong quá trình thực hiện thanh toán, không có khóa cơ sở dữ liệu độc
quyền trên thực thể nữa, do đó, các điều kiện chủng tộc phải được xử lý theo
cách khác (ví dụ: trạng thái thực thể mới).
 Có một số trường hợp biên giới bổ sung cần xem xét, ví dụ như trường hợp
JVM-crash trong quá trình thực hiện thanh toán. Tuy nhiên, điều này cũng
đúng với việc thực hiện thanh toán đồng bộ, trong đó toàn bộ giao dịch cơ sở
dữ liệu sẽ quay trở lại, về cơ bản bỏ qua trường hợp biên giới hoàn toàn.

Các phương thức sau có tham số chế độ thực thi để thực thi đồng bộ hoặc
không đồng bộ:

 PaymentSessionService
o cam kết
 PaymentService
o ủy quyền
o AuthozeOrPreauthorize
o ủy quyền trước
o chiếm lấy
o đảo ngược
o Hoàn tiền
o tín dụng

Trình thực thi không đồng bộ có thể được định cấu hình bằng cách sử dụng các
thuộc tính sau:

27
  trimplement.wallet.server.payment.impl.async.taskExecutor.maxPoolSize -
để xác định số luồng tối đa xử lý việc thực hiện thanh toán không đồng bộ;
mặc định là 20
 trimplement.wallet.server.payment.impl.async.taskExecutor.queueCapacity -
để xác định số lượng tác vụ không đồng bộ tối đa trong hàng đợi được thực
thi; mặc định là 1000

Nếu tất cả các luồng thực thi không đồng bộ bị chiếm, thì các tác vụ sẽ được
đưa vào một hàng đợi thực thi tác vụ. Nếu hàng đợi đầy, thì việc thực hiện thanh
toán bị từ chối / thất bại trực tiếp.
Payment.confirm / Purchase.confirm thường được cấu trúc như sau:
1. Chuẩn bị trong giao dịch cơ sở dữ liệu
 Đặt trạng thái thực thể thành ConfirmInProgress để ngăn các hoạt động
song song
 Gọi PaymentSession.commit để bắt đầu thực thi ở chế độ không đồng bộ
2. Chờ thanh toán-thực hiện-hoàn tất mà không có giao dịch cơ sở dữ liệu
3. Xử lý thanh toán-thực hiện-kết quả trong giao dịch cơ sở dữ liệu
 Khi thành công, hãy cập nhật trạng thái thực thể thành Đã xác nhận
 Nếu có lỗi, hãy cập nhật trạng thái thực thể thành Đã tạo

Cân nhắc về sản phẩm

Khi một Sản phẩm cung cấp triển khai riêng cho Thanh toán / Mua hàng. Xác
nhận, họ nên tuân thủ những điều sau:
 Không gói toàn bộ phương pháp trong một giao dịch cơ sở dữ liệu
 Phương pháp phải tuân theo các nguyên tắc tương tự như đã nêu ở trên về
kết quả chuẩn bị / cuộc gọi / quá trình
Khi một Sản phẩm cung cấp triển khai PaymentGateway, nó phải tuân theo
những điều sau:
 Không nên cho rằng bất kỳ giao dịch cơ sở dữ liệu nào tồn tại trong cuộc gọi
PaymentGateway
 Nó có thể tương tác với cơ sở dữ liệu trong giao dịch cơ sở dữ liệu của chính
nó, nhưng nó không nên  thực hiện giao tiếp từ xa trong khi giao dịch cơ sở
dữ liệu đang hoạt động

Việc tuân theo các nguyên tắc này đảm bảo một hệ thống ổn định và có thể mở
rộng, ngay cả với các kết nối cơ sở dữ liệu hạn chế.
Ví dụ: một thử nghiệm tải với 75 người dùng đồng thời, thời gian phản hồi PSP
là 5 giây và 20 luồng thanh toán không đồng bộ dẫn đến nhiều nhất 14 kết nối cơ
sở dữ liệu được sử dụng, vì không có sự chờ đợi nào chiếm bất kỳ kết nối cơ sở dữ
liệu nào.

28
2.7. User Module

Các mô-đun tài khoản  chứa các cấu trúc và quy trình quản lý dữ liệu của người
dùng, KYC-xử lý và xác minh quá trình cho dữ liệu người dùng khác nhau, chẳng
hạn như địa chỉ email, điện thoại, số lượng, địa chỉ, ngày tháng năm sinh, mã quốc
gia, vv
 user.api  - chứa API nội bộ cho mô-đun Người dùng
 user.impl  - chứa phần triển khai cho mô-đun Người dùng

User: Người dùng  đại diện cho một pháp nhân khách hàng là đối tác hợp
đồng hợp pháp cho Công ty con. Người dùng cũng thường là chủ sở hữu của một
chiếc ví. Người dùng có các thuộc tính sau đây có thể được lưu trữ trong cơ sở dữ
liệu:
 ID
 birth country
 birth place
 citizenship
 creation datetime
 date of birth
 display name
 first name
 gender
 invited by
 IP address
29
  is on watch list flag
 language
 last name
 nation code
 occupation
 personal number
 primary address ID
 primary email ID
 primary phone ID
 registration source
 source of income
 status
 subsidiary ID
 verified address flag
 verified bank account flag
 verified birth place flag
 verified citizenship flag
 verified date of birth flag
 verified email flag
 verified gender flag
 verified identification document flag
 verified name flag
 verified nation code flag
 verified personal number flag
 verified phone flag
 verification level
Chỉ có một số trường là bắt buộc (không thể null trong cơ sở dữ liệu), ví dụ:
ngày giờ tạo, ngôn ngữ, mã quốc gia, trạng thái, ID công ty con. ID công ty con và
mã quốc gia là quan trọng nhất, vì các thông số cấu hình quan trọng cho các quy
trình kinh doanh như quy trình xác minh KYC bị ràng buộc với các trường này
Identifier : Mỗi Người dùng  có thể có từ 1 đến n Số nhận dạng  có thể được sử
dụng để xác thực người dùng. Một định danh  có các thuộc tính sau đó có thể được
lưu trữ trong cơ sở dữ liệu:
 identifier (value of the identifier)
 scope (a reference to the identifier scope)
 creation datetime
 identifier type (e.g. email or phone)

30
  user ID (a reference to the user)
Identifier scope : Mọi Mã định danh  thuộc phạm vi Số nhận dạng và Mã định
danh  phải là duy nhất trong phạm vi này. Một phạm vi định danh  có các thuộc
tính sau đó có thể được lưu trữ trong cơ sở dữ liệu:
 ID
 creation datetime
 display email address (as entered by the user)
 email address (normalized)
 standard flag
 status (e.g. Active)
 newsletter subscription status (Subscribed/Unsubscribed)
 verified flag
 user ID (reference to a user)
Phone : Mỗi Người dùng  có thể có từ 1 đến n Điện thoại  có thể được sử dụng
cho mục đích liên lạc và trong các quy trình KYC (xem mô tả về các quy trình
KYC bên dưới). Một điện thoại luôn được đánh dấu là chính (tiêu chuẩn), điện
thoại này được sử dụng theo mặc định để gửi SMS cho người dùng. Một người
dùng có thể có một hoặc nhiều điện thoại đã được xác minh. Ngay sau khi ít nhất
một điện thoại được xác minh, cờ điện thoại đã xác minh của người dùng cũng
được bật. Một điện thoại  có các thuộc tính sau đó có thể được lưu trữ trong cơ sở
dữ liệu:
 ID
 creation datetime
 display phone number (as entered by the user)
 phone number (normalized)
 standard flag
 status (e.g.  Active)
 verified flag
 user ID (a reference to the user)
Address : Mỗi Người dùng  có thể có từ 1 đến n Địa chỉ  có thể được sử dụng
cho mục đích giao tiếp và trong các quy trình KYC (xem mô tả về các quy trình
KYC bên dưới). Một địa chỉ luôn được đánh dấu là chính (tiêu chuẩn), địa chỉ này
nên được sử dụng theo mặc định, chẳng hạn như để gửi thư giấy cho người dùng.
Người dùng có thể có một hoặc nhiều địa chỉ đã được xác minh. Ngay sau khi ít
nhất một địa chỉ được xác minh, cờ địa chỉ đã xác minh của người dùng cũng được
bật. Một Địa chỉ  có các thuộc tính sau đó có thể được lưu trữ trong cơ sở dữ liệu:
 creation date time
31
  first name (of the recipient, might be different from the user’s first name)
 last name (of the recipient, might be different from the user’s last name)
 display name (of the recipient, might be different from the user’s display
name)
 address line 1
 house number
 address line 2
 district
 city
 province
 country
 zip
 standard flag
 verified flag
 type (SHIPPING / BILLING / STANDARD)
 user ID (reference to the user)
IdDocument : Mỗi Người dùng  có thể có từ 1 đến n Tài liệu nhận dạng  mà
anh ta có thể tải lên để đăng ký xác minh KYC. Thông thường những giấy tờ này
là bản sao của thẻ căn cước hoặc hộ chiếu do chính phủ cấp để chứng minh danh
tính và các hóa đơn tiện ích gần đây để chứng minh nơi cư trú. Một IdDocument
có các thuộc tính sau đó có thể được lưu trữ trong cơ sở dữ liệu:
 ID
 creation datetime
 file name (generated by the system)
 file path
 file content type
 file size bytes
 original file name
 status (Accepted/Created/Rejected/Revoked)
 status change datetime
 status text
 qualifier (free text field e.g. identification document, utility bill)
 verified flag
 expiration date (where applicable)
 purpose
 user ID (reference to the user)
InternalDocument : Mỗi Người dùng  có thể có từ 1 đến n Tài liệu nhận dạng
mà anh ta có thể tải lên để đăng ký xác minh KYC. Thông thường những giấy tờ
32
này là bản sao của thẻ căn cước hoặc hộ chiếu do chính phủ cấp để chứng minh
danh tính và các hóa đơn tiện ích gần đây để chứng minh nơi cư trú. Một
IdDocument  có các thuộc tính sau đó có thể được lưu trữ trong cơ sở dữ liệu:
 ID
 creation datetime
 comment (employee/admin comment)
 file content type,
 file name (generated by the system)
 file path
 file size bytes
 original file name
 qualifier (free text field)
 status (Created/Deleted)
 status datetime
 user ID (reference to the user)
VerificationHistory : Mỗi Người dùng  có thể có 1 đến n Tài liệu Nội bộ  mà
quản trị viên có thể tải lên cho người dùng. Những tài liệu này không thể được sử
dụng trong quy trình xác minh KYC của dữ liệu người dùng và chỉ được lưu trữ để
lưu giữ lịch sử giao tiếp hoặc để lưu trữ thông tin bổ sung về người dùng. Tài liệu
Nội bộ  có các thuộc tính sau đây có thể được lưu trữ trong cơ sở dữ liệu:
 ID
 user attribute (e.g. EMAIL / PHONE / NATIONCODE / NAME and so on)
 creation datetime
 verification item id (ID of the IdDocument which was used for verification if
applicable)
 verfiied item ID (database ID of the verified item, e.g. address, email or
phone if applicable)
 verified value (verified value as string or JSON string)
 user ID (reference to the user)
UserDataUpdate : Đối với mục đích tài liệu và khả năng kiểm tra, lịch sử cập
nhật dữ liệu cho mỗi Người dùng   được lưu trong bảng đặc biệt, nơi có thể lưu trữ
các thuộc tính sau:
 ID
 creation datetime
 item ID (database ID of the updated item, e.g address, email, phone if
applicable)
 status (created, canceled, verification_needed, applied)
33
  update action (add, update, delete)
 update display value (value as entered by the user)
 update time
 update type
 update value (normalized value)
 user ID (reference to the user)

Hình 10. Biểu đồ hoạt động nạp tiền vào ví điện tử

Luồng hoạt động:
Bước 1: Đăng nhập và lựa chọn nạp tiền vào Tài khoản ví điện tử của Tổ
chức trung gian thanh toán
 Khách hàng đăng nhập vào ứng dụng của Tổ chức trung gian thanh toán;.
 Lựa chọn tính năng nạp tiền vào Tài khoản ví điện tử của Tổ chức trung gian
thanh toán.
Bước 2: Ví hiển thị màn hình thông tin nạp tiền vào ví điện tử. Lựa chọn ngân
hàng đã liên kết để nạp tiền vào Tài khoản ví điện tử của Tổ chức trung gian thanh
toán.

34
 Bước 3: Nhập thông tin nạp tiền vào Tài khoản ví điện tử của Tổ chức trung
gian thanh toán
 Khách hàng nhập số tiền cần nạp vào Tài khoản ví điện tử của Tổ chức trung
gian thanh toán.
 Nhập mật khẩu thanh toán (PIN hoặc xác thực sinh trắc học của khách
hàng).
 Thông tin xác thực này lưu tại hệ thống của Tổ chức trung gian thanh toán.
Bước 4: gửi thông tin nạp tiền: Số tiền cần nạp
 Mật khẩu thanh toán (PIN hoặc xác thực sinh trắc học của khách hàng)
Trước khi gửi thông tin thì xác thực PIN hoặc xác thực sinh trắc học của
khách hàng: Mật khẩu được coi là hợp lệ là mật khẩu khách hàng nhập trùng
với mật khẩu khách hàng thiết lập và đăng ký với Tổ chức trung gian thanh
toán đang có hiệu lực tại thời điểm thực hiện xác thực mật khẩu.
 Nếu mật khẩu của khách hàng không hợp lệ, ứng dụng của Tổ chức trung
gian thanh toán thông báo lỗi tới khách hàng.
 Nếu số tiền khách hàng nhập vượt quá số tiền quy định 1 lần nạp hoặc quá
số tiền chuyển trong 1 ngày, ứng dụng của Tổ chức trung gian thanh toán
thông báo lỗi tới khách hàng;
 Nếu Mật khẩu của khách hàng hợp lệ, Hệ thống của Tổ chức trung gian
thanh toán chuyển thông tin tới ngân hàng. Thông tin gửi tới ngân hàng bao
gồm: Thông tin về liên kết thẻ (Mã ID duy nhất đã liên kết giữa Tài khoản ví
điện tử của Tổ chức trung gian thanh toán với ngân hàng), Số tiền cần nạp
tiền vào Tài khoản ví điện tử của Tổ chức trung gian thanh toán.
Bước 5: Xác thực thông tin khách hàng:
 Nếu mã ID duy nhất của khách hàng không tồn tại, ngân hàng trả thông báo
lỗi gửi tới Tổ chức trung gian thanh toán, Tổ chức trung gian thanh toán
thông báo tới Khách hang.
 Nếu trạng thái liên kết là InActive (ví gắn với thẻ ngân hàng ở trạng thái
InActive), ứng dụng của Tổ chức trung gian thanh toán hiển thị thông báo
lỗi tới khách hang.
 Nếu số tiền khách hàng nhập vượt quá hạn mức tối đa hoặc thấp hơn số tiền
tối thiểu quy định 1 lần nạp hoặc quá số tiền chuyển trong 1 ngày, ngân hàng
trả về kết quả lỗi cho Tổ chức trung gian thanh toán , Tổ chức trung gian
thanh toán thông báo lỗi tới khách hang.
 Nếu thông tin hợp lệ
o Gửi thông tin sang Tổ chức trung gian thanh toán , ứng dụng của Tổ chức
trung gian thanh toán yêu cầu khách hàng nhập mã OTP.
o Gửi mã OTP tới khách hàng.

35
 Bước 7: Khách hàng nhập mã OTP:
 Nhập mã OTP mà ngân hàng gửi.
 Xác nhận thanh toán trên ứng dụng của Tổ chức trung gian thanh toán.
 Tổ chức trung gian thanh toán chuyển tiếp thông tin sang ngân hàng để xác
thực OTP
Bước 8 : Xác thực mã OTP.
Bước 9 : Hạch toán.
Bước 10: Tổ chức trung gian thanh toán cộng tiền vào Tài khoản ví điện tử cho
khác hàng:
 Nếu Tổ chức trung gian thanh toán cộng tiền thành công, thông báo tới
khách hàng.
 Nếu Tổ chức trung gian thanh toán cộng tiền không thành công:
o Gửi thông báo lỗi tới khách hàng.
o Gửi thông báo lỗi cộng tiền sang ngân hàng, ngân hàng thực hiện hoàn
tiền lại cho khách:

2.8. Cơ chế bảo vệ app ví điện tử

SSL Pinning - SSL được pin sẵn vào trong Application

Đầu tiên phải nói về Secure Web Connections:
Khi Client bắt đầu 1 Secure session với Server, có 3 điều hai bên phải thống nhất:
- How keys be exchange - Làm sao để trao đổi các key cho nhau?
- How will data be encrypted - Dữ liệu được mã hóa theo cách nào ?
- How will messages be marked as authentic - Như thế nào thì messages được
đánh dấu là xác thực ?
Ví dụ Server có thể quyết định rằng sẽ sử dụng RSA để trao đổi keys, dùng AES
256 để encrypt data và SHA-1 để sign messages.
Nếu Client có support các loại trên, nó sẽ request một certificate chain từ Server,
khi client đã xác nhận certificate chain, public key sẽ được trích xuất từ certificate.

36
Theo mặc định, việc triển khai SSL được sử dụng trong các App sẽ tin tưởng bất
kỳ Server nào có certificate được tin cậy bởi OS ( như hình trên ). Đó là một danh
sách các CA ( certificate authorities ) có sẵn trong OS.
Đây là lúc SSL Pinning phát huy tác dụng. Developers có thể compile (biên dịch)
public key vào trong application code, điều này về cơ bản là pinned key vào ứng
dụng. Khi máy client nhận được public key từ Server, nó sẽ so sánh key này với
key được pinned trong ứng dụng. Nếu key đúng, sẽ khởi tạo sessions.

37
Hiện nay có 3 loại SSL Pinning:
- Certificate Pinning
- Public Key Pinning ( Là loại được đề cập ở phía trên )
- SPKI Pinning
Certificate Pinning: Đây là phương pháp pinning toàn bộ certificate thay vì chỉ
pinning public key và cũng là phương pháp dễ thực hiện nhất. Vậy sẽ ra sao khi
certificate expires ( hết hạn ) ? Client sẽ phải update application với certificate mới
trước khi certificate trên Server được update. Vì vậy đôi khi Public key pinning là
phương thức được ưa chuộng hơn.
Public key pinning: Linh hoạt hơn nhưng phức tạp hơn một chút do cần các
bước bổ sung để trích xuất public key từ certificate.
SPKI Pinning ( Subject Public Key Information ): là phương thức pinning mới
nhất, hash của public key và meta-data được pin vào trong ứng dụng.
Nếu ứng dụng không sử dụng SSL Pinning, sẽ rất dễ bị tấn công Man-in-the-
Middle.

Như vậy SSL Pinning giúp Developers có thêm một lớp bảo mật bổ sung trong
ứng dụng của họ và rất dễ thực hiện với các thư viện như AF Networking ( với iOS
) hay OkHTTP ( với Android ).

38
Lý do phải bypass cái này vì chúng ta sẽ dựng proxy server để chặn bắt request từ
App gửi lên Server, mà Server và App lại chỉ nói chuyện khi có đúng Cert mà
thôi...
Anti VM - Không cho phép cài đặt / sử dụng trên thiết bị ảo hóa.
Đơn giản thì đây là cách thức để Application phát hiện thiết bị có phải là thiết bị ảo
hóa ( emulator ) hay không, nếu có thì các tính năng sẽ hạn chế hoặc không cho
phép cài đặt.
Tại sao việc pentest Application trên emulator vẫn được sử dụng ? Đơn giản vì nó
tiện hơn, mọi thiết bị, mọi phiên bản android...chỉ cần chọn và install, sau 5 phút
bạn đã có ngay 1 thiết bị android emulator với đầy đủ chức năng. Ứng dụng tạo
emulator device được biết đến và sử dụng phổ biến hàng đầu là Genymotion.

Cách Application detect ra thiết bị là emulator cũng muôn hình vạn trạng. Đây là
một ví dụ:

Code tường minh như thế này thì chẳng có lý do gì không bypass được cả, có thể
modify string như sau:

39
Như vậy là function trên đã "vô hại" và application có thể cài đặt được trên
emulator.
Root Detection Techniques
Nếu việc Anti VM không có vẻ gì là đau đớn lắm vì có thể dễ dàng dùng thiết bị
thật thay thế , thì việc "anti rooted device" lại là một câu chuyện khác. Vì dù là
thiết bị thật hay emulator, tất cả đều phải rooted, do có liên quan tới rất nhiều vấn
đề khi pentest.
Đây là ví dụ về một đoạn script để detect Root theo 3 cách khác nhau. Đương
nhiên vẫn còn có những cách khác và những binary khác hỗ trợ cho việc này.
/** @author Kevin Kowalewski */
public class RootUtil {
public static boolean isDeviceRooted() {
return checkRootMethod1() || checkRootMethod2() ||
checkRootMethod3();
}

private static boolean checkRootMethod1() {

String buildTags = android.os.Build.TAGS;
return buildTags != null && buildTags.contains("test-keys");
}

private static boolean checkRootMethod2() {

String[] paths = { "/system/app/Superuser.apk", "/sbin/su",
"/system/bin/su", "/system/xbin/su", "/data/local/xbin/su",
"/data/local/bin/su", "/system/sd/xbin/su",
"/system/bin/failsafe/su", "/data/local/su", "/su/bin/su"};
for (String path : paths) {
if (new File(path).exists()) return true;
}
return false;
}

private static boolean checkRootMethod3() {

40
 Process process = null;
try {
process = Runtime.getRuntime().exec(new String[] {
"/system/xbin/which", "su" });
BufferedReader in = new BufferedReader(new
InputStreamReader(process.getInputStream()));
if (in.readLine() != null) return true;
return false;
} catch (Throwable t) {
return false;
} finally {
if (process != null) process.destroy();
}
}
}
Khi tìm hiểu Mobile Device Management (MDM), có rất nhiều cách để detecting
thiết bị Android đã root. Những phương thức khá giống nhau và thường liên quan
tới việc tìm kiếm package hoặc file cụ thể nào đó, hoặc quyền thư mục và chạy các
lệnh nhất định.
Thông qua việc review source code, pentester có thể modify lại như ví dụ ở trên và
nhiều hướng dẫn khác để bypass việc detect root, kể cả khi Safetynet - API chính
chủ Google, chuyên để chống người dùng đã root, mở khoá bootloader hoặc cài
bản custom ROM sử dụng Android Pay được sử dụng.
Code Obfuscation
Đây là kỹ thuật được thêm vào khi sản phẩm chuẩn bị được publish. Nhằm giữ cho
source code không thể đọc hiểu được bởi bên thứ ba. Một ví dụ cơ bản về việc
Code Obfuscation của một ứng dụng

41
Đây là một kỹ thuật cần thiết và quan trọng. Tuy nhiên việc Obfuscation Code có
ảnh hưởng đến performance của App và 1 số vấn đề liên quan. Thành ra ở ví dụ
thứ 2 kia, dù đây là application in-house của một công ty chuyên về Software
nhưng việc Obfuscation Code không được áp dụng.

ViettelPay

Tổng quan

ViettelPay là gì?
ViettelPay là ứng dụng thanh toán di động được phát triển bởi Viettel, giúp
cho các thuê bao khi đăng ký dịch vụ có thể thực hiện nạp tiền, chuyển tiền, thanh
toán tiền điện nước, mua vé máy bay, tàu hỏa,... một cách nhanh chóng và an toàn.
Khách hàng có thể đăng ký sử dụng dịch vụ ViettelPay dù đang sử dụng thuê bao
di động của bất kỳ nhà mạng nào tại Việt Nam.

Các tính năng nổi bật của ViettelPay

Một số tính năng nổi bật mà bạn có thể sử dụng khi đăng ký ViettelPay như:

42
Thanh toán ngân hàng
+ Miễn phí 100 triệu đồng/tháng hoặc 30 giao dịch/tháng với các giao dịch chuyển
khoản như chuyển tiền qua số tài khoản, số thẻ ngân hàng, số điện thoại (tùy vào
điều kiện nào đến trước).

Nếu vượt qua 1 trong 2 điều kiện, mức phí được áp dụng theo công thức 0,1%*Giá trị
GD. Để xem thêm các biểu phí giao dịch khác.
+ Nhận được tiền mặt sau 2 giờ chuyển tiền trên toàn quốc.
+ Dễ dàng nạp, rút tiền khi có gần 200.000 điểm giao dịch Viettel trên toàn quốc.

Thanh toán dịch vụ

+ Hỗ trợ thanh toán hóa đơn tiền điện trên 63 Tỉnh/Thành phố, tiền nước 17
Tỉnh/Thành phố.
+ Thanh toán bảo hiểm, giáo dục, chi phí tài chính (Home Credit, FE Credit,...)
Dịch vụ khác
+ Thanh toán các dịch vụ, mua sắm bằng mã QR Code.
+ Hỗ trợ đặt phòng khách sạn, mua vé xem phim, mua vé máy bay, tàu hỏa,...

Kiến trúc

43
Xác thực đa yếu tố

SMS OTP

https://abenla.com/dich-vu-sms-otp-la-gi-tai-sao-can-phai-trien-khai-sms-otp/

Tổng quan
Một công nghệ phổ biến được sử dụng để gửi OTP là nhắn tin văn bản. Bởi
vì tin nhắn văn bản là một kênh giao tiếp phổ biến, có sẵn trực tiếp trên hầu hết các
thiết bị di động và thông qua chuyển đổi văn bản thành giọng nói, cho bất kỳ điện
thoại di động hoặc điện thoại cố định nào, nên nhắn tin văn bản có tiềm năng lớn
để tiếp cận tất cả người tiêu dùng với tổng chi phí thấp thực hiện.
SMS OTP (Short Message Service One Time Password) là tin nhắn từ hệ
thống gửi về điện thoại mã xác thực, nó là một dãy số hoặc một chuỗi kết hợp cả
số với ký tự. Nhưng khác mật khẩu thông thường, mã xác thực OTP được tạo ra
ngẫu nhiên không phải từ người dùng, chỉ sử dụng được một lần và sau đó không
còn tác dụng. Thậm chí, thời hạn của mật khẩu OTP thường rất ngắn, có thể chỉ
sau 30 giây, 60 giây hay một vài phút, nó sẽ vô tác dụng và lại được thay thế bằng
một mã mới.
Dịch vụ SMS OTP được sử dụng nhiều và rất phổ biến. Để chuyển tiền hay
thực hiện một giao dịch trực tuyến, người dùng không chỉ dùng tài khoản và mật
khẩu để đăng nhập mà còn cần nhập đúng mã xác thực OTP được gửi bằng hình
thức SMS mới hoàn tất được giao dịch.

44
 Dịch vụ SMS OTP là cách xác thực hai yếu tố bổ sung thêm một lớp bảo
mật cho thủ tục đăng nhập, cải thiện đáng kể tính bảo mật của trang web, ứng dụng
hoặc phần mềm. Ngay cả khi thông tin email và mật khẩu được truy cập, dữ liệu
trực tuyến sẽ vẫn được SMS OTP bảo vệ.
Các thuật toán tạo OTP thường sử dụng tính ngẫu nhiên hoặc ngẫu nhiên giả
để tạo khóa chia sẻ hoặc hạt giống và các hàm băm mật mã, có thể được sử dụng
để lấy giá trị nhưng rất khó để đảo ngược và do đó kẻ tấn công khó lấy được dữ
liệu được sử dụng cho băm. Điều này là cần thiết vì nếu không, sẽ dễ dàng dự đoán
các OTP trong tương lai bằng cách quan sát các OTP trước đó.
Ưu điểm quan trọng nhất của OTP là trái ngược với mật khẩu tĩnh, chúng
không dễ bị tấn công phát lại. Điều này có nghĩa là một kẻ xâm nhập tiềm năng
quản lý để ghi lại một OTP đã được sử dụng để đăng nhập vào một dịch vụ hoặc
để thực hiện một giao dịch sẽ không thể sử dụng nó, vì nó sẽ không còn hợp lệ. Ưu
điểm chính thứ hai là người dùng sử dụng cùng một mật khẩu (hoặc tương tự) cho
nhiều hệ thống sẽ không dễ bị tấn công trên tất cả chúng, nếu mật khẩu của một
trong những hệ thống này bị kẻ tấn công lấy được. Một số hệ thống OTP cũng
nhằm mục đích đảm bảo rằng một phiên không thể dễ dàng bị chặn hoặc bị mạo
danh nếu không biết về dữ liệu không thể đoán trước được tạo ra trong phiên trước
đó, do đó làm giảm bề mặt tấn công hơn nữa.
Thuật toán tạo OTP
Các thuật toán OTP cụ thể khác nhau rất nhiều về chi tiết của chúng. Các cách tiếp
cận khác nhau để tạo OTP bao gồm:
- Dựa trên đồng bộ hóa thời gian giữa máy chủ xác thực và máy khách cung
cấp mật khẩu (OTP chỉ có hiệu lực trong một khoảng thời gian ngắn)
- Sử dụng một thuật toán toán học để tạo mật khẩu mới dựa trên mật khẩu
trước đó (OTP thực sự là một chuỗi và phải được sử dụng theo thứ tự được
xác định trước).
- Sử dụng một thuật toán toán học trong đó mật khẩu mới dựa trên một thử
thách (ví dụ: một số ngẫu nhiên do máy chủ xác thực hoặc chi tiết giao dịch
chọn) và / hoặc bộ đếm.

45
Mô hình hệ thống

46
Luồng hoạt động

1. Người dùng thực hiện gửi credentials đến server

2. Server thực hiện tạo OTP, lưu trữ vào database và gửi về cho phía
người dùng.
3. Người dùng nhập OTP vừa nhận từ tin nhắn vào ứng dụng và gửi lên
server.
4. Server thực hiện check OTP và xử lí yêu cầu của người dùng.
SMS OTP trong ví điện tử Viettelpay
- Chức năng chuyển tiền

47
48
USSD
Khái niệm USSD
USSD là viết tắt của Unstructured Supplementary Service Data - Dữ liệu dịch vụ
bổ sung không có cấu trúc, đôi khi được gọi là 'mã nhanh' hoặc 'mã tính năng'.
Hiểu đơn giản thì nó là một giao thức nhắn tin, tương tự như SMS mà mọi người
sử dụng hàng ngày để gửi và nhận tin nhắn nhưng bị giới hạn ở 182 ký tự.
Cũng giống như SMS, USSD ra đời trước thời đại của smartphone, khi điện thoại
cần một phương thức tương tác với nhau mà không cần đến các ứng dụng siêu hiện
đại ngày nay. 
Và thay vì truyền tải những thông tin giữa các đối tượng người dùng thì USSD có
thể giúp cho các nhà mạng và người sử dụng giao tiếp được với nhau, đáp ứng
được những yêu cầu của người sử dụng một cách nhanh chóng, đơn giản nhất qua
việc thao tác trên bàn phím USSD.
Lợi ích của USSD
2.1. USSD có độ tương tác cực cao
Trước hết, những thứ mà người dùng muốn trải nghiê ̣m đó chính là những thuâ ̣n
lợi kết hợp cùng đô ̣ nhanh chóng. Và điều này thì khỏi phải bàn cãi khi USSD
khẳng định được đây là mô ̣t trong những loại hình có tính tương tác rất cao. USSD
có thể thực hiê ̣n phản hồi các thông tin về rất nhanh so với hình thức SMS truyền
thống thông thường. Nếu bạn phải đợi đến 1 phút để nhâ ̣n các tin nhắn được gửi về
máy thông qua sms thông thường thì với USSD sự chờ đợi chỉ là vài giây ngắn
ngủi.
49
Trong khi thông tin phản hồi về rất nhanh nếu chúng ta so sánh nó với hình thức
SMS truyền thống. Bên cạnh đó, USSD còn thể hiê ̣n vị thế của mình khi liên tục
cho phép cung cấp nhiều dịch vụ khác nhau trên cùng một đầu số thuê bao riêng
biê ̣t.
2.2. Bảo mật thông tin an toàn
Ưu điểm của USSD chính là có thể tương thích được với hầu như tất cả những
thiết bị điện thoại di động trên thị trường Việt Nam cũng như trên toàn thế giới.
Ngoài ra, USSD không phụ thuộc vào bất cứ thông tin nào nên ngay từ khi trải
nghiệm lần đầu tiên, người dùng sẽ không cần phải lo lắng sẽ gặp rắc rối hay
những khó khăn, trở ngại.
Điều đặc biệt là USSD được thể hiện dưới dạng flash và người sử dụng sẽ không bị
giữ hay sao lưu lại thông tin qua các giao dịch đã thực hiện, đảm bảo được tính bảo
mật thông tin cho khách hàng. Đồng thời, bạn cũng sẽ được trải nghiệm dịch vụ
này ở bất kỳ nơi đâu mà mình muốn.
2.3. Tích hợp đa dạng nhiều dịch vụ trên một đầu số
Điều tuyê ̣t vời khi tìm hiểu về USSD đó là khám phá ra được tính năng của nó đối
với người dùng trong viê ̣c cung cấp các dịch vụ tiê ̣n ích. Phải kể đến sự hoạt đô ̣ng
và cho phép tích hợp đa dịch vụ trên một đầu số duy nhất, không chỉ thế kết hợp
với viê ̣c nâng tốc độ tương tác lên cao gấp 7 lần SMS do sự hoạt đô ̣ng và điều
chỉnh nhờ cơ chế hướng phiên session-based.
Giờ đây bạn có thể tìm hiểu những thông tin về ưu điểm của nó mang lại cho người
dùng, cũng như trải nghiê ̣m các tính năng đô ̣c đáo, mới nhất và hiê ̣n đại nhất từ
phía dịch vụ này gửi đến bạn khi dùng chiếc điê ̣n thoại của mình và có mô ̣t chiếc
sim liên lạc rồi đấy.
Đối với lần bạn thao tác về nhập thì điện thoại của người dùng sẽ có một
danh sách các dịch vụ được cung cấp cũng như hiển thị các thông tin từ trên đầu
số. Từ đó, nếu bạn đóng vai trò là người dùng và sử dụng thì có thể sử dụng dịch
vụ USSD ngay lập tức. Điều này tạo ra thuận lợi vì đối với nhiều khách hàng, vì
đâu phải lúc nào chúng ta cũng nhớ được những thông tin về cú pháp tin nhắn đâu.
Thực hiê ̣n sử dụng cung cấp từ các dịch vụ chắc chắn cho bạn nhiều thuâ ̣n lợi đến
đáng kể.

50
Cách hoạt động của USSD

Từ sơ đồ trên, một yêu cầu được gửi từ điện thoại di động đến một mạng viễn
thông.
Cổng Ussd (viễn thông) sau đó sẽ gửi yêu cầu đến ứng dụng ussd (tức là nơi có
logic nghiệp vụ xác định menu để phục vụ việc sử dụng khi nhận được yêu cầu của
người dùng.)
Ứng dụng Ussd sau đó phản hồi yêu cầu và cổng Ussd tiếp tục và hiển thị nội dung
cho người dùng
Dưới đây là một sơ đồ khác để giúp hiểu khái niệm

51
USSD trong đăng ký ví điện tử Viettelpay

Về cơ bản thì hoạt động đăng ký ví điện tử của viettelpay là các yêu cầu và phản
hồi giữa người dùng và nhà cung cấp dịch vụ thông qua cổng USSD. Đầu tiên
người dùng bấm gọi *998#. Màn hình ngay sau đó sẽ hiển thị nội dung:
Viettlpay – Dich vu Thanh toan va chuyen tien tren di dong. Chon:
1. Dang ky
2. Tong quan dich vu
3. Gioi thieu tinh nang noi bat
4. Tro giup
Đây là form để người dùng lựa chọn tính năng cần sử dụng. Người dùng bấm phím
1 và gửi đi, tương đương với yêu cầu đăng ký dịch vụ. Ứng dụng gửi lại form yêu
cầu người dùng tạo mật khẩu. Sau khi mật khẩu được nhập và gửi đi, ứng dụng
tiếp tục gửi lại một form yêu cầu xác nhận mật khẩu một lần nữa. Và cuối cùng sau
khi đặt xong mật khẩu, sẽ có một mã OTP đc gửi đến người dùng chỉ cần nhập
đúng mã OTP để xác nhận và dịch vụ sẽ được kích hoạt

52
SỬ DỤNG VIETTELPAY QUA USSD

53
54
DOTP
Tổng quan:
- Digital OTP là phương thức xác thực trực tuyến nâng cao và được tích hợp
ngay trên các ứng dụng ( app ) của 1 số ngân hàng.
- Với phương thức xác thực này mọi người cần lưu ý có sự khác biệt so với
các phương thức xác thực khác như SMS OTP hay Token OTP hiện tại.
- Sử dụng phương thức chỉ cần có kết nối Internet: Sử dụng tiện lợi khi ở
nước ngoài hay ở vùng sóng yếu.
- Bảo mật cao hơn so với các phương thức xác thực khác: Mã hóa bảo mật
nhiều tầng, bảo vệ cả app lẫn các giao dịch tài chính. Mã khóa riêng cho
từng thiết bị, ví dụ mọi người sử dụng nhiều điện thoại khác nhau hay trên
ipad sẽ có mã Digital OTP riêng.
- Với SMS OTP, khi mất điện thoại, bạn cần phải báo ngay cho ngân hàng để
khóa tạm thời tính năng này. Với Token, bạn phải luôn mang theo nó bên
mình và đặt mật khẩu có tính phức tạp và lưu giữ để phòng khi quên
- Với Digital OTP thì bạn có thêm một mã bảo vệ nữa, nhưng đây là mã bảo
vệ ứng dụng riêng cho từng thiết bị. Mỗi thiết bị bạn đăng ký sử dụng ở
ngân hàng sẽ được phép đăng nhập, nếu như tài khoản mọi người bị lộ hoặc
bị ai đó đánh cắp thì sẽ không bị sao cả.

55
Thành phần:
- Provisioning Server:
o Lưu trữ mobile tokens được tạo trong bộ nhớ an toàn ngoại tuyến để
cấp phép
o Hỗ trợ các dịch vụ web để cung cấp mobile token vào V-Tap SDK
o Các tập lệnh dòng lệnh cho các hoạt động của Máy chủ Cấp phép, ví
dụ: sao lưu / phục hồi cơ sở dữ liệu, báo cáo tóm tắt mã thông báo,
v.v.
- V-Tap Server:
o Dịch vụ Web để có được thời gian an toàn, thu thập nhật ký khắc phục
sự cố và thông tin môi trường liên quan của thiết bị từ V-Tap SDK
o Duy trì danh sách trắng / danh sách đen các thiết bị di động được V-
Tap SDK hỗ trợ / không hỗ trợ
- V-Track Server:
56
 o Hỗ trợ các dịch vụ web cho V-Guard để báo cáo các mối đe dọa di
động được phát hiện đến Máy chủ V-Track
o Duy trì các cấu hình bảo mật và cập nhật OTA của các cấu hình này
thông qua cập nhật tệp hồ sơ
- Authentication Server:
o Cơ sở dữ liệu an toàn để lưu trữ Serial Token và liên kết các seed
o Mô-đun xác thực Serial Token và OTP
Cơ chế hoạt động:
5. Người dùng nhập PIN vào ứng dụng
6. Vtap thực hiện các công việc :
 Kiểm tra đồng bộ time với server
 Kiểm tra sự tương thích của thiết bị (Thiết bị có cài các phần
mềm độc hại, thiết bị đã root,…)
 Theo dõi APP, cập nhập phần mềm, firmware
 Log các sự kiện của ứng dụng
 Kiểm tra soft token , deviceId của thiết bị.
7. Vtap thực hiện generate OTP trả về cho người dùng.
8. Người dùng sử dụng OTP vừa tạo để thực hiện các giao dịch
Luồng giao dịch
- Luồng chuyển tiền Wallet-Account

57
Luồng chuyển tiền Wallet-Wallet

58