in-app purchase with server

Question

I want to implement an in-app purchasing mechanism that supports both Google checkout and PayPal for purchasing virtual items in one of my Android apps. I read both references of these mechanisms but I still have one question as to what is the correct way to handle such purchases. The issue is that i'd like to manage a call to my own server as part of the purchase transaction and in case that call fails to cancel/rollback the entire transaction. If I first perform the purchasing transaction and only when its confirmed I call my own service, what should I do if it fails? If I first call my service and than try to handle the transaction and it fails I need to rollback my call (and what happens if the rollback fails? ??)

What is the correct way to manage it? Is there some way to create a multi-phase transaction that I'm missing?

Answer 1

AFAIK, It's not possible to "rollback" transaction. I think Google's logic as simple as possible: if you do have product (added to Developer Console) than you do can sell it.
When Google's market service tells you PURCHASE_STATE_CHANGED you should confirm transaction. Otherwise the app will receive PURCHASE_STATE_CHANGED till it is not confirmed, but the fact is that user already charged. And you can not rollback this transaction.
If your server can reject transaction, you should implement additional logic for such cases, for example:

• check if the product available BEFORE starting purchase;
• if product available - use "booking" for the product to be sure it is exist when purchase is done;
• and so on;
• otherwise you should tell user to contact support for refund.

Answer 2

Try to use the Google Checkout Mechanism provided for InApp Billing than PayPal SDK as it is the best way for getting the error responses of the transaction as well as RESTORE TRANSACTIONS if the app is deleted from the device and reinstalled again. Google Provides the Asynchronous Broadcast Notifications during the App Billing transactions. Purchase Types can be divided into Managed(per user account) and UnManaged.

Google provides the information here: In App Billing Overview as below:

1.Some in-app billing implementations may also use a private remote server to deliver content or validate transactions, but a remote server is not required to implement in-app billing.

2.A remote server can be useful if you are selling digital content that needs to be delivered to a user's device, such as media files or photos.

3.You might also use a remote server to store users' transaction history or perform various in-app billing security tasks, such as signature verification.

4.Although you can handle all security-related tasks in your application, performing those tasks on a remote server is recommended because it helps make your application less vulnerable to security attacks.

So, Finally I would like to recommend you the Google InApp Billing Implementation over other third-party payment process.

Answer 3

If you are still looking for a way of implementing a payment method handled by Google you can find a detailed description on how to implement Android Market In-app Billing here:

http://developer.android.com/guide/market/billing/index.html

Answer 4

I've never used Google Checkout before, only PayPal.

What you might be looking for is the PayPal Payments Pro SDK.

This lets your server become the face of the paying transaction (and not the PayPal site like the normal Checkout express).

You need to implement a 2-phase commit mechanism.

I can recommend two different approaches:

a) You could start the purchase process on your server and leave it in a middle "uncommited" status in the database. You call PayPal from your server so PP can process your call, and when you have the response from PP, and if the response means that the payment was accepted, you commit your purchase. The problem with this approach is that your application need to take a decition of completing or rejecting the transaction at that point, and that is not how a real world purchase transaction might behave. PayPal might sometimes response something different than just plain OK/Error, the payment can be pending, or it can be OK with warning.

b) Even more reliable is letting PayPal notify you about the payment status.

You make the same flow as described before with a change. Once PayPal processes the payment and give you a positive answer, you store the transaction ID in your database but don't commit anything. Only tell the user that the transaction was completed.

As part of the call to the PayPal server, there is a parameter that you can use, that parameter is called the IPN Listener URL.

IPN means Instant payment notification, is a call back to your server, originated by PayPal, in which your application will get instant information about your payment status.

This is really important as a pending transactions might become accepted or rejected. Even an accepted transaction might be rollback-ed by you or by a claim suited by your purchaser to PayPal.

Let me know if you need more information on how to implement the PP IPN Listener.