api for merchant sites to give our users credits for transactions

I am working on a commerce site that lets users get "points" for shopping at participating sites. right now they must scan a receipt in order to get points. We want to simplify this by introducing an API that other sites can use to integrate with ours. Our site has users that have accounts so the requires are as follows:

• let users log in to our site from the merchant order confirm page / checkout page
• after user makes a purchase, the merchant site must let our site know the purchaser's user id, transaction total and transaction id
• most important: the 开发者_StackOverflow中文版less work merchant sites need to do to implement this the better, we are talking really small businesses here without any full time web programmers.

Some ideas I have:

• obviously having a java webservice api is best, but might be asking to much for some merchants to implement it on their cookiecutter shopping cart sites.
• iframe our stuff in, but not sure how do get the transaction amount in securely
• javascript api.. also, pretty certain it cannot be secured.

I'll sketch a strawman hack solution. Ignoring security for now, presumably the flow could go something like this.

1. User goes to site X and purchases something
2. Before finalizing the purchase, they redirect to your log in page with GET/POST parameter transaction ID and a redirect URL
3. You log them in, creating a unique callback id passed via HTTP and redirect to their cart page
4. Transaction completed, they hit a REST API on your site to indicate the transaction is complete and include the cost

Taking into account security we need to look at the possible places where we can fake a transaction

1. Impostor passes in fake ID in step 2). This shouldn't be a problem since the client site presumably can verify the validity of a transaction ID
2. Impostor takes callback ID in #3 and passes it to API, creating a false transaction. For this we can encrypt the callback ID at the host server (in addition to whatever SSL security is between the webserver and the client), it is then decrypted at the client's site and passed (via SSL) unencrypted to the host's REST API.

In short, the client would need to be able to

1. Accept/generate parameters
2. Decrypt a string
3. Call an arbitrary URL to hit the REST interface (or have some way of notifying the host site of the callback, obviously not via redirect since this would reveal the ID).

One advantage to this approach is that 2/3 could be done asynchronously. If their hosting solution doesn't allow custom code, you could provide a script that would batch and send this at various intervals provided they log the information somewhere.