Thêm tính năng hỗ trợ 3DS1 và 3DS2

Bạn có thể sử dụng cả 3DS1 và 3DS2 để tích hợp tính năng Đặt phòng toàn diện trong Trung tâm hành động. Bạn có thể triển khai một (hoặc cả hai) phương thức này để tích hợp.

3DS1 hoặc 3DS2 đều đáp ứng yêu cầu về quy trình Xác thực khách hàng mạnh của PSD2, nhưng có một số điểm khác biệt chính:

  • 3DS1: Bạn có thể quyết định kích hoạt 3DS1 cho một giao dịch khi nhận được tín hiệu cho thấy khoản phí đó là gian lận.
    • Để triển khai 3DS1, bạn cần thay đổi máy chủ đặt phòng.
  • 3DS2: 3DS2 sẽ chỉ được dùng cho các giao dịch áp dụng PSD2 (ngân hàng thu phí và ngân hàng của khách hàng đều ở Khu vực kinh tế Châu Âu (EEA)).
    • Để triển khai 3DS2, bạn cần thay đổi nguồn cấp dữ liệu người bán.

Triển khai 3DS2

Để triển khai 3DS2, bạn cần thêm các trường bổ sung vào nguồn cấp dữ liệu người bán trong thông báo TokenizationConfig. Nếu tất cả các khoản thanh toán đều chuyển đến cùng một tài khoản, bạn sẽ lặp lại giá trị này trong mỗi mục nhập của người bán. Nếu các khoản thanh toán được chuyển đến các tài khoản khác nhau, thì giá trị trong mỗi mục nhập người bán sẽ cần phải là của tài khoản nhận tiền trong giao dịch.

Thay đổi đối với nguồn cấp dữ liệu người bán

  • merchant_of_record_name: Tên của Đơn vị chịu trách nhiệm xử lý thanh toán (MOR). Tên hiển thị cho người dùng này sẽ xuất hiện trong các thử thách 3DS2.
  • payment_country_code: Quốc gia nơi giao dịch sẽ được xử lý, ở định dạng ISO 3166-1 alpha-2.
  • Thông báo CardNetworkParameters: Thông báo này được lặp lại với các giá trị dành riêng cho từng mạng (Chỉ cần thiết cho Visa và American Express)
    • card_network: Mạng (Visa, American Express) áp dụng các giá trị này
    • acquirer_bin: Mã số nhận dạng ngân hàng của ngân hàng thu phí dùng để xử lý thẻ.
    • acquirer_merchant_id: Giá trị nhận dạng người bán do bên thu phí chỉ định cho người bán để sử dụng trong quá trình uỷ quyền giao dịch (đối với giao dịch bằng thẻ Visa và American Express).

Bằng cách thêm các trường này vào nguồn cấp dữ liệu người bán, bạn sẽ nhận được một mã hoá 3DS2 trong unparsed_payment_method_token mà máy chủ đặt phòng của bạn nhận được bất cứ khi nào PSD2 áp dụng cho giao dịch. Bạn nên truyền unparsed_payment_method_token và mật mã được nhúng của mã này cho đối tác xử lý theo thông số kỹ thuật của họ.

Triển khai 3DS1

Thay đổi đối với Máy chủ đặt phòng

Chúng tôi sẽ tạo một yêu cầu CreateBooking và nếu bạn xác định cần có 3DS1 cho giao dịch, hãy trả về Booking Failure từ phương thức CreateBooking và chỉ định PAYMENT_REQUIRES_3DS1 làm nguyên nhân. Trong phản hồi lỗi đó, bạn cũng cần chỉ định thông báo ThreeDS1Parameters trong thông báo PaymentFailureInformation:

  • acs_url = URL để tải một biểu mẫu hiển thị cho Người dùng nhằm xác thực.
  • pa_req = Yêu cầu xác thực thanh toán. Để được đăng lên biểu mẫu ACSUrl.
  • transaction_id = Giá trị nhận dạng do nhà cung cấp ACS sử dụng. Để đăng lên biểu mẫu ACSUrl.
  • md_merchant_data = Dữ liệu để Trung tâm hành động chia sẻ với nhà cung cấp ACS (nếu có).

Sau đó, chúng tôi sẽ gửi lại yêu cầu CreateBooking ban đầu cùng với pa_response nằm trong thông báo PaymentInformation. Trường pa_response sẽ chứa tải trọng được nhà cung cấp ACS trả về cho chúng tôi và bạn sẽ sử dụng tải trọng này để uỷ quyền giao dịch với trình xử lý.

Dưới đây là sơ đồ mô tả quy trình 3DS1:

Hình 1: Sơ đồ quy trình 3DS1
Hình 1: Sơ đồ quy trình 3DS1