Как интегрировать обработку платежей с приложением на базе GWT / GAE?

#java #google-app-engine #gwt #payment-processing

#java #google-app-engine #gwt #обработка платежей

Вопрос:

У меня есть приложение на основе GWT, которое развернуто в Google App Engine для Java. Приложение использует аутентификацию на основе учетных записей Google. Я сохраняю основную информацию о пользователе, такую как идентификатор электронной почты (из учетных записей Google), дату последнего входа и т.д. В хранилище данных GAE. Доступ к веб-сайту бесплатный. Любой может использовать его, используя свою учетную запись Google.

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

Вот некоторые из моих требований (но я гибок в отношении точной реализации):

Предлагаем 2 разных типа учетных записей — бесплатную и премиум.
Я не хочу сохранять в своей системе какую-либо информацию, связанную с кредитной картой. Я бы также предпочел не поддерживать сложную базу данных пользователей.
При первом входе в систему пользователь автоматически получает бесплатную учетную запись.
Пользователь должен «обновиться» до премиум-аккаунта, чтобы получить доступ ко всем функциям приложения.
Пользователь должен заплатить единовременную плату за обновление.

Учитывая эту информацию, у меня возникают следующие вопросы:

Подходит ли GAE для моих требований?
Какой платежный шлюз (Paypal, Google Checkout и т.д.) Был бы наиболее подходящим для моих требований?
Какой уровень интеграции требуется между моим приложением и платежным шлюзом? Я хотел бы сохранить минимальную информацию о пользователе в своем приложении. Я хочу сосредоточиться на разработке своего приложения и потратить минимум усилий на администрирование пользователей.
Нужно ли мне внедрять пользовательский механизм аутентификации или продолжать использовать учетные записи Google или другую аутентификацию на основе OpenID?
Какие еще вещи мне нужно учитывать?

Я буду признателен за любую помощь в этом. Спасибо.

Ответ №1:

Вообще говоря, нет абсолютно никаких причин, по которым вы не смогли бы сохранить текущее приложение и управление его учетной записью. Вы можете расширить свою учетную запись пользователя с помощью поля типа учетной записи, в котором указывается, является ли пользователь платежеспособным клиентом или нет. Если вам нужно отправлять счета, также сохраните контактную информацию пользователей (Paypal отправит ее вам вместе с платежными квитанциями)

Что касается конкретных поставщиков платежей. У меня есть только практический опыт работы с PayPal. Я бы не стал использовать их снова по нескольким причинам:

Их API не очень хорошо документированы, а часть документации неверна (или устарела).
Если вы мелкий игрок, поддержка осуществляется в основном через форумы. По сути, это означает, что вы предоставлены сами себе.
Некоторые API имеют серьезные пробелы и недостающую функциональность (например, вы можете создавать подписки, но не отменять их, если используете стандартные API платежей.
За пределами США и нескольких удачливых стран расширенные API недоступны. Итак, вы застряли с внедрением сервлета прослушивателя IPN, в то время как было бы гораздо предпочтительнее извлекать информацию при необходимости.

Все существующие Java-библиотеки PayPal, которые я нашел, используют функции Pro, которые недоступны большинству пользователей. Поскольку я не смог найти его больше нигде, я создал свой собственный сервлет IPN с открытым исходным кодом, но он очень незавершенный. Если на это есть спрос, я был бы готов улучшить его, просто дайте мне знать.

Что делает этот сервлет IPN, так это прослушивает входящие сообщения PayPal. Например, если пользователь подписывается, вы получите сообщение. Если пользователю выставлен счет (например, за ежемесячный цикл), вы получите сообщение. Если пользователь отменяет свою подписку, вы получите сообщение. Эти сообщения позволяют вам поддерживать тип учетной записи пользователя.

Если бы я сделал это снова, я бы, вероятно, использовал более продвинутый API подписки более высокого уровня, такой как Spreedly. Я слышал несколько хороших отзывов об API, и они довольно доступны. У меня нет реального опыта работы со Spreedly, так что это не одобрение.

1. @Peter — Я действительно ценю, что вы продолжаете мой комментарий в вашем блоге. Я просмотрел все публикации в вашем блоге, связанные с Paypal, и нашел их полезными. Я также просмотрел инструментарий PaypalX GAE Toolkit и нашел соответствующие примеры. Но мое основное сомнение — зачем использовать Adaptive Payment API вместо стандартной кнопки с перенаправлением — все еще остается. Смотрите мой комментарий под предыдущим ответом (выше). Пожалуйста, поделитесь своими мыслями, если у вас будет такая возможность. В любом случае, я думаю, что буду использовать ваш сервлет IPN. Поэтому любые улучшения, которые вы сделаете, будут высоко оценены. Спасибо.

2. Я провел некоторое первоначальное исследование различных API, но поскольку я могу использовать только стандартный, я не исследовал полностью другие. API адаптивных платежей — это полноценный веб-сервис. Если вы используете это, нет необходимости в перенаправлениях или обратных вызовах IPN-сервлетов. Это сделает ваш код чище и проще. Насколько я знаю, Adaptive Payments one также является самым современным из API PayPal. Имейте в виду, что это может вам немного обойтись. Если вы хотите использовать стандартный API, но вам требуется немного больше возможностей, ознакомьтесь с API экспресс-оформления заказа. Смотрите библиотеку NVP

3. Я все еще знакомлюсь с терминологией Paypal. 1. Что вы подразумеваете под «стандартным»? 2. Почему я не могу использовать стандартную кнопку оплаты на сайте? Это то, что вы подразумеваете под стандартом? 3. Что касается API адаптивных платежей, вы просмотрели образцы, предоставленные Paypalx GAE Toolkit? Они используют перенаправление и сервлет IPN нажмите здесь . Я чувствую, что API «Pay» должен мне подойти. 4. Связаны ли затраты с использованием адаптивных платежей? Я не видел никакой информации об этом. Можете ли вы пояснить это? Я прочитаю больше о Express Checkout и библиотеке NVP. Спасибо.

4. 1. существует «профессиональный» и «стандартный» платежный API. Pro предлагает более богатый API. 2. Вы можете использовать кнопки, они просто указывают на экран оплаты на серверах PayPal. 3. Я не исследовал инструментарий PayPal X toolkit, поскольку я живу в Бельгии, где я не могу использовать API адаптивных платежей. Я полагаю, вы можете объединить сервлет IPN с любой формой оплаты или API. По сути, PayPal будет отправлять обновления статуса сервлету. 4. Опять же, я не изучал это подробнее, поскольку не могу им пользоваться, но я полагаю, что вам нужен более дорогой тип учетной записи, чтобы иметь возможность использовать адаптивные платежи

5. Теперь все становится яснее. Я нашел эту ветку , в которой указано, что за использование адаптивных API не взимается специальная плата. На данный момент я склоняюсь к использованию простой кнопки, но если по какой-либо причине это не сработает, я попробую использовать адаптивные API. В обоих случаях я, вероятно, буду использовать ваш сервлет IPN. Теперь у меня есть 2 вопроса. 1. Какие обновления требуются вашему сервлету IPN (вы сказали, что он не завершен)? 2. Если я использую кнопку, могу ли я передать user_id в качестве «пользовательского» параметра и вернуть его в IPN для идентификации пользователя в моей системе? Спасибо.

Ответ №2:

GAE поддерживает такого рода приложения без каких-либо особых проблем; если вы предпочитаете Java, я бы выбрал Paypal с этим инструментарием, потому что Google Checkout Java API, похоже, не очень хорошо работает на GAE.

Вам понадобится механизм авторизации, чтобы проверить, что разрешено делать вашим пользователям на основе их разрешений.
В принципе, вам понадобятся следующие вещи:

Флаг membership состояния, который указывает, если пользователь премиум или нет; это значение должно быть установлено после уведомления о платеже
Система авторизации для проверки, может ли данный веб-обработчик использоваться текущим пользователем при чтении membership значения флага

Ознакомьтесь с этим замечательным руководством по безопасности Spring; оно охватывает:

Аутентификация с использованием учетных записей Google.
Установите ограничения контроля доступа на основе ролей, назначенных пользователям.

1. Привет, systempuntoout, спасибо за ваш ответ. Это продвинуло меня на один шаг вперед. Я уже видел руководство по безопасности Spring, но я не уверен, подходит ли оно для моего простого приложения, в котором всего 2 роли (исключая роль АДМИНИСТРАТОРА, которая автоматически предоставляется app engine). На данный момент у меня есть 2 вопроса. 1. Могу ли я не управлять авторизацией программно (для начала), если мое приложение довольно простое? Дайте мне знать, если я чего-то не понимаю. Я публикую второй вопрос в отдельном комментарии.

2. 2. Мне нужно более подробно изучить API Paypal X, но на данный момент я не могу понять, как идентификатор учетной записи Google (email Id) будет привязан к идентификатору Paypal пользователя. Насколько я понимаю, новый пользователь входит в мое приложение. Пользователь нажимает ссылку «Обновить сейчас» в приложении. Эта ссылка ведет пользователя в Paypal, где пользователь производит платеж. Paypal отправляет уведомление об успешном платеже обратно в мое приложение. Приложение обновляет роль пользователя до PREMIUM. Если это так, как это будет работать, то как запрос из моего приложения в Paypal и ответ от Paypal будут идентифицировать пользователя? Спасибо.

3. 1. вы можете закодировать декоратор или простой метод, который просто проверяет флаг членства 2. Для идентификации пользователя следует использовать user_id, а не email (который может измениться)

4. В # 2 я могу использовать user_id для идентификации пользователя, но мои сомнения все еще остаются. Позвольте мне объяснить еще раз. Допустим, пользователь1 нажимает «Обновить сейчас», переходит в Paypal, использует адрес электронной почты xyz@hotmail.com чтобы произвести платеж, и я получаю данные транзакции от Paypal, сообщающие, что человек с идентификатором электронной почты xyz@hotmail.com произвел платеж. Теперь, как я узнаю, что адрес электронной почты xyz@hotmail.com принадлежит пользователю 1? Возможно, пользователь не зарегистрировал свой идентификатор пользователя Paypal в моем приложении. Спасибо.

5. @DFB Вы изучали API Paypal X? Вы уверены, что можете передать дополнительный параметр user_ID в вызов Paypal? Таким образом, вы могли бы связать обратный вызов с конкретным пользователем.

Ответ №3:

Если вам нужен биллинг на основе подписки с бесплатными пробными версиями, купонами, повышением / понижением статуса плана, управлением Dunning и многим другим, тогда взгляните на Recurly.

Вы можете настроить, чтобы клиенты сохраняли свою платежную информацию на страницах, размещенных в Recurly, или использовать их прозрачный POST API для отправки платежной информации на свои серверы со страницы в вашем приложении GAE — оба решения позволяют избежать передачи конфиденциальных данных кредитной карты через ваши серверы, что упрощает соблюдение требований PCI.

Java API разработан не полностью, но его легко настроить под ваши конкретные требования с помощью JAXB. У меня нет моего кода, обернутого в проект с открытым исходным кодом, но я был бы готов поделиться фрагментами.

1. Привет, Рори, на данный момент у меня нет планов делать это сервисом на основе подписки. Это первый раз, когда я пытаюсь сделать такую вещь. Итак, я рассматриваю это как пилотный проект. Я не хочу подписываться на сторонний сервис, который поставляется с собственной абонентской платой. Но я ценю вашу помощь. Я учту ваше предложение в своих будущих проектах. Спасибо.