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

Question

Я работаю над коммерческим сайтом, который позволяет пользователям получать " баллов " за покупки на участвующих сайтах.Прямо сейчас они должны отсканировать квитанцию, чтобы получить очки.Мы хотим упростить это, введя API, который другие сайты могут использовать для интеграции с нашими.На нашем сайте есть пользователи, которые имеют учетные записи, поэтому следующие требования:

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

У меня есть несколько идей:

• , очевидно, с Java WebService API - лучший вариант, но некоторые продавцы могут попросить его реализовать его на своих сайтах корзины покупок cookiecutter.
• iframe наш материал, но не уверены, как получить транзакциюбезопасное количество
• javascript api .. Кроме того, почти наверняка его невозможно защитить.

Answer 1

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

1. Пользователь заходит на сайт X и что-то покупает
2. Перед завершением покупки они перенаправляют на вашу страницу входа с идентификатором транзакции GET / POST и URL-адресом перенаправления
3. Вы входите в систему, создавая уникальный идентификатор обратного вызова, переданный через HTTP, и перенаправляете на страницу их корзины
4. Транзакция завершена, они нажимают REST API на вашем сайте, чтобы указать, что транзакция завершена, и включают стоимость

Принимая во внимание безопасность, мы должны рассмотреть возможные места, где мы можем подделать транзакцию

1. Самозванец передает поддельный идентификатор на шаге 2).Это не должно быть проблемой, поскольку клиентский сайт предположительно может проверить действительность идентификатора транзакции
2. Impostor принимает идентификатор обратного вызова в # 3 и передает его в API, создавая ложную транзакцию.Для этого мы можем зашифровать идентификатор обратного вызова на хост-сервере (в дополнение к тому, какой SSL-протокол находится между веб-сервером и клиентом), затем он дешифруется на клиентском сайте и передается (через SSL) в незашифрованном виде в REST API хоста.

Короче говоря, клиент должен иметь возможность

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

Одним из преимуществ этого подхода является то, что 2/3 может выполняться асинхронно.Если их хостинговое решение не допускает пользовательский код, вы можете предоставить скрипт, который будет пакетировать и отправлять его через различные промежутки времени, если они где-нибудь сохранят информацию.