Chương 6. Thanh toán cho các giao dịch nhỏ
6.4. Các giải pháp chính
6.4.1. Gi ải quyế t tranh ch ấp và hoàn trả
Trước hết chúng ta tập trung vào loại tranh chấp và hoàn trả phổ biến nhất (cũng là quan trọng nhất) là khi khách hàng tuyên bố rằng h ã không đồng ý giao d ch. Đểọ đ ị hiểu rõ hơn vấn đề, chúng ta xem xét cơ ch chung khi th c hi n giao dịch dùng thẻ tín dụng trên mạng Internet ế ự ệ (hoặc qua phone), bằng cách gửi thông tin thẻ tín dụng đến người bán. Thông thường thông tin về thẻ tín dụng được mã hoá SSL/TLS như được mô tả trong hình 6-5. Do việc chấp nhận thanh toán chỉ bao gồm cung cấp thông tin về số ẻ th nên b t k ai có thông tin v số ẻấ ỳ ề th có th tham ể gia giao dịch. Kết quả là có rất nhi u có r t nhi u tranh ch p liên quan ề ấ ề ấ đến thanh toán th tín ẻ
Luận Văn Cao học Ngành Công Nghệ Thông Tin - ĐH Bách Khoa Hà Nội 75 dụng trên mạng Internet. Tỷ lệ này lên cao đến n i nó t o ra nhi u thi t h i cho bên phát hành ỗ ạ ề ệ ạ thẻ; tỷ lệ này chỉ giảm khi có sự xuất hiện cơ chế phạt những người bán có nhiều tranh ch p. ấ
Hình 6-5: Thanh toán thẻ tín dụng SSL
Có nhiều cách khác nhau chính nhằm làm giảm các tranh chấp và hoàn trả liên quan đến việc phủ nhậ đã chấp nhận thanh toán của khách hàng. Trong đó hướng tiếp cận n quan tr ng nh t ọ ấ là đưa ra một quá trình xử lý việc chấp nhận thanh toán một cách an toàn. Quá trình xử lý nên tuân theo quy trình chuẩn nh sau: ư
1. Người bán trình diễn các sản phẩm và dịch vụ tới khách hàng. Trong m t k ch b n ộ ị ả duyệt thông thường, một chào hàng thường thông qua một đường dẫn siêu văn bản, gọi là trả phí theo đường dẫn (per-fee link). Ngoài ra còn có các mô tả về chào hàng có thể ằ n m cả ở trong và ngoài đường dẫn trả trả phí.
2. Thông thường, trình diện sẽ trình diễn các mô tả chào hàng hàng. Khách hàng thực hiện quá trình thanh toán đơn giản bằng cách bấm chọ đường dẫ đó. Kết quả của n n thao tác đó là việc chuyển các tham số ủ c a đường dẫn trả phí tới PSP, cung cấp đầy đủ các thông tin thanh toán.
3. Ở đ ể i m này, trong h u h t các trường h p, khách hàng đã chi trả căầ ế ợ n c vào thông ứ tin đã được mô tả trong đường dẫn trả phí. Tuy nhiên, một người bán có m c ích ụ đ xấu có thể có thể cung cấp một mô t khác v i các thông tin thanh toán tới PSP. Do ả ớ đó, PSP c n ph i xác định l i r ng khách hàng đầ ả ạ ằ ã đồng ý tr theo úng mô t . Quá ả đ ả trình này thường được thực hiện bằng việc gửi một yêu cầu xác nhận chấp nhận
Customer Merchant
Issuer Bank
Acquier Bank (or processor)
SSL encrypted
Credit Card Number
Credit Card Number
Luận Văn Cao học Ngành Công Nghệ Thông Tin - ĐH Bách Khoa Hà Nội 76 thanh toán trên một trang web. Khách hàng sau đó có thể đồng ý hay từ chối yêu cầu này.
4. Khi PSP xác nhận khách hàng đã chấp nhận thanh toán, PSP phát hành ra một hoá đơn thanh toán đã xác th c (PO) g i t i khách hàng. PO thường được xác thựự ử ớ c b i ở chữ ký của PSP hoặc sử dụng khoá chung gi a PSP và người bán. Đểữ phòng kh ả năng hoá đơn thanh toán bị “mất cắp” trên đường tới khách hàng, quá trình trao đổi thường được mã hoá sử dụng SSL.
5. Trình duyệt của khách hàng thường tự động x lý hoá đơn ã xác th c b ng cách ử đ ự ằ gửi nó tới người bán như là một yêu cầu. Nếu xử dụng m t ph n m m ví i n t , ộ ầ ề đ ệ ử phần mềm này có thể thay đổi PO trước khi gửi nó đến người bán (thêm vào chữ ký của khách hàng hoặc xác nhận hoá đơn đó).
6. Hoá đơn sau đ được kiểm định bởi người bán, kiểm tra xem có đúng xác nhận của ó PSP hay không. Việc này có thể thực hiện thông qua sử dụng m t khoá MAC, khoá ộ dùng chung giữa PSP và người bán, hoặc là chữ ký khoá công khai của PSP. Ngay khi hoá đơn thanh toán được xác nhận h p lợ ệ, người bán sẽ cung cấp hàng hoá và dịch vụ cho khách hàng.
7. Trong xử lý không trực tuyến, các xử lí lưới (xử lý “batch”) người bán đặt các hoá đơn và nhận tiền v . ề
6.4.2. Sử ụ d ng đường d n trả phí ẫ
Các hệ thống thanh toán nhỏ được thiết kế cho các giao dịch giá trị ấp. Chính vì vậy yếu th tố quan trọng là tương tác người dùng phải tự nhiên, thuận tiện, nhanh chóng. Từ thực tế khách hàng không mong muốn trả tiền nhiều cho các hàng hoá và dịch vụ, họ càng không muốn mất nhiều thời gian và sức lực trong các khâu thanh toán. Giải pháp chọn và trả (click anh pay) sẽ là phù hợp, hơn thế ữ n a có còn giảm chi phí hỗ trợ khách hàng. Quy trình thanh toán này trở thành một mở ộ r ng của các giao diện trình duyệt web, để mua thông tin hay dịch vụ, người sử ụ d ng chỉ cần kích chọn vào đường dẫn trả phí, cũng giống như cách lựa chọn một đường dẫn thông thường.
Có rất nhiều cách để có thể triển khai đường dẫn trả phí. Các nhà quản lý và phát triển Web thì đề xuất một cú phá chuẩn cho các đường dẫn trả phí. Đề xuất cũng hỗ trợ rất nhi u cách ề để thể hiện đường dẫn tr phí nh nhúng, applet hay các thành ph n i tượng, tấ ảả ư ầ đố t c các cách này đều yêu cầu phần mở rộng c a trình duy t web tiêu chu n để bi u di n đường d n tr phí ví ủ ệ ẩ ể ễ ẫ ả dụ các bộ đính kẻm plug-in, bộ đ ều khiển Active X hoặc là một applet. Nó cũng đòi hỏi cài đặt i một phần mềm “ví đ ện tử” trên máy tính của khách hàng. i
Luận Văn Cao học Ngành Công Nghệ Thông Tin - ĐH Bách Khoa Hà Nội 77 Trong một vài trường hợp cũng có thể sử ụ d ng đường d n tr phí trên m t trình duy t web ẫ ả ộ ệ chuẩn cơ sở và đơn giản ch cần cho thêm giá bán ngay trên đường dẫn. Xem hình 6-2 khi thông ỉ tin trao đổi giữa khách hàng và người bán đều đi qua PSP hoặc một nhà cung cấp có liên hệ chặt với PSP. Trong kịch bản này thì PSP có thể thay đổi đường dẫn trả phí (thêm vào các thông tin mô tả ả s n phẩm và giá) trước khi gửi tới khách hàng. Ví dụ:
<A HREF=”url”>click here to receive the song [5 cents charge]</A>
Thông tin về giá s n ph m [5 cents charge] được thêm và xác nh n b i gateway thanh toán ả ẩ ậ ở và do vậy lượng thanh toán bằng lượng phải trả. Khách hàng chấp nhận thoả thuận bằng cách đơn giản l a ch n ự ọ đường dẫn đó. Thông thường thì quy trình này thường xử dụng trong các truyền thông di động; khi đó người bán thường chỉ cung c p thông tin dạng thô, còn chính ấ ở mobile gateway mới mã hoá cung c p giao diấ ện phù hợp với thiết bị ủ c a người dùng.
6.4.3. Mạng thanh toán mở
Một trong những biện pháp giảm chi phí hỗ trợ khách hàng cũng như mở rộng ho t ạ động thanh toán nhỏ là thiết lập mạng thanh toán mở. Một khách hàng thuộc PSP này có thể thực hiện mua hàng ở một PSP khác. C ch chính để đạt được m c tiêu này là hai thông i p được ký ơ ế ụ đ ệ đ ệi n t : hoá đơn thanh toán PO và b ng ch n đường thanh toán PRT - payment routing table. ử ả ọ Xem xét mộ ịt k ch b n đơn gi n có 2 PSP A và B (hình 6-6). Trong k ch b n này khách hàng C ả ả ị ả chấp nhận l i đề ngh (3) t người bán và thực hiện trờ ị ừ ả tiền bằng cách gửi cho người bán một hoá đơn thanh toán đã ký bởi PSP_A (6). Người bán ngay lậ ứp t c có th xác định tính chính xác ể của hoá đơn này. Người ban sau đó có thể lấy được ti n t nh ng hoá đơn này (7 và 8). Việc lấy ề ừ ữ tiền về của người bán có thể được thực hiện một lần thông qua xử lý lưới để giảm chi phí.
Bảng chọn đường thanh toán được gửi từ đi trước mỗi PSP tớ ấ ải t t c các th c th có tài ự ể khoản thanh toán với nó. Ví dụ trong hình 6-6, PSP_A gửi PRT tới PSP_B và PSP_B gửi PRT tới người bán. Trong một kịch bản phức tạp hơn, như trong hình 6-7, mỗi PSP sẽ gử ải b ng ch n ọ đường thanh toán PRT một cách định k t i t t c các ngườỳ ớ ấ ả i ng i bán và các PSP khác có quan ườ hệ với nó.
Luận Văn Cao học Ngành Công Nghệ Thông Tin - ĐH Bách Khoa Hà Nội 78 Hình 6-6: Tương tác giữa 2 PSPs
Hình 6-7: Tương tác trong mạng lưới PSP
PSP_A PSP_B
Customer C Merchant M
1. PRT (signed by PSP_A)
3. Offer, PRT (unsigned) 4. Offer,
PRT, Approval
5. PO
(signed by PSP_A)
6. PO (signed by PSP_A)
7. PO (signed by PSP_A) 8. PO (signed by PSP_A)
PSP_A PSP_B
PO
(signed by PSP_A)
PO (signed by PSP_A)
Offer, PRT (unsigned)
PSP_X PSP_Y
PSP_Z PRT
(signed by PSP_A)
PRT (signed by PSP_Z)
PRT (signed by PSP_Y) PRT
(signed by PSP_A)
PRT (signed by PSP_X)
PRT (signed by PSP_B) 2. PRT
(signed by PSP_B)
PO (signed by PSP_A) Offer,
PRT, Approval
Luận Văn Cao học Ngành Công Nghệ Thông Tin - ĐH Bách Khoa Hà Nội 79 Bảng chọn đường thanh toán PRT gồm các thông tin cần thiết để cho phép người bán có thể xử lý một hoá đơn thanh toán đã ký bởi PSP. Khi PSP gửi PRT, nó cũng ký với khoá riêng của mình.
Cấu trúc của bảng PRT được ký bởi PSP_B sẽ gồm các thông tin sau đây:
1. Định danh người giữ tài khoản (người bán M).
2. Khoá công khai của PSP phát hành hoá đơn thanh toán (PSP_A).
3. Số tiền thanh toán tối đa được chấp nhận từ PSP cung cấp (PSP_A).
4. Mứ ệc l phí để thanh toán hoá n c a PSP (2% hoặ ố đđơ ủ c t i a 5 cent). S ti n người ố ề bán sẽ nhận được = số tiền khách hàng trả - mức lệ phí thanh toán.
5. Thời gian thanh toán tối thiểu, việc thanh toán sẽ chỉ hợp l nếệ u được th c hi n ự ệ trước thời gian này.
6. Một bằng chứng về các định danh tham gia giao dịch. Bằng chứng này được dùng trong các giải quyết tranh ch p và hoàn trấ ả. Thông thường bằng ch ng là các ghi ứ chép của PSP (log file), hoặc là hoá đơn nhận đã được ký.
7. Đường dẫn các PSP thông qua đó hoá đơn thanh toán được chi trả. Trong hình 6-8 sẽ chỉ có định danh của PSP_B. Trong hình 6-9 sẽ có thể có {PSP_B, PSP_Y, PSP_X} hoặc {PSP_B, PSP_Z}.
8. Khoảng thời gian hợp lệ mà PSP phát hành b ng ch n đường thanh toán PRT. ả ọ 9. Một định danh cho bảng nh đị đường PRT (ví dụ: số đếm).
10. Một số các chi tiết kỹ thuật khác có thể được bổ sung để đảm bảo chắc chắn không có tranh chấp.
Cấu trúc của thông tin thanh toán PO g m nh ng thành ph n sau ây: ồ ữ ầ đ
1. Lượng tiền và loại tiền phải trả.
2. Đường dẫn PSP thông qua đó hoá đơn PO được thanh toán.
3. Thời gian hết hạn (người phát hành sẽ không thanh toán sau thờ đ ểi i m này).
4. Định danh của PRT mà thanh toán sử dụng.
5. Thời gian phát hành từ PSP và số hiệu PO tại thời đ ể đi m ó (dùng để tránh kh n ng ả ă sử dụng lặp).
6. Ngoài ra, có thể thêm vào các thông số bổ sung kỹ thuật khác.