Tài liệu Hướng dẫn Tích hợp Bảo mật 3D Phần mềm
Hướng dẫn tích hợp Bảo mật 3D
Từ ngày 01.01.2021, xác thực hai yếu tố sẽ được thực hiện như một yêu cầu bắt buộc đối với tất cả các giao dịch thanh toán bằng thẻ thương mại điện tử. Để tuân thủ nghĩa vụ này,
các nhà khai thác mạng thẻ tín dụng sẽ sử dụng cái gọi là quy trình Bảo mật 3D. Đối với bạn với tư cách là người bán, bạn bắt buộc phải có thể thực hiện thủ tục này cho khách hàng của mình từ
01.01.2021. Trong phần sau, bạn sẽ tìm thấy mô tả về các cách tích hợp khác nhau và cách thức triển khai quy trình Bảo mật 3D cho chúng.
Vui lòng chọn phương pháp tích hợp bạn sử dụng
- Bạn có đang sử dụng hình thức thanh toán hCO không?
- Bạn có đang sử dụng hình thức thanh toán hPF không?
- Bạn có xử lý các khoản thanh toán mà không sử dụng biểu mẫu do hệ thống Unzer cung cấp không?
Xin lưu ý: Việc ghi nợ hoặc ủy quyền trước (đặt trước) theo cách nào cũng rất quan trọng. Ngay cả khi bạn sử dụng hình thức thanh toán từ Unzer GmbH để đăng ký dữ liệu thẻ, quy trình 3D Secure sẽ được thực hiện mà không có biểu mẫu thanh toán khi dữ liệu thẻ được ghi nợ hoặc ủy quyền lần đầu tiên. Trong trường hợp này, áp dụng cách tích hợp thứ ba không có biểu mẫu do Unzer cung cấp.
Cũng xin lưu ý:
Nếu bạn sử dụng thanh toán định kỳ (thanh toán đăng ký), hãy nhớ đọc phần “Thanh toán định kỳ và an toàn 3D”.
Quy trình bảo mật 3D khi sử dụng biểu mẫu thanh toán hCO
Biểu mẫu thanh toán hCO đã được thiết kế cho quy trình Bảo mật 3D. Không có hành động bổ sung nào từ phía bạn cần thiết để thực hiện quy trình. Tuy nhiên bạn
phải đảm bảo rằng hệ thống của bạn có thể xử lý các câu trả lời tương ứng của hệ thống thanh toán của chúng tôi trong trường hợp quá trình Bảo mật 3D được bắt đầu. Trong phản hồi không đồng bộ từ
hệ thống thanh toán đến máy chủ của bạn, kết quả của giao dịch được truyền đi và phải được đánh giá ở đó trước khi trả về URL được truyền đến hệ thống thanh toán.
Vì mục đích này, các tham số sau đây phải được đánh giá.
- ĐANG XỬ LÝ.RETURN.CODE = 000.200.000
- PROCESSING.RETURN = Giao dịch + đang chờ xử lý
- CHẾ BIẾN.RESULT = ACK
Giải thích: Trạng thái của giao dịch là "đang chờ xử lý", tham số PROCESSING.RESULT
chỉ đại diện cho một kết quả sơ bộ. Miễn là quy trình Bảo mật 3D được thực hiện, trạng thái
vẫn đang chờ xử lý.
Kết quả cuối cùng của giao dịch sau đó là
- ĐANG XỬ LÝ.RETURN.CODE = 000.000.000
- CHẾ BIẾN.RESULT = ACK
or - PROCESSING.RETURN.CODE = irgendein Wert ungleich 000.000.000 đơn đặt hàng 000.200.000
- CHẾ BIẾN.RESULT = NOK
Trong trường hợp đầu tiên, giao dịch đã được hoàn thành thành công, trong trường hợp thứ hai, nó đã thất bại toàn bộ. Sau này có thể có nhiều lý do khác nhau, bao gồm cả việc từ chối xác thực. Bạn sẽ
nhận thêm thông tin chi tiết trong các tham số “PROCESSING.RETURN” và “PROCESSING.RETURN.CODE”.
Chúng tôi khuyên bạn nên chạy thử nghiệm cho cả hai thông báo. Để biết thêm thông tin về cách thực hiện kiểm tra và chi tiết thẻ tín dụng nào bạn có thể sử dụng để kiểm tra, vui lòng xem bên dưới.
Quy trình bảo mật 3D khi sử dụng biểu mẫu thanh toán hPF
Biểu mẫu thanh toán hPF cũng được thiết kế để sử dụng quy trình 3DS. Không có hành động bổ sung nào từ phía bạn cần thiết để thực hiện quy trình. Như mô tả
để triển khai hCO, phản hồi từ hệ thống thanh toán diễn ra theo hai bước, đó là lý do tại sao hệ thống của bạn phải kiểm tra giá trị của PROCESSING.RETURN.CODE
khi xử lý phản hồi.
Vì mục đích này, các tham số sau đây phải được đánh giá.
- ĐANG XỬ LÝ.RETURN.CODE = 000.200.000
- PROCESSING.RETURN = Giao dịch + đang chờ xử lý
- CHẾ BIẾN.RESULT = ACK
Giải thích: Trạng thái của giao dịch là "đang chờ xử lý", tham số PROCESSING.RESULT chỉ thể hiện một kết quả sơ bộ. Miễn là quy trình Bảo mật 3D được thực hiện, trạng thái
vẫn đang chờ xử lý.
Kết quả cuối cùng của giao dịch sau đó là
- ĐANG XỬ LÝ.RETURN.CODE = 000.000.000
- CHẾ BIẾN.RESULT = ACK
or - PROCESSING.RETURN.CODE = irgendein Wert ungleich 000.000.000 đơn đặt hàng 000.200.000
- CHẾ BIẾN.RESULT = NOK
Trong trường hợp đầu tiên, giao dịch đã được hoàn thành thành công, trong trường hợp thứ hai, nó đã thất bại toàn bộ. Sau này có thể có nhiều lý do khác nhau, bao gồm cả việc từ chối xác thực. Bạn sẽ
nhận thêm thông tin chi tiết trong các tham số “PROCESSING.RETURN” và “PROCESSING.RETURN.CODE”.
Chúng tôi khuyên bạn nên chạy thử nghiệm cho cả hai thông báo. Để biết thêm thông tin về cách thực hiện kiểm tra và chi tiết thẻ tín dụng nào bạn có thể sử dụng để kiểm tra, vui lòng xem bên dưới.
Quy trình bảo mật 3D với kết nối trực tiếp
Nếu bạn không sử dụng hình thức thanh toán do Unzer (trước đây là heidelpay) cung cấp để xử lý các khoản thanh toán bằng thẻ tín dụng hoặc nếu bạn chỉ đăng ký thẻ bằng một trong các biểu mẫu và xử lý ủy quyền trước (đặt trước) hoặc ghi nợ như một tham chiếu đến việc đăng ký dưới dạng giao tiếp trực tiếp với hệ thống thanh toán, bạn phải thực hiện quy trình Bảo mật 3D.
Luồng giao dịch không đồng bộ:
Đây là một quá trình không đồng bộ, trong đó máy chủ của bạn nhận được chuyển tiếp URL (Chuyển hướng URL) từ hệ thống thanh toán của chúng tôi. Máy chủ của bạn phải chuyển tiếp khách hàng đến đây URL để anh ta có thể thực hiện xác thực thông qua quy trình Bảo mật 3D. Kết quả của xác thực 3D Secure này được ngân hàng phát hành thẻ báo cáo trực tiếp cho Unzer.
Sau khi xác thực thành công, giao dịch được tiếp tục xử lý trong hệ thống Unzer theo cách bạn đã biết bằng cách gửi cho hệ thống của bạn một kết quả tổng thể ở cuối và bạn sẽ trả lời
với một chuyển hướng URL. Hệ thống thanh toán sau đó sẽ chuyển hướng khách hàng trở lại hệ thống của bạn bằng cách sử dụng chuyển hướng này URL từ hệ thống của bạn
Xin lưu ý: Trong quy trình làm việc này, hệ thống của bạn nhận được hai câu trả lời từ hệ thống thanh toán:
- Một thẻ có trạng thái “đang chờ xử lý” (PROCESSING.RETURN.CODE = 000.200.000 và PROCESSING.RETURN = Giao dịch + đang chờ xử lý) và các thông số chuyển hướng đến ngân hàng phát hành thẻ của khách hàng
- Một với kết quả cuối cùng của việc ghi nợ hoặc đặt trước. Ngoài ra còn có hai chuyển hướng URLđược đề cập trong quy trình này, một từ hệ thống thanh toán mà khách hàng phải được chuyển hướng để xác thực tại ngân hàng phát hành thẻ của mình và một từ hệ thống của bạn, khi nhận được kết quả cuối cùng, để chuyển hướng khách hàng trở lại hệ thống của bạn.
Các thay đổi sau đây sẽ được thực hiện đối với quy trình thông thường. Xin lưu ý rằng do việc triển khai các phương thức thanh toán không đồng bộ khác, chẳng hạn như Paypal, một số
các quy trình có thể đã tồn tại trong quá trình triển khai của bạn.
- Phản ứng URL
Trong cuộc gọi đầu tiên (số 2 trong sơ đồ) đến hệ thống thanh toán, một "Phản hồi URL”Phải được thông qua trong nhóm giao diện người dùng.
Xin lưu ý: Thông số IDENTIFICATION.REFERENCEID chỉ có liên quan nếu bạn tham chiếu đến đăng ký hoặc giao dịch đã tồn tại khác - Xử lý chuyển hướng URL Nếu yêu cầu xác thực, chuyển hướng URL và các tham số khác trong nhóm chuyển hướng được chuyển trong phản hồi từ hệ thống thanh toán (số 5 trong sơ đồ).
- Chuyển tiếp khách hàng đến chuyển hướng URL
Nếu nhóm chuyển hướng đang phản hồi bằng chuyển hướng URL, trình duyệt của khách hàng phải được chuyển hướng đến URL (Số 6 trong sơ đồ) để thực hiện xác thực. Các tham số bổ sung từ nhóm chuyển hướng phải được chuyển sang bên ngoài webtrang web dưới dạng tham số POST.
Xin lưu ý: Các thông số bổ sung chỉ được trả lại trong nhóm “PROCESSING.REDIRECT.xxx” với Phiên bản bảo mật 3D 1 (ngay cả khi có số lượng và cách đặt tên có thể khác nhau), trong khi với Phiên bản 3D 2 chỉ có PROCESSING.REDIRECT.URL như hiển thị bên dưới được trả lại: https://heidelpay.hpcgw.net/AuthService/v1/auth/public/2258_2863FFA4C5241C12E39F37
CCF / run Điều này có nghĩa là bất kể loại và số lượng tham số, trình duyệt máy khách phải chuyển hướng đến PROCESSING.REDIRECT.URL.
Dưới đây, bạn sẽ tìm thấy một mã đơn giảnampvề cách một chuyển hướng như vậy có thể được thực hiện. Các một phần nhằm mục đích thông báo cho khách hàng cuối có hệ thống không hỗ trợ Javascript hoặc bị vô hiệu hóa. Chúng tôi đặc biệt khuyên rằng chuyển hướng được thực hiện trong cửa sổ trình duyệt đang hoạt động của khách hàng và không sử dụng cửa sổ bật lên hoặc cửa sổ trình duyệt mới, vì điều này có thể
khiến khách hàng khó chịu và khiến họ phải đóng trang mà họ được chuyển hướng đến.
- Kiểm tra kết quả không đồng bộ
Kết quả xác thực được gửi không đồng bộ đến máy chủ của bạn. Hệ thống thanh toán mong đợi giá trị hợp lệ URL như phản hồi. (Số 12 & 13 trong sơ đồ). Thành công hay bị từ chối
thanh toán, một khác URL có thể được hệ thống của bạn phản hồi tại đây. - Đường dẫn trở lại của khách hàng
Hệ thống thanh toán chuyển hướng khách hàng đến URL được cung cấp bởi hệ thống của người bán sau khi quá trình xác thực và giao dịch thanh toán đã hoàn tất.
Xin lưu ý: Các bước 4.) và 5.) tiến hành theo cách giống hệt như cách bạn đã quen thuộc với các giao dịch NONE 3D Secure hiện có.
Thanh toán định kỳ và an toàn 3D
Từ ngày 1 tháng 2021 năm 3, XNUMXD Secure sẽ là bắt buộc đối với tất cả các giao dịch thẻ thương mại điện tử. Tuy nhiên, vì điều này hầu như không áp dụng cho các khoản thanh toán định kỳ, ngân hàng
hệ thống có một quy trình làm việc riêng cho việc này.
Vì mục đích này, các ngân hàng phân biệt giữa
- CIT = giao dịch do khách hàng khởi tạo
- MIT = giao dịch do người bán khởi tạo
Giao dịch đầu tiên của thẻ trong tài khoản người bán của bạn phải được xác thực bằng 3D Secure từ ngày 01.01.2021 trở đi. Việc xác thực thành công như vậy là một yêu cầu bắt buộc trong
để có thể gửi thêm các yêu cầu đặt phòng sau đó trên cùng một thẻ mà không có 3D Secure. Do đó, khách hàng phải được chuyển tiếp đến ngân hàng phát hành thẻ của mình cho khoản ghi nợ đầu tiên trong
theo quy trình được mô tả ở trên và xác thực mình là chủ thẻ. Nếu không có kế hoạch ghi nợ tại thời điểm đặt hàng, ví dụampDo thời gian dùng thử, thay vào đó phải đặt trước (ủy quyền trước) ít nhất một euro bằng 3D Secure với sự có mặt của khách hàng. Việc nắm bắt thông tin đặt chỗ này là không cần thiết.
Tuy nhiên, đối với khách hàng hiện tại, không cần xác thực 3D Secure. Nếu lần ghi nợ thành công đầu tiên diễn ra trước ngày 01.01.2021, hồ sơ khách hàng cũng có thể được giả định là
đã được xác thực thành công. Mặt khác, đối với khách hàng mới kể từ ngày 01.01.2021, xác thực 3D Secure là bắt buộc đối với lần ghi nợ hoặc đặt chỗ đầu tiên (ủy quyền trước).
Xin lưu ý: Về mặt này, hệ thống ngân hàng xem xét dữ liệu thẻ, không phải dữ liệu khách hàng. Vì vậy, nếu khách hàng hiện tại sử dụng thẻ mới sau 01.01.2021, đối vớiample vì cái trước
một người đã hết hạn hoặc vì anh ta đã thay đổi ngân hàng phát hành thẻ của mình, đây là một chu kỳ lặp lại mới theo quan điểm của các ngân hàng view và phải được xác thực bằng 3D Secure cho lần đặt vé đầu tiên.
Khi xác thực ban đầu này đã được thực hiện thành công, tất cả các giao dịch tiếp theo được miễn nghĩa vụ sử dụng 3D Secure Do đó, điều kiện tiên quyết để thanh toán định kỳ mà không có 3D Secure là:
- Có ít nhất một lần ghi nợ hoặc đặt trước (ủy quyền trước) thành công được thực hiện với 3D Secure hoặc diễn ra trước ngày 01.01.2021.
- nó được tham chiếu đến đăng ký hiện có và ghi nợ khi gửi
Để hệ thống thanh toán biết rằng đây là khoản thanh toán định kỳ, tham số RECURRENCE.MODE = REPEATED cũng phải được gửi. Điều này báo hiệu cho hệ thống rằng
thanh toán định kỳ sẽ được báo cáo cho hệ thống ngân hàng.
Xin lưu ý: Nếu tham số RECURRENCE.MODE = REPEATED được nhập khi thẻ mới được nạp lần đầu tiên, chuyển tiếp 3D Secure sẽ được thực hiện bất chấp tham số này.
Kiểm tra việc triển khai 3D Secure
Bạn có thể kiểm tra kết nối 3D Secure bất kỳ lúc nào qua hệ thống thanh toán của chúng tôi. Để làm như vậy, hãy sử dụng chế độ “CONNECTOR_TEST” cho một giao dịch, như được hiển thị trongamples ở trên.
Dữ liệu kết nối cho thử nghiệm này:
| BẢO MẬT. | 31HA07BC8142C5A171745D00AD63D182 |
| ĐĂNG NHẬP NGƯỜI DÙNG | 31ha07bc8142c5a171744e5aef11ffd3 |
| NGƯỜI DÙNG.PWD | 93167DE7 |
| GIAO DỊCH.CHANNEL | 31HA07BC8142C5A171749A60D979B6E4 |
| Đơn vị tiền tệ được định cấu hình cho phiên bản 3D 2 | EUR, USD, SEK |
| Đơn vị tiền tệ được định cấu hình cho phiên bản 3D 1 | GBP, CZK, CHF |
Điểm cuối cổng hệ thống là
Cổng SGW:
- https://test-heidelpay.hpcgw.net/sgw/gtw - được mã hóa theo tiếng Latinh-15
- https://test-heidelpay.hpcgw.net/sgw/gtwu - được mã hóa UTF-8
Cổng NGW:
- https://test-heidelpay.hpcgw.net/ngw/post
Dữ liệu thẻ tín dụng cho bài kiểm tra này:
| thương hiệu | số thẻ | CVV | ngày hết hạn | ghi chú |
| Thẻ MasterCard | 5453010000059543 | 123 | Ngày trong tương lai | 3D - mật khẩu: secret3 |
| Visa | 4711100000000000 | 123 | Ngày trong tương lai | 3DS - mật khẩu: bí mật! 33 |
Xin lưu ý: Đối với 3D Secure Version 2, bạn không cần nhập mật khẩu mà chỉ cần nhấp vào liên kết ”Nhấp vào đây để hoàn tất xác thực.
Cách duy nhất để mô phỏng lỗi với 3D Secure Version 2 là để trang có liên kết hết thời gian chờ (khoảng 18 phút).
Đọc thêm về hướng dẫn này và tải xuống PDF:
Tài liệu / Tài nguyên
 |
Hướng dẫn tích hợp bảo mật 3D phần mềm [tập tin pdf] Tài liệu Unzer, Hướng dẫn tích hợp, Bảo mật 3D |
