Thanks for all the hard work you put into this! I know our dev community will love this. We were asked to tackle this specific problem several times back in November at the 1 year b-day party. It’s good to see this so far along already. The proposal is put together pretty well.
I do have some comments on places to make the spec better as well as a few questions.
1. The phrase “The payment is committed but not executed.” is confusing. The user actually ‘approves’ or ‘denies’ a request for payment. I didn’t resolve my own confusion until I studied the workflow diagram. I’d suggest that commit gets changed to approve.
2. APP_LOGIC_ERROR or APPLICATION_LOGIC_ERROR. One of these is a typo (I think the spec means to use APP_LOGIC_ERROR)
3. The init handler seems like a bit of overkill. I think the JS developers will be used to XHR and our own response code where Open|Commit|Cancel|Close can be communicated via a state in the object passed to the callback. This is the model chosen by Netlog, and seems to be good enough (http://en.netlog.com/go/developer/documentation/article=opensocialcreditsextension) . Further, one may not care about Open | Close, only Commit/Cancel. As a result, I imagine that many impls would pass null for the current proposal. Yes—I know that the Netlog mechanism rides on top of makeRequest. This even seems to be suggested by the workflow diagram with the ‘payCallback’ at step 20.
4. The workflow diagram should include where close and cancel would be triggered in the flow.
5. The spec should indicate the format of items being sent from the containeràapp server. Otherwise, it will be difficult for other containers to implement compatible versions.
6. Lots of references to a SIGNED request. The spec suggests RSA-SHA1. Why not HMAC-SHA1 since HMAC-SHA1 is used by OAuth?
7. Do we need to require SSL between the container and the app server? That is, can a man in the middle do something to the sent data to change the outcome? Right now, we aren’t signing the request body, so I assume that a MITM could change the outcome.
8. Can the RequestParameters.AMOUNT be expressed as a float? What type of precision is expected?
9. Object model: do we want to continue to use the Parameters model or should this be designed more like what we see with the Lightweight JS API? Instead of a map of params, I’d rather be able to submit an object that looked like this:
{amount:"20", message:"You want fries with that?", userdefParam1:"SuperSize"}
Or, is the map preferred?
10. Timestamp info doesn’t specify how to communicate the info. I think we should consider using UTC.
11. It seems a goal here is to only allow for payment for applications that have external development servers. Is this intentional? The current design prohibits two friends from exchanging a gift where the presence of the gift could be stored in the recipients appdata. I don’t have an opinion yet on whether this scenario is valuable, I just noticed it appears to be impossible with the proposal.
Thanks for all the hard work you put into this! I know our dev community will love this. We were asked to tackle this specific problem several times back in November at the 1 year b-day party. It's good to see this so far along already. The proposal is put together pretty well.
I do have some comments on places to make the spec better as well as a few questions.
1. The phrase "The payment is committed but not executed." is confusing. The user actually 'approves' or 'denies' a request for payment. I didn't resolve my own confusion until I studied the workflow diagram. I'd suggest that commit gets changed to approve.
2. APP_LOGIC_ERROR or APPLICATION_LOGIC_ERROR. One of these is a typo (I think the spec means to use APP_LOGIC_ERROR)
3. The init handler seems like a bit of overkill. I think the JS developers will be used to XHR and our own response code where Open|Commit|Cancel|Close can be communicated via a state in the object passed to the callback. This is the model chosen by Netlog, and seems to be good enough (http://en.netlog.com/go/developer/documentation/article=opensocialcreditsextension) . Further, one may not care about Open | Close, only Commit/Cancel. As a result, I imagine that many impls would pass null for the current proposal. Yes—I know that the Netlog mechanism rides on top of makeRequest. This even seems to be suggested by the workflow diagram with the 'payCallback' at step 20.
4. The workflow diagram should include where close and cancel would be triggered in the flow.
5. The spec should indicate the format of items being sent from the containeràapp server. Otherwise, it will be difficult for other containers to implement compatible versions.
6. Lots of references to a SIGNED request. The spec suggests RSA-SHA1. Why not HMAC-SHA1 since HMAC-SHA1 is used by OAuth?
7. Do we need to require SSL between the container and the app server? That is, can a man in the middle do something to the sent data to change the outcome? Right now, we aren't signing the request body, so I assume that a MITM could change the outcome.
8. Can the RequestParameters.AMOUNT be expressed as a float? What type of precision is expected?
9. Object model: do we want to continue to use the Parameters model or should this be designed more like what we see with the Lightweight JS API? Instead of a map of params, I'd rather be able to submit an object that looked like this:
{amount:"20", message:"You want fries with that?", userdefParam1:"SuperSize"}
Or, is the map preferred?
10. Timestamp info doesn't specify how to communicate the info. I think we should consider using UTC.
11. It seems a goal here is to only allow for payment for applications that have external development servers. Is this intentional? The current design prohibits two friends from exchanging a gift where the presence of the gift could be stored in the recipients appdata. I don't have an opinion yet on whether this scenario is valuable, I just noticed it appears to be impossible with the proposal.
Good point, we should definitely consider that case. Actually, the reference implementation allows the app to pass a null or empty checkout url, which could be used to indicate that they don't have external servers. Added a note in the doc to expand on this.
thanks!
-- sha-mayn
From: opensocial-an...@googlegroups.com [mailto:opensocial-an...@googlegroups.com] On Behalf Of Chris Chabot
Sent: Thursday, February 12, 2009 7:45 AM
To: Sha-Mayn Teh (郑韶敏)
Cc: opensocial-an...@googlegroups.com; Jian Cai ☑; Yizi Wu (吴伊自)
Subject: [opensocial-and-gadgets-spec] Re: Proposal: Virtual Currency API
Proposal looks great to me, hope we can have a productive discussion here, would be *very* exciting to have a standard payment API and have it live right away on 2 large social network sites!
Small suggestion btw: the feature xml linked refers to 'payment-processer.js' but the javascript file seems to be called 'pay-counter.js'.
-- ChrisOn Thu, Feb 12, 2009 at 4:21 PM, Sha-Mayn Teh (郑韶敏) <sha...@google.com> wrote:
Hi,
A few of us from the Google OpenSocial team have been working with 51.com in China on a proposal for payments/virtual currency, and we'd like to get your feedback. The goal is to allow app developers to develop apps using virtual currency and deploy their apps on different containers. The container handles the actual transfer of money from the user (via cash, credit cards, etc) into the fake currency, and apps can charge the user for virtual items, advanced features or VIP status. Two of the biggest social networks in China, Xiaonei and 51.com, have implemented REST-like APIs on their own (non-OpenSocial) platforms, and what we're proposing is an OpenSocial JavaScript API for them to use.
Our proposal (with link to a simple prototype) can be found here: http://docs.google.com/Doc?id=dfjcf7w4_10ddst9xd9We have a simple demo: http://www.unickway.org.cn:9002/gadgets/files/container/sample-payment.html
with sample code for the app and container: http://docs.google.com/Doc?id=dfjcf7w4_10ddst9xd9&hl=en#Demo_And_CodeAny feedback on our proposal will be appreciated, but the end goal would be: a single unified proposal for an OpenSocial REST/RPC API and JavaScript API for payments.
I know there are some other proposals/thoughts out there, including Netlog's credits extension (at http://en.netlog.com/go/developer/documentation/article=opensocialcreditsextension), so feel free to jump in!
-- sha-mayn
- Show quoted text -
Great proposal. I think most developers dream about a standardized
solution for payments and virtual currency.
Some feedback:
[1] Subscriptions. I'm pretty sure we can build a subscription model
on top of this, but should the concept of VIP "subscriptions", with
reoccurring charges be built in to the proposal?
[2] Mobile payments. Mobile payments are often an easy way for users
to pay. Is there anything in the proposal that would prevent mobile
payments? Or any other form of payments?
[3] Support. With any payment solution, there will always be fraud,
requests for charge backs etc. Is there anything about support that
can or should be standardized? Or should it be up to the container or
app developer to handle support? If it's up to the developer, then
how would the developer request a charge back if the payment was made
through the container's payment solution? Can the idea of a "refund"
be standardized?
[4] Setting different currency exchange rates for different
countries. We'd likely charge far less for a subscription in Brazil
than we would in the US, and we'd want to have a nice round exchange
rate from real cash to virtual currency in each country. How would
this be handled? How can we specify a different currency exchange
rate? Maybe this can be handled at the app level..
None of these necessarily have to be including in the spec, just as
long as there is nothing that prevents them in the spec. But I bring
them up for discussion, because these are the kinds of things devs
think about..
In general, i'm very pleased with this proposal as it's quite similar
to our current implementation.
We also have an object representing the payment, instead of a json
data object.
It's quite similar to an activity object.
Did we ever come to a conclusion on how to handle UI element flows in
osapi/oslite?