Facebook Canvas Async Payment error states

Question

question

apiech1 asked Sep 25, '16

Facebook Canvas Async Payment error states

I'm trying to implement Facebook Canvas Pay.

I'm doing these steps: StartPurchase, FB.Canvas.Pay, PayForPurchase, ConfirmPurchase

everything is working pretty well except for asynchronous payments. When I call ConfirmPurchase, they return an error condition that looks like this:

Failed by payment provider (PlayFabError(FailedByPaymentProvider, Failed by payment provider, 400 BadRequest - Details: ProviderErrorCode: | ProviderErrorMessage: | ProviderErrorDetails: | ProviderOrderId: | ))

PayForPurchase result returned state 'init' and the transaction is most likely pending in facebook's system.

if I keep calling ConfirmPurchase (the facebook testbed gives you a purchase that succeeds or fails after 30 seconds), I get the same error regardless of whether the transaction is still pending or has completed with an error. If the transaction succeeds, I get a success state and award correctly.

How do I tell "pending" from "failed" for asynchronous payments?

In-Game Economy

10 |1200

Attachments: Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Answer 1 · 2016-09-25T02:51:44Z

brendan answered Sep 25, '16

Have you had a chance to review this doc? https://api.playfab.com/docs/non-receipt-purchasing

Your steps are correct, but for one thing: ConfirmPurchase isn't what completes an asynchronous payment with Facebook, technically. There's a callback URL you set in your app which Facebook uses to inform us when the payment has been made. Once it has, we confirm that it's valid and then deposit the items in the player inventory.

However, it sounds like the ConfirmPurchase isn't giving you the info you need (you can use it to check if Facebook has completed the payment), so I'm opening a bug on this to check that we're passing back the right error/success notifications when you use this payment method. Thanks for calling that out - we'll get it fixed soon.

1

10 |1200

Attachments: Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

apiech1 commented · Sep 25, 2016 at 04:27 AM

@Brendan

Thank you for your prompt reply, on a weekend no less! I hadn't seen that doc and just checked it out now.

I'm porting an existing title to Facebook. The game is pretty simple and meant to be played single player / offline. It has Apple in app purchases which are handled entirely through iTunes, but Facebook Canvas Pay is a little more complicated. I signed up for PlayFab yesterday as a possible solution so I'm starting from square one here.

I have the Facebook purchase status callback set up. Is there any kind of callback I can make to the client from there? I decided my best option was to use exponential backoff polling for the status. I'm polling with ConfirmPurchase and I can't tell when it completes in an error state. Based on the documentation you linked, maybe I should make the IAPs reward a PlayFab "inventory" item that the client knows how to cash in?

Or if it takes an update to get that ConfirmPurchase functionality in I'd appreciate that.

Thanks again!

0 ·

Answer 2 · 2016-09-25T04:35:44Z

brendan answered Sep 25, '16

Ah, I see - yes, I would highly recommend using the economy system as designed. What you do is, create all the items in a catalog. For iTunes purchases, you should make sure that the ItemId for each purchase matches the Product ID in the iTunes catalog, as that's how we match them up from the receipt. Please do set a price in RM ("real money") for those items, but don't worry - the price stated in the receipt validation API call is the one we use for reporting, so that sale periods are accounted for without having to update everything in our service. The reason this is important for iTunes (and other mobile platforms) is because the purchase isn't really handled "entirely" by their process. What you're probably doing right now is the common process - you call from the client to see if the receipt is valid, and then (if so) call from the client to award the item(s). Thing is, that's trivially easy to cheat. The most common cheat is to use a Cut the Rope 2 receipt. It's valid, it's just not for your game. Using the full economy model in our service prevents those issues.

It's not really possible to create a callback for the client for the purchase completion (since the application may not even be running), but we will be enabling a publish/subscribe model later this year, which will give you the equivalent. For right now, the best way is to do an exponential backoff re-query, as you describe. I'm checking to see why the ConfirmPurchase call isn't getting you the info you need, so we should have that fixed soon. But in the meantime, rest assured that the purchase process will work fine if you've got it all running through our service (defined catalog, using receipt validation and the StartPurchase flow for non-receipt payments).

10 |1200

Attachments: Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

question