如何将支付处理与基于 GWT / GAE 的应用程序集成？
我有一个基于 GWT 的应用程序，部署在 Google App Engine for Java 上。该应用程序使用基于 Google 帐户的身份验证。我正在 GAE 数据存储中维护基本的用户信息，例如电子邮件 ID（来自 Google 帐户）、上次登录日期等。访问该网站是免费的。任何人都可以通过他/她的 Google 帐户使用它。
展望未来，我希望将其变成一项付费服务。然而，我对建立和运营电子商务网站的经验为零。所以我的问题可能有点含糊。我需要一些关于如何去做的指导。
以下是我的一些要求（但我对具体实施很灵活）：
- 提供 2 种不同类型的帐户 - 免费和高级。
- 我不想在我的系统中保留任何信用卡相关信息。我也不想维护一个复杂的用户数据库。
- 当用户首次登录时，他/她会自动获得一个免费帐户。
- 用户必须“升级”到高级帐户才能访问应用程序的所有功能。
- 用户必须支付一次性费用才能升级。
鉴于此信息，我有以下问题：
- GAE 适合我的要求吗？
- 哪种支付网关（Paypal、Google Checkout 等）最适合我的要求？
- 我的应用程序和支付网关之间需要什么级别的集成？我想在我的应用程序中保留最少的用户信息。我想专注于应用程序开发，并希望在用户管理上花费最少的精力。
- 我是否需要实施自定义身份验证机制或继续使用 Google 帐户或其他基于 OpenID 的身份验证？
- 我还需要考虑哪些其他事情？
我将不胜感激对此的任何帮助。谢谢。
I have a GWT based app, which is deployed on Google App Engine for Java. The app uses Google Accounts based authentication. I'm maintaining basic user information such as email id (from Google Accounts), last login date etc. in the GAE datastore. The access to the website is free. Anyone can use it using his/her Google Account.
Going forward, I would like to make it a paid service. However, I have zero experience with setting up and operating an e-commerce website. So my question may be a bit vague. I need some guidance on how to go about it.
Here are some of my requirements (but I'm flexible on the exact implementation):
- Offer 2 different types of account - free and premium.
- I do not want to maintain any credit card related information in my system. I would also prefer to not maintain an elaborate user database.
- When a user first logs in, he/she automatically gets a free account.
- User has to "upgrade" to a premium account to access all features of the application.
- User has to pay a one-time fee to upgrade.
Given this information, I have the following questions:
- Is GAE suited for my requirements?
- Which payment gateway (Paypal, Google Checkout etc.) would be most suitable for my requirements?
- What level of integration is required between my app and the Payment gateway? I would like to maintain minimal user information in my app. I want to focus on my application development and want to spend minimal effort on user administration.
- Would I need to implement a custom authentication mechanism or continue to use Google Accounts or another OpenID based authentication?
- What other things do I need to consider?
I'll appreciate any help on this. Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
一般来说，您完全没有理由无法保留当前的应用程序及其帐户管理。您可以使用帐户类型字段来扩展您的用户帐户，该字段存储用户是否是付费客户。如果您需要发送发票，还需要存储用户的联系信息（Paypal 会将其与付款收据一起发送给您）
就特定的支付提供商而言。我只有 PayPal 的实际操作经验。我不会再次使用它们有几个原因：
因此，您必须实现 IPN 侦听器 servlet，而我发现的所有现有 PayPal Java 库都使用大多数用户无法使用的 Pro 功能，而 。在其他地方找不到它，我创建并开源了我自己的 IPN servlet 但它还没有完成。如果有需求，我愿意改进它，请告诉我
这个 IPN servlet 的作用是监听传入的 PayPal 消息。如果用户按月付费，您将收到一条消息；如果用户取消订阅，您将收到一条消息。这些消息允许您维护用户的帐户类型。
如果我再这样做，我可能会使用更高级和更高级别的订阅 API，例如 Spreedly< /a>.我听说过一些关于 API 的好消息，而且它们的价格相当实惠。我没有使用 Spreedly 的实际经验，所以这不是一个认可。
Generally speaking, there's absolutely no reason why you wouldn't be able to keep the current application and its account management. You can extend your user account with an account type field that stores whether the user is a paying customer or not. If you need to send invoices, also store the users contact information (Paypal will send this to you together with payment receipts)
As far as specific payment providers is concerned. I only have practical hands-on experience with PayPal. I would not use them again for a few reasons:
All existing PayPal Java libraries I have found use the Pro features that are not available to most of the users. Because I couldn't find it anywhere else, I have created and open sourced my own IPN servlet but it is very unfinished. If there is a demand for it, I'd be willing to improve it, just let me know.
What this IPN servlet does is listen to incoming PayPal messages. For instance, if a user subscribes, you'll get a message. If a user is billed (for instance on a monthly cycle), you'll get a message. If a user cancels his subscription you'll get a message. Those message allow you to maintain the account type of the user.
If I'd do it again, I would probably use a more advanced and higher level subscription API, such as Spreedly. I've heard some good things about the API and they are pretty affordable. I have no actual experience with Spreedly, so this is not an endorsement.
GAE支持此类应用程序没有任何特殊问题；如果您选择的语言是 Java，我会选择 Paypal 以及这个工具包，因为Google Checkout Java API 似乎运行得不太好关于GAE。
您需要一个授权机制来检查您的用户根据其权限可以执行哪些操作。
基本上，您需要以下内容：
membership状态，指示用户是否为高级用户；这应该在付款通知之后设置membership标志值，当前用户可以使用给定的 Web Handler
查看 这个很棒的 Spring Security 教程；它涵盖：
GAE supports this kind of applications without any particular problem; if your language of choice is Java, I would pick Paypal with this toolkit because Google Checkout Java API does not seem to work very well on GAE.
You would need an Authorization mechanism to check what your users are allowed to do based on their permissions.
Basically you would need the following things:
membershipstatus that indicates if a user is Premium or not; this should be set after the payment notificationmembershipflag value, a given Web Handler can be consumed by the current user
Have a look to this great Spring Security tutorial; it covers:
如果您需要基于订阅的计费，包括免费试用、优惠券、计划升级/降级、催款管理等，请查看 重复。
您可以选择让客户在 Recurly 托管的页面上维护其账单信息，或使用其透明 POST API 发布账单从您的 GAE 应用程序中的页面将信息发送到他们的服务器 - 两种解决方案都避免通过您的服务器传递敏感的信用卡数据，这使得 PCI 合规性变得容易。
Java API 尚未完全开发，但可以使用 JAXB 轻松构建以满足您的特定需求。我没有将我的代码封装到开源项目中，但愿意分享片段。
If you need subscription based billing with free trials, coupons, plan upgrades/downgrades, Dunning management and a whole lot more then take a look at Recurly.
You can choose to have customers maintain their billing information on pages hosted by Recurly, or use their Transparent POST API to post billing info to their servers from a page in your GAE app - both solutions avoid passing sensitive credit card data through your servers, which makes PCI compliance easy.
The Java API is not fully developed but it's easy to build out for your specific requirements using JAXB. I do not have my code wrapped into an open source project but would be willing to share snippets.