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

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

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

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

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

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

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

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


java payment-processing google-app-engine gwt
person DFB    schedule 23.05.2011    source источник

Ответы (3)


arrow_upward
3
arrow_downward

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

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

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

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

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

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

person Peter    schedule 25.05.2011
comment
@Peter - я очень ценю ваше продолжение моего комментария в вашем блоге. Я просмотрел все сообщения, связанные с Paypal в вашем блоге, и нашел их полезными. Я также ознакомился с набором инструментов PaypalX GAE Toolkit и нашел соответствующие образцы. Но мое основное сомнение - зачем использовать Adaptive Payment API вместо стандартной кнопки с переадресацией - все еще остается. Смотрите мой комментарий под предыдущим ответом (выше). Пожалуйста, поделитесь своими мыслями, если у вас есть шанс. В любом случае я думаю, что буду использовать ваш сервлет IPN. Поэтому любые улучшения, которые вы делаете, будут высоко оценены. Спасибо. - person DFB; 25.05.2011
comment
Я провел некоторое первоначальное исследование различных API, но, поскольку я могу использовать только стандартный, я не исследовал полностью другие. Adaptive Payments API — это полноценный веб-сервис. Если вы используете его, нет необходимости в перенаправлениях или сервлетах обратного вызова IPN. Это сделает ваш код чище и проще. Насколько я знаю, Adaptive Payments также является самым современным из API PayPal. Имейте в виду, что это может стоить вам немного. Если вам нужен стандартный API, но вам требуется немного больше свободы действий, попробуйте API Express Checkout.См. библиотеку NVP - person Peter; 26.05.2011
comment
Я все еще знакомлюсь с терминологией Paypal. 1. Что вы подразумеваете под «стандартным»? 2. Почему я не могу использовать стандартную кнопку оплаты через веб-сайт? Это то, что вы имеете в виду под стандартом? 3. Что касается Adaptive Payments API, смотрели ли вы образцы, предоставленные Paypalx GAE Toolkit? Они используют перенаправление и сервлет IPN нажмите здесь. Я чувствую, что Pay API должен соответствовать всем требованиям для меня. 4. Взимается ли плата за использование адаптивных платежей? Я не видел никакой информации об этом. Вы можете это прояснить? Я почитаю больше об экспресс-оплате и библиотеке NVP. Спасибо. - person DFB; 26.05.2011
comment
1. есть про и стандартные платежные API. Pro предлагает более богатый API. 2. Вы можете использовать кнопки, они просто указывают на экран оплаты на серверах PayPal. 3. Я не исследовал инструментарий PayPal X, так как живу в Бельгии, где не могу использовать Adaptive Payments API. Я считаю, что вы можете комбинировать сервлет IPN с любой платежной формой или API. По сути, PayPal будет отправлять обновления статуса на сервлет. 4. Опять же, я не изучал это дальше, так как не могу его использовать, но я считаю, что вам нужен более дорогой тип учетной записи, чтобы иметь возможность использовать адаптивные платежи. - person Peter; 26.05.2011
comment
Теперь все становится яснее. Я нашел эту тему, в которой указано, что за использование Adaptive API не взимается специальная плата. На данный момент я склоняюсь к использованию простой кнопки, но если это по какой-либо причине не сработает, то я попробую использовать Adaptive API. В обоих случаях я, вероятно, буду использовать ваш сервлет IPN. Теперь у меня 2 вопроса. 1. Какие обновления нужны вашему сервлету IPN (вы сказали, что он не закончен)? 2. Если я использую кнопку, могу ли я передать user_id в качестве пользовательского параметра и вернуть его в IPN для идентификации пользователя в моей системе? Спасибо. - person DFB; 26.05.2011
comment
1. Функциональных проблем нет. Но это довольно грубо: во-первых, в настоящее время он извлекает только те поля, которые мне нужны. Однако расширить это тривиально. Во-вторых, учитывая то, что я знаю сейчас, я хотел бы еще раз взглянуть на архитектуру. И наконец, мне действительно нужно получить этот Mavenized и в репозиторий Maven для легкой интеграции. 2. Да, вы просто добавляете настраиваемое поле в качестве скрытого поля на кнопку. Имейте в виду, что по соображениям безопасности вы можете не захотеть раскрывать идентификатор пользователя (но использовать одноразовый ключ). - person Peter; 27.05.2011
comment
Конечно, понял. Теперь я собираюсь начать прототипировать это в среде Sandbox и посмотреть, как это работает. Было бы здорово, если бы вы улучшили свой сервлет. А пока я буду использовать версию, которая у вас уже есть. Буду на связи (здесь и в вашем блоге). Большое спасибо за терпеливые ответы на все мои вопросы. - person DFB; 27.05.2011

arrow_upward
1
arrow_downward

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

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

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

Взгляните на это отличное Учебник по весенней безопасности; это покрывает:

  • Аутентификация с использованием учетных записей Google.
  • Настройте ограничения контроля доступа на основе ролей, назначенных пользователям.
person systempuntoout    schedule 23.05.2011
comment
Здравствуйте, systempuntoout, спасибо за ваш ответ. Это продвинуло меня на один шаг вперед. Я уже видел учебник Spring Security, но я не уверен, подходит ли он для моего простого приложения, которое имеет только 2 роли (исключая роль ADMIN, которая автоматически предоставляется движком приложения). У меня есть 2 вопроса на данный момент. 1. Могу ли я не управлять авторизацией программно (для начала), если мое приложение довольно простое? Дайте мне знать, если я что-то упустил. Второй вопрос пишу отдельным комментарием. - person DFB; 23.05.2011
comment
2. Мне нужно более подробно изучить API Paypal X, но на данный момент я не могу понять, как идентификатор аккаунта Google (идентификатор электронной почты) будет привязан к идентификатору пользователя Paypal. Насколько я понимаю, в мое приложение входит новый пользователь. Пользователь щелкает ссылку «Обновить сейчас» в приложении. Эта ссылка ведет пользователя в Paypal, где пользователь производит платеж. Paypal отправляет уведомление об успешном платеже обратно в мое приложение. Приложение обновляет роль пользователя до PREMIUM. Если это так, то как запрос от моего приложения к Paypal и ответ от Paypal идентифицируют пользователя? Спасибо. - person DFB; 23.05.2011
comment
1. вы можете написать декоратор или простой метод, который просто проверяет флаг членства 2. Вы должны использовать user_id для идентификации пользователя, а не электронной почты (это может измениться) - person systempuntoout; 23.05.2011
comment
В № 2 я могу использовать user_id для идентификации пользователя, но мои сомнения все еще остаются. Позвольте мне объяснить снова. Допустим, пользователь 1 нажимает «Обновить сейчас», переходит в Paypal, использует адрес электронной почты [email protected] для совершения платежа, и я получаю информацию о транзакции от Paypal, сообщающую, что человек с идентификатором электронной почты [email protected] совершил платеж. . Теперь, как я узнаю, что адрес электронной почты [email protected] принадлежит пользователю user1? Пользователь, возможно, не предварительно зарегистрировал свой идентификатор пользователя Paypal в моем приложении. Спасибо. - person DFB; 24.05.2011
comment
@DFB Вы изучали API Paypal X? Вы уверены, что можете передать дополнительный параметр user_ID в вызов Paypal? Таким образом, вы можете связать обратный вызов с конкретным пользователем. - person systempuntoout; 24.05.2011
comment
Я читал различные документы Paypal, но у них так много разных API. Я не уверен, какой из них подходит для моего требования. Я действительно хочу, чтобы все было просто: пользователь нажимает кнопку, делает разовый платеж на веб-сайте Paypal, мое приложение получает IPN и обновляет базу данных пользователей. Это все. На какой API мне следует обратить внимание? Большое спасибо за Вашу помощь. - person DFB; 24.05.2011
comment
Paypal X, кажется, предлагает только адаптивные платежи, посмотрите на это. - person systempuntoout; 24.05.2011
comment
Это непросто, но возможно. Если вы используете стандартные кнопки, вы можете добавить настраиваемое поле. Это позволит вам связать учетную запись пользователя в вашем приложении с платежом. Однако убедитесь, что вы также сохранили идентификатор подписчика (subscr_id), потому что регулярные платежи больше не будут иметь это настраиваемое поле. - person Peter; 25.05.2011
comment
Я прочитал Adaptive API Guide, но не могу понять одну основную вещь. Зачем мне нужно использовать API? Почему я не могу использовать стандарт оплаты через веб-сайт (перенаправление со стандартной кнопкой), как описано здесь. Если я не собираюсь использовать подписки/регулярные платежи, а мне нужен только разовый платеж, то что мне дает Adaptive Payment API? Извините, если этот вопрос звучит слишком элементарно. Спасибо за помощь. - person DFB; 25.05.2011

arrow_upward
0
arrow_downward

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

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

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

person Rori Stumpf    schedule 25.05.2011
comment
Здравствуйте, Рори, на данный момент у меня нет планов сделать это услугой на основе подписки. Это первый раз, когда я пытаюсь сделать что-то подобное. Так что я рассматриваю это как пилотный проект. Я не хочу подписываться на стороннюю услугу, которая поставляется с собственной абонентской платой. Но я ценю вашу помощь. Я учту ваше предложение для своих будущих проектов. Спасибо. - person DFB; 26.05.2011