Архитектура для надежной обработки платежей

Question

Представьте себе 3 системных компонента: 1. Внешний веб-сервис электронной коммерции для обработки транзакций по кредитным картам 2. Локальная база данных для хранения результатов обработки 3. Локальный пользовательский интерфейс (или выигрышная услуга) для обработки платежей документа заказа клиента

Внешний веб-сервис, очевидно, не является транзакционным, поэтому как гарантировать: 1. результаты, которые в конечном итоге будут сохранены в базе данных при получении от веб-службы, даже если база данных в данный момент недоступна (проблема с сетью, тайм-аут дБ) 2. запретить клиентам обрабатывать заказ клиента во время оплаты, инициированной другим клиентом, но результаты еще не были успешно сохранены в базе данных (и ожидают в какой-то очереди восстановления)

Цель состоит в том, чтобы выполнить обработку с использованием не транзакционных компонентов системы и гарантировать, что транзакция не будет повторена другим процессом в случае сбоя.

(пожалуйста, посмотрите на это в контексте обработки платежей после продажи, когда несколько операторов могут попытаться обработать платеж вручную, а не в приложении для онлайн-оплаты)

Answer 1

Спросите обработчика платежей, могут ли они обнаружить дубликаты транзакций на основе предоставленного вами идентификатора заказа.Затем, если вы не можете сохранить ответ из-за сбоя базы данных, вы можете безопасно повторно отправить запрос, не опасаясь двойной зарядки (по крайней мере один PSP, который я использовал, возвратил тот же код ответа / аутентификации в этом сценарии вместе сотметка о том, что это дубликат).

В качестве альтернативы, просто установите флажок в вашем заказе непосредственно перед попыткой платежа и не пытайтесь выполнить платеж, если флаг уже установлен.Если во время оплаты возникает ошибка, вы можете исследовать и исправить данные на досуге.

Я не хотел бы идти по пути, пытаясь автоматически отменить заказ и повторно отправить его, поскольку это только сбивает с толку(например, что если отмена не удалась - повторить или нет?).Лучше всего придерживаться простой логики, чтобы, когда что-то пошло не так, вы точно знали, где стоите.

Answer 2

В любой системе, подобной этой, вам нужна надежная обработка ошибок и отчеты об ошибках.Это вдвойне верно, когда речь идет о работе с платежами, когда вы абсолютно не хотите случайно брать чьи-то деньги и не доставлять товар.

Поскольку вы передаете свою обработку платежей третьей стороне, вы 'в конечном итоге очень зависит от шлюза, имеющего надежную систему обработки ошибок и отчетности.

В общем случае вы передаете управление шлюзу платежей и запускаете задачу, которая ожидает ответа от шлюза, который либо 'платеж принят или платеж отклонен.Когда вы получаете этот ответ, вы переходите к следующему шагу в вашем процессе, и все хорошо.

Когда вы вообще не получаете ответ (время ожидания), или ответ недействителен, тогда как вы будете действоватьочень многое зависит от платежного шлюза:

• Если шлюз поддерживает его, отправьте запрос в стиле «отменить платеж».Если платеж отменен успешно, вы, вероятно, захотите отправить пользователя на страницу в стиле «извините, пожалуйста, попробуйте еще раз».

• Если шлюз не поддерживает отмену или у вас нетДля связи со шлюзом вам потребуется вручную (лично, например, по телефону) связаться с третьей стороной, чтобы выяснить, что пошло не так и как действовать.Чтобы помочь этому, вам нужно собрать как можно больше подробностей в журналах ошибок, таких как дата / время, идентификатор клиента, стоимость транзакции, идентификаторы продукта и т. Д.на вашем сайте (и оплата принимается), тогда вы намного больше контролируете ошибки, но вкратце, если вы не можете выполнить заказ, вам следует либо сбросить данные на диск (например, файл CSV для ручной обработки), либо связаться сшлюз для отмены платежа.

  Стоит также иметь систему для отслеживания ошибок по мере их возникновения, и, если возникает чрезмерное количество, подумайте, что должно произойти.Например, если это сайт с высоким трафиком, вы можете временно запретить другим клиентам размещать заказы во время расследования проблемы.

Answer 3

Распределенные сообщения.

Когда ваш платежный шлюз возвращается, отправьте сообщение в длительную очередь, которая гарантирует, что обработчик в конечном итоге получит его и обработает. Обработчик обновит базу данных. В случае сбоя в этот момент обработчик может оставить сообщение в очереди, отправить его в очередь или опубликовать альтернативное сообщение.

Если позже произойдет что-то, что сделает транзакцию недействительной, другое сообщение может быть поставлено в очередь для отмены изменения.

В последнее время довольно много разговоров о возможной согласованности и распространении сообщений. NServiceBus - это новый компонент hotness. Я предлагаю разобраться в этом, я знаю, что мы.