Tích hợp với một nhà cung cấp thanh toán; Cách tiếp cận OOP đúng đắn và mạnh mẽ

Lịch sử

Chúng tôi hiện đang sử dụng mô hình chuyển hướng được gọi là thanh toán trực tuyến của chúng tôi (nơi bạn gửi người trả tiền đến cổng thanh toán, nơi anh ta nhập chi tiết thanh toán của mình - cổng sau đó sẽ đưa anh ta trở lại trang gọi lại thành công / thất bại). Điều đó dễ dàng và đơn giản, nhưng thật không may, khá bất tiện và đôi khi gây nhầm lẫn cho khách hàng của chúng tôi (rời khỏi trang web, thay đổi chi tiết thẻ tín dụng của họ bằng một đăng nhập bổ sung trên một trang web khác, v.v.).

Ý định & mô tả vấn đề

Chúng tôi hiện đang có ý định chuyển sang một cách tiếp cận tích hợp bằng cách trao đổi các yêu cầu và phản hồi XML. Vấn đề của tôi là làm thế nào để phục vụ với tất cả (hay đúng hơn là) những điều có thể xảy ra trong quá trình xử lý - lưu ý rằng sự đơn giản thông thường là mạnh mẽ trong khi sự phức tạp là mong manh.

Ví dụ

• Hủy bỏ người dùng: Người dùng nhập chi tiết Thẻ tín dụng và lượt truy cập gửi. Một thông báo XML tới cổng của nhà cung cấp được gửi và chờ phản hồi. Người dùng nhấn "dừng" trong trình duyệt của mình hoặc đóng cửa sổ.
  • ign_user_abort () trong PHP có thể là một tùy chọn - nhưng điều đó có đáng tin cậy không?
  • có thể tốt hơn để chuyển hướng người dùng đến trang "vui lòng đợi", đến lượt nó mở AJAX hoặc yêu cầu khác đến bộ xử lý thực tế không dựa vào kết nối?
• Cơ sở dữ liệu biến mất
  • Nghe có vẻ quá phức tạp, nhưng với ví dụ: máy chủ web ở Hoa Kỳ và DB ở Anh, điều đó đã xảy ra và sẽ xảy ra lần nữa: Người dùng nhấp vào đơn đặt hàng của mình, yêu cầu thanh toán đã được gửi đến nhà cung cấp nhưng không thể lưu trữ phản hồi trong cơ sở dữ liệu. Cách tiếp cận nào tôi có thể sử dụng, sử dụng PHP để sắp xếp một SQL như "Giao dịch" mà chỉ cuối cùng mới được cam kết hoặc quay trở lại, tùy thuộc vào từng bước? Nếu sau đó không xảy ra cam kết hoặc quay lại, tôi có thể "khóa" người dùng để ngăn anh ta thanh toán lại hoặc tài khoản thanh toán không đúng cách - nhưng làm thế nào?
• Và những gì khác tôi cần phải xem xét về mặt kỹ thuật? Không có ví dụ tích hợp nào, ví dụ như Worldpay, Realex hoặc SagePay cung cấp bất kỳ thông tin chi tiết nào, và công cụ tìm kiếm của tôi hoặc cụm từ tìm kiếm của tôi không đủ tốt để tìm suy nghĩ của người khác về điều này.

Cảm ơn bạn rất nhiều vì bất kỳ cái nhìn sâu sắc về cách bạn sẽ tiếp cận này!

Là một nhà phát triển làm việc gần như độc quyền với các khoản thanh toán, có lẽ tôi có thể cung cấp cho bạn một số gợi ý về nơi mà những cạm bẫy có thể xảy ra. Tôi đang làm việc cho một trang web có lưu lượng truy cập cao, ~ 40 nhà cung cấp dịch vụ thanh toán hoạt động (PSP) và xử lý hàng chục nghìn giao dịch mỗi ngày. Và hãy tin tôi, sh * t sẽ luôn luôn hâm mộ và tất cả những gì bạn có thể làm là chuẩn bị càng nhiều càng tốt để xử lý tình huống từ thời điểm đó.

Đăng nhập, đăng nhập và đăng nhập một số ...

Đây là phần quan trọng nhất trong quy trình thanh toán của bạn, hãy đảm bảo bạn có hồ sơ về mọi thứ . Hãy tự hỏi mình câu hỏi "phần thông tin này có thể giúp tôi một lần trong một triệu giao dịch không?". Nếu câu trả lời là có, đăng nhập nó!

Thiết lập của chúng tôi là điểm chính của đăng nhập là cơ sở dữ liệu. Mọi giao dịch được bắt đầu, thất bại, giải quyết, chuyển hướng, vv được lưu trữ trên mỗi PSP trong các bảng. Nếu PSP sử dụng API, tất cả các lệnh gọi API đều được ghi lại (cả yêu cầu được gửi và phản hồi). Tất cả các cuộc gọi lại được ghi lại trong bảng là tốt. Và kể từ đó trở đi..

Khi chúng tôi gặp phải một sự kiện hoặc ngoại lệ không mong muốn, chúng tôi đăng nhập nó vào tệp nhật ký PHP với một định dạng nhất định để làm cho nó có thể tìm kiếm và dễ dàng tìm thấy dựa trên ID giao dịch, ID người dùng, v.v.

Bạn sẽ biết ơn rằng bạn có tất cả dữ liệu nếu bạn bị kiện chẳng hạn.

Giám sát và cảnh báo

Xây dựng theo dõi logic với một số bài kiểm tra đơn giản sẽ cảnh báo bạn qua email khi có sự cố. Ví dụ: nếu 3 cuộc gọi lại liên tiếp không thành công cho PSP. Tất cả những điều nhỏ nhặt này có thể khiến bạn giải quyết vấn đề nhanh chóng thay vì phản ứng với chúng sau khi khách hàng của bạn đã cho bạn biết về chúng (điều không luôn xảy ra) là rất quan trọng.

Giao dịch cơ sở dữ liệu

Nếu bạn có nhu cầu thiết lập hoặc thay đổi cấu trúc cơ sở dữ liệu của mình để hỗ trợ các giao dịch cơ sở dữ liệu, ví dụ: hãy sử dụng InnoDB trên MySQL. Hãy xem câu trả lời này về cách xử lý nó trong mã. Bạn nên đảm bảo rằng mọi bước của giao dịch đã được hoàn thành hoặc không có gì, việc giao dịch đã hoàn thành một phần chỉ là gánh nặng cho bạn và hệ thống của bạn. Ví dụ: 1) Người dùng hoàn thành giao dịch, 2) Người dùng được thưởng bằng cách nào đó. Nếu không đáp ứng cả bước 1 và 2 ở đây, giao dịch sẽ không được đặt thành hoàn thành trong bước 1.

Người kỹ thuật liên hệ

Khi bạn gặp vấn đề về kỹ thuật, hãy chắc chắn rằng bạn có người kỹ thuật để liên hệ ngay lập tức. Có một người quản lý tài khoản là khá vô dụng, đặc biệt nếu người đó quyết định làm trung gian giữa bạn và kỹ thuật viên của họ.

Ví dụ về thế giới trực tiếp đã xảy ra với tôi: một PSP tất cả đột ngột ngừng hoạt động, không có gì trong mã của chúng tôi thay đổi và họ nói họ cũng không thay đổi gì cả. Sau khi gửi thông tin gỡ lỗi qua lại với họ (thông qua người quản lý tài khoản của họ), một trong những kỹ thuật viên của họ nhận thấy rằng các lược đồ WSDL có vẻ bị tắt. Sau đó, họ nhận ra rằng họ đã cập nhật lược đồ WSDL của họ và sau khi gỡ lỗi, tôi nhận ra rằng PHP đã lưu trữ lược đồ WSDL cũ. Điều này có thể đã bị bắt sớm hơn khi được giải quyết nếu tôi chỉ cần một người kỹ thuật trên Skype liên hệ trực tiếp. Hoặc nếu họ chỉ thừa nhận thay đổi lược đồ WSDL của họ, nhưng thường khó có thể nhận được lời thú nhận từ PSP khi có sự cố xảy ra ..

Từ cuối cùng...

Chuẩn bị tất cả những gì bạn có thể và cho rằng MỌI THỨ có thể xảy ra :)

Không chắc chắn đây chính xác là loại câu trả lời của bạn sau đó, nhưng tôi đang cố gắng cung cấp một ví dụ thực tế về thanh toán và cách bạn có thể ngăn chặn những cạm bẫy và cạm bẫy lớn nhất. Hãy cho tôi biết nếu có điều gì bạn muốn tôi giải thích hoặc nếu bạn quan tâm đến chủ đề khác.

Theo ý kiến ​​trung thực của tôi, cách tốt nhất để quản lý các giao dịch thông qua Cổng thanh toán là thông qua các dịch vụ web. Một số cổng thanh toán khác nhau cung cấp các loại dịch vụ này với tỷ lệ phần trăm cố định cạnh tranh cho mỗi giao dịch + hoa hồng thẻ tín dụng thông thường mà thẻ tín dụng của khách hàng cũng sẽ sử dụng (Ví dụ: Cybersource ). Với tất cả mọi thứ trong cuộc sống, bạn nhận được những gì bạn phải trả, 9 xu / giao dịch không tồn tại với bộ xử lý thanh toán có uy tín mà không buộc bạn phải chuyển hướng người dùng.

Mã thông báo và dữ liệu an toàn

Lưu trữ chi tiết thẻ tín dụng trên hệ thống của bạn chỉ là vấn đề rắc rối, và tùy thuộc vào nơi bạn sống, thậm chí có thể có các yêu cầu pháp lý và luật hình sự có thể chống lại cách quản lý dữ liệu này. Trừ khi bạn là Amazon, bạn không cần phải lo lắng về tất cả sự phức tạp về kỹ thuật và pháp lý. Bộ xử lý thanh toán loại bỏ rủi ro và sự phức tạp này khỏi bạn bằng cách có các dịch vụ web được mã hóa SSL nơi chi tiết thẻ tín dụng có thể được chuyển qua trang web của bạn đến máy chủ của bạn và từ máy chủ của bạn đến các dịch vụ web của bộ xử lý thanh toán để gửi thanh toán qua tài khoản của bạn với bộ xử lý. Đổi lại, dịch vụ web sẽ cung cấp cho bạn mã ủy quyền hoặc mã thông báo biểu thị duy nhất giao dịch trên hệ thống của họ và cung cấp cho bạn số tham chiếu để nhanh chóng tìm kiếm thông qua tài khoản của bạn cho các giao dịch cụ thể. Bạn có thể giữ lại mã thông báo trong cơ sở dữ liệu của mình và nó không có kết quả thực sự đối với người dùng nếu mã thông báo bị xâm phạm trên hệ thống của bạn. Hơn nữa bằng cách không lưu trữ chi tiết thẻ tín dụng trên hệ thống của bạn, tài khoản ngân hàng của người dùng vẫn an toàn ngay cả khi hệ thống của bạn bị xâm phạm.

Lưu giữ hồ sơ thanh toán

Cách tiếp cận này để tích hợp với bộ xử lý thanh toán có thêm lợi ích là có thể duy trì hồ sơ thanh toán và mua hàng của riêng bạn tách biệt với bộ xử lý thanh toán của bạn, nhưng được liên kết thông qua mã thông báo. Điều này cho phép bạn chạy báo cáo doanh thu thông qua hệ thống của mình, truy vấn phân tích và người dùng có thể xem giao dịch mua của họ mà không cần phải truy vấn bộ xử lý thanh toán để biết thông tin.

Tuân thủ PCI

Bất kỳ bộ xử lý thanh toán có uy tín nào cũng sẽ có tất cả các hệ thống và dữ liệu của họ được lưu trữ trong các máy chủ và cơ sở tuân thủ PCI. Để biết thêm thông tin về các chi tiết của chính Tuân thủ PCI và tại sao nó quan trọng, hãy xem trang web này .

Có một số yêu cầu nhất định mà họ phải tuân thủ, trung tâm dữ liệu của họ phải được bảo mật về mặt vật lý cũng như kỹ thuật. Họ không thể có bất kỳ WAP nào không được mã hóa trên mạng của họ, v.v ... Không ai trong số này thực sự quan tâm đến bạn tuy nhiên có một số yêu cầu được mong đợi của các hệ thống thương mại để họ yêu cầu tuân thủ PCI. Một số trong những yêu cầu này bao gồm nhưng không giới hạn ở:

• Sử dụng mã hóa SSL trên bất kỳ yêu cầu thanh toán nào thông qua trang web của bạn.

• Trong mọi trường hợp, không nên có số thẻ tín dụng được lưu trữ ở bất kỳ đâu trong bất kỳ hệ thống nào của bạn, bao gồm các tệp nhật ký và thậm chí các đối tượng được tuần tự hóa.

• Các máy chủ ứng dụng giao tiếp với bộ xử lý thanh toán phải nằm sau một tường lửa được cấu hình tốt, chỉ cho phép số lượng cổng mở tối thiểu được yêu cầu.

• Chỉ nhân viên kỹ thuật thích hợp mới được phép truy cập vật lý hoặc từ xa vào các máy chủ ứng dụng này trên mạng của bạn.

• Khác...

Thông thường, hầu hết các bộ xử lý thanh toán sẽ cung cấp một công cụ trực tuyến có thể chạy trên mạng của bạn và xác định các sự cố có thể xảy ra khi trở thành PCI Tuân thủ. Việc làm việc với bộ xử lý thanh toán vẫn không phải là điều CẦN THIẾT hoặc BẮT BUỘC, nhưng bộ xử lý thanh toán có quyền tính phí bổ sung cho bạn nếu bạn sử dụng dịch vụ của họ và không đáp ứng các tiêu chuẩn Tuân thủ PCI.

Nhờ những ý tưởng từ các câu trả lời trước đó, tôi muốn đề xuất giải pháp mà tôi có bây giờ mặc dù; Tôi hy vọng điều này có thể mời một hoặc hai ý kiến ​​từ kiến ​​thức chu kỳ có mặt ở đây và giúp tôi cải thiện nó. Chỉ để làm rõ: Mặc dù các vấn đề quan trọng, câu hỏi của tôi không liên quan đến cách chọn Nhà cung cấp dịch vụ thanh toán (PSP), các yêu cầu PCI DSS hoặc ý nghĩa pháp lý của bất kỳ điều gì, nhưng chỉ là những cạm bẫy kỹ thuật mà người ta có thể vấp ngã khi thực hiện "trực tiếp" thay vì một mô hình "chuyển hướng" với bất kỳ PSP.

Điều kiện tiên quyết

Khách hàng đang ở giai đoạn anh ta nhập chi tiết thẻ tín dụng vào biểu mẫu của bạn. Tôi biết những gì anh ta nợ và số tiền và loại tiền tôi muốn tính vào thẻ tín dụng mà anh ta nộp.

Giải pháp (?)

1. Khi gửi biểu mẫu có chứa thông tin chi tiết về Thẻ tín dụng, tôi sẽ sử dụng Javascript để dừng hành động mặc định trên nút gửi (mà nếu JS hoặc AJAX không khả dụng, có thể chuyển đến trang lỗi để thông báo cho người dùng gần đây hơn trình duyệt ...)
2. Yêu cầu AJAX (được lặp lại bởi bộ đếm thời gian) sẽ gọi một kịch bản cập nhật trạng thái, chính nó kích hoạt quá trình xử lý thực tế trong một tệp riêng biệt; sử dụng "ign_user_abort () để ứng dụng khách đóng trình duyệt hoặc một cái gì đó
3. vì vậy các cuộc gọi AJAX, ví dụ như phương thức -> StatusUpdate () - nếu được gọi lần đầu tiên, nó sẽ bắt đầu quá trình và trả về "vui lòng chờ", trong các cuộc gọi tiếp theo, nó sẽ đánh giá một biến phiên hoặc một cái gì đó để cập nhật trạng thái
4. Tôi sẽ cập nhật bản ghi của người dùng trong cơ sở dữ liệu để đặt cờ "lockSession" thành "bị khóa" - nếu điều gì đó xảy ra trước khi mở khóa, người dùng sẽ được thông báo về lần đăng nhập tiếp theo để liên hệ với văn phòng để loại bỏ bất kỳ mớ hỗn độn nào có thể xảy ra .. .
5. chèn một bản ghi thanh toán vào DB với trạng thái "đã chuẩn bị"
6. Gửi yêu cầu tới PSP, sử dụng id đơn hàng của hồ sơ thanh toán đã chuẩn bị. Tùy thuộc vào PSP, yêu cầu có thể được gửi dưới dạng giao dịch bị trì hoãn (có nghĩa là nó sẽ không được giải quyết tự động)
7. cập nhật bản ghi đã chuẩn bị với trạng thái mới (nếu bị từ chối, mở khóa phiên và quay lại trang thanh toán; nếu thành công, hãy cập nhật với trạng thái "đã truyền")
8. Nếu thành công, chúng tôi sẽ không có tham chiếu auth và các chi tiết quan trọng khác từ PSP - vì vậy hãy gửi yêu cầu "giải quyết" tới PSP để tham chiếu auth thu được.
9. Nếu thành công, hãy cập nhật hồ sơ thanh toán thành đã hoàn thành (hoặc trong trường hợp của tôi, di chuyển và cập nhật nó từ PendingTransilities sang PaymentTransilities)
10. Xóa cờ "khóa" khỏi hồ sơ người dùng

Những ý kiến ​​khác

Hãy hiểu những điều trên như một lời mời để chia sẻ kiến ​​thức và ý tưởng của bạn - chúng chỉ là những ý tưởng cho đến nay!

Ghi nhật ký

Tôi rất đồng ý với các nerdklers khi đăng nhập - Tôi hiện đang xem xét sử dụng một số hình thức ghi nhật ký dựa trên tệp cho mọi giai đoạn của quy trình trên (và để giữ nhật ký trong vài ngày ngay cả khi đã hoàn tất và được xác minh - ai biết được. ..)

Giao dịch cơ sở dữ liệu

Tôi không chắc chắn tôi sẽ đồng ý với việc sử dụng các giao dịch cơ sở dữ liệu. Chúng tôi đang sử dụng MS SQL và với các cài đặt mặc định, mọi giao dịch sẽ được khôi phục khi mất kết nối. Và khi đặt giao dịch thành không tự động cam kết hoặc tự động khôi phục, người ta có thể kết thúc bằng một vài giao dịch DB mở và một số hàm ý về việc khóa bản ghi / bảng, v.v. Tôi nghĩ rằng tôi sẽ thích nhiều cập nhật hơn trong quá trình; nếu bất kỳ lỗi nào trong số đó (và do đó quá trình bị chấm dứt), người dùng vẫn sẽ bị ngăn không gửi lại giao dịch có thể hoàn thành (nhưng chưa được ghi lại) cho đến khi nó được giải quyết thủ công.

AJAX, chính trị

Tôi không hoàn toàn chắc chắn liệu chúng ta có cần xem xét các trình duyệt không hỗ trợ AJAX hay không. Tôi đoán dù sao đó cũng là một chủ đề "chính trị". Tôi nghĩ rằng chúng tôi có thể đủ khả năng để có được tự do trong kinh doanh của chúng tôi, những người khác có thể không.

AJAX, kỹ thuật

Tôi không chắc chắn về cách tiếp cận của mình với việc gọi một phương thức "StatusUpdate" một cách không đồng bộ, điều đó sẽ xảy ra trong lần gọi đầu tiên để kích hoạt quy trình thực tế. Nhưng tôi sẽ làm cho câu hỏi này trở thành một câu hỏi riêng biệt nếu tôi không tìm thấy những ví dụ hay - mà tôi đoán tôi có thể tìm thấy. Dù sao đi nữa, nếu bạn biết cách thực hành tốt nhất, xin vui lòng cho tôi (và những người khác) biết trong bình luận của bạn.

Suy nghĩ cuối cùng

Thật tuyệt nếu tôi có một ý nghĩ thậm chí từ xa tiếp cận từ "cuối cùng" - điều này nếu công việc đang tiến triển đối với tôi và tôi rất có nghĩa vụ đối với bất kỳ phản hồi nào và gợi ý thêm về cách cải thiện điều này.