How to provide accurate prices with new Payment system

Question

According to new payment documentation available here if we want dynamic pricing we need to set up a script that FB will call saying "User wants to buy x your items and wants to pay in currency CC" and our script should return the price in that currency. What documentation is not clear about but our testing showed is that FB expects us to return the price of one item rounded to two decimals. So if FB asks my script "Tell me the price of 14 tokens in USD" and I want 14 tokens to cost 2USD I need to return round(2/14, 2) which is 0.14 and then FB will multiply this 0.14 with 14 and show the user that he needs to pay 1.96$.

So how am I supposed to make FB show the user that he needs to pay 2 dollars for 14 tokens?

What I (and probably a lot of others) am curious about, is: How do you get the new flow to work? I (like many others) am always getting a _1383005 ("App not allowed to use new flow")_ error... As for your problem: Since you are supposed to pass round(x, 2), I'd say that your only option is to **define** a product that contains exactly 14 tokens and costs exactly 2 dollars. — loptrinho, Jun 03 '13 at 11:57

score 0 · Accepted Answer · answered Jun 07 '13 at 10:31

Now that I managed to get access to the new payment flow (as FB made their "breking change announcement"), I can tell you how we managed to get around a similar problem.

Situation:
We are offering a number of products to a user that are individually generated at runtime, similar to your problem: one of those products might for example contain an amount of ingame currency for a fixed price. At another time the user might get an additional amount of currency for free, resulting in a product containing +x ingame currency, but for the same price.

Solution:
We define the product dynamically, i.e. we call a script page that renders the individual product. For this purpose, we provide a securely encrypted token that is sent with the FB.ui call as request_id. The product script now decrypts the token and - if security checks pass - renders the product by dynamically creating and outputting the og:product HTML...

Note:
Please make sure that the generated products og:url tag does exactly match the called url, e.g. if you create the product calling http://www.example.com/product.php?test=123&token=nkvadkfjgakajdvkaldhjf your product's meta for its url must look like this:

<meta property="og:url" content= "http://www.example.com/product.php?test=123&token=nkvadkfjgakajdvkaldhjf" />

Otherwise, Facebook will not be able to follow the redirect... Keep in mind: Every og:product must be self referencing, thus pointing to the exact url where it is called.

The drawback with the described procedure is that FB won't be able to cache your product as every used request_id has to be unique. But then the product is individually generated anyway, so why bother...

In short:
Just create a product dynamically that fulfills your needs and make it point to itself, using an amount of 1 instead of 14 and setting the final price to 2 USD.

<!DOCTYPE html>
<html>
  <head prefix=
    "og: http://ogp.me/ns#
     fb: http://ogp.me/ns/fb#
     product: http://ogp.me/ns/product#">
    <meta property="og:type"                   content="og:product" />
    <meta property="og:title"                  content="14 tokens" />
    <meta property="og:image"                  content="http://www.example.com/imageUrl.png" />
    <meta property="og:description"            content="You'll get 14 tokens here. Use them to your liking..." />
    <meta property="og:url"                    content="[exact_path_to_this_file_including_all_params]" />
    <meta property="product:price:amount"      content="2"/>
    <meta property="product:price:currency"    content="USD"/>
  </head>
</html>

How to provide accurate prices with new Payment system

1 Answers1