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

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

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

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

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

person mkoryak    schedule 19.03.2011    source источник
comment
Я не совсем понял вопрос, можно поподробнее?   -  person Daniel    schedule 19.03.2011
comment
просто переписал большую часть вопроса, чтобы сделать его более понятным.. надеюсь   -  person mkoryak    schedule 19.03.2011
comment
Я не уверен, как вы размещаете веб-сайт, но я бы предложил создать механизм API на языке программирования, таком как PHP, ROR и т. д.   -  person Daniel    schedule 19.03.2011
comment
Это, безусловно, решение, но для наших продавцов его внедрение может оказаться слишком дорогим.   -  person mkoryak    schedule 19.03.2011
comment
Вы бы создали API, а затем продавцы получили бы доступ к этому API?   -  person Daniel    schedule 20.03.2011
comment
в идеале, но некоторые продавцы используют любую корзину для покупок, которая поставляется с Dreamhost.. они не в состоянии интегрироваться с пользовательским API   -  person mkoryak    schedule 21.03.2011
comment
У меня очень похожие требования, и любая помощь в этом вопросе будет высоко оценена.   -  person jitendra    schedule 23.03.2011


Ответы (1)


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

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

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

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

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

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

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

person dfb    schedule 23.03.2011