I am developing an application that uses FB Credits as a currency, however, my clients are going to be paying in their local currency (ILS, israeli sheqel).
I know the rate for 1 credit is 10 cents, however, the price in ILS seems to be changing according to changes in the exchange-rates of USD-ILS.
Is there a way to query Facebook Server to know the prices users are going to be charged in their local money? Like a way to query the pricelist. Many new users don't understand the concept of credits and i'd like to show them what they're about to pay in local money.
The Facebook Credits API doesn't have exchange rate information available. You could request this feature on their developer group. You're best bet would be to pull down an exchange rate feed (there are tons available if you search) and display that with a warning that it is just an estimated rate and that it is dependent on the actual exchange rate Facebook uses.
xe.com is a great feed , you can also pull data from yahoo or google finance
As stated by OffBySome, Facebook do not have exchange rate information available. Thinking about this, I can see why they don't have this as they do not want you to display the local currency price for items. Although at the moment Facebook Credits are relatively new, and there is a lot of confusion for end users, eventually when it becomes widespread there won't be these issues.
I would suggest for now (as that is what I have done - here one Facebook Credit is currently ~7p) that you just hard code in your app the price of 1 Facebook Credit in your local currency, and if required display this. I think one of the reasons why Facebook don't support this is that they didn't envisage apps using Credits to be restricted to one territory, however in reality not everything is a game to be used worldwide. :)
Just to sum this question up, I tried two methods. One was to pull the rate every 10 minutes from openexchange using this python function:
def update_ils_rate():
print "Updating ILS/USD exchange rate"
url = 'http://openexchangerates.org/latest.json'
response = requests.request('get', url)
content = response.content
data = loads(content)
return data['rates']['ILS']
However it seems that facebook credits calculates ILS(israeli sheqel) rate according to a different rate (calculations were off by a little). So we have decided to pull xml data from israel's central bank, using this function:
import requests, BeautifulSoup
def get_ils_rate():
response = requests.request('get', 'http://www.bankisrael.gov.il/currency.xml')
content = response.content
soup = BeautifulSoup(content)
currencies = soup.findAll('currency')
for c in currencies:
if c.currencycode.contents[0]=='USD':
return float(c.rate.contents[0])
Related
I have problem getting user local currency and usd-exchange rate from facebook, so this one: https://developers.facebook.com/docs/graph-api/reference/currency/
I'm trying to show my shop prices in local currency, just like fb shows prices in local currency in its own purchase dialog after facebook-purchase is launched.
I'm trying to get currency like this:
https://graph.facebook.com/v2.12/me?fields=id,name,currency&access_token=...
(Actually using Unity and Facebook's Unity SDK to do this, but exactly same thing happens when using url above.)
That have definitely worked before. I've also tried api version 3.2. It returns id and name, but no currency info of any kind. But it doesn't give any error message either, as it does with invalid fields.
I really can't find any useful info or help to this. Does getting currency require special permissions these days? But I can't find anything currency related from FB dev console App Review / Permissions and Features either.
Thanks!
Answering to my own question. It just seems that currency info is no longer available.
Starting from January 8th (2019) that field is no longer available for any apps:
https://developers.facebook.com/blog/post/2018/05/01/facebook-login-updates-further-protect-privacy/
There's discussion about this issue here, without any solution so far (may require having FB developer account to access):
https://developers.facebook.com/bugs/285780305453757/
There are some workarounds to get user currency like:
New way to detect Facebook API user currency
But that doesn't give you exchange rate to USD, so that isn't too helpful showing prices in local currency before Facebook's own purchase dialog is displayed.
Very unfortunate. Still, if someone knows way to get local currency and exchange rate that will surely match exchange rates used by FB, please let me know.
I know many developers are using linkshare.com as an affiliate to track app conversions for paid apps. Does linkshare.com provide conversion data for free apps? All signs point to no but I thought I would ask.
We want to be able to track particular marketing campaigns with referrer codes and see how many downloads result from each campaign.
Unfortunately no. "Sales" of free apps are not returned in either LinkShare's or TradeDoubler's report. You will, of course, see all of the other items the user bought during that 72 hour period that your affiliate cookie was active but those again will only be paid apps, music, movies, etc.
Even if you were using the Signature Tracking provided by LinkShare to track specific campaigns you are still going to have a hard time determining if the sale that is reported in your Signature Orders report was specifically your app or a competitors app at a similar price as the reporting is only at category level.
Good luck!
I have a web site using Facebook Connect where people have a strong incentive to create fake Facebook accounts and login multiple times in order to get more "votes" in my singing competition.
Anyways, I've come up with a strategy to identify these fake accounts and not let them use my site. (Haven't done the programming yet)
If their earliest wall post is more than 30 days old, then validate them.
If they have more than 20 friends, then validate them.
If their first profile picture is more than 30 days old, then validate them.
If their account has been phone verified, then validate them.
Number 4 is the one I'm having trouble with. One post I read says the GRAPH API has a verified field, but suggests that shows if the email has been verified (but not phone). This has proven a tough thing to search for. So I'm still unsure if this is possible.
Any comments on my strategy or help with #4 would be appreciated.
Thanks.
Actually the verified field should be what you are looking for. From the docs:
A user is considered verified if she takes any of the following
actions:
Registers for mobile
Confirms her account via SMS
Enters a valid credit card
We use verified and friend count to limit people. We even put those requirements into our legal terms so there's no misunderstanding.
Client looking into using QR codes in print advertising that will reward the visitor with a discount. Simplest solution (to the best of my knowledge) is to make the QR code point to a unique URL (ex. using a GET parameter for a "coupon code") that is used to store a cookie and then check for that cookie upon checkout to apply the discount.
Now most of the QR apps I've been looking at have embedded browsers. If the user scans the code and completes the purchase right within the app, I believe the above solution would work. But an ideal solution would allow the user to scan the code on the go and then visit the site up to X days later and still receive the discount. If a user returns to the site later they will probably use the mobile phone's standard browser app (i.e. Safari on iPhone) and not the app they originally used.
The answer to this question says that "each SDK app is given its own WebKit cache and cookie stores, so while cookies will persist within the same app, they aren't accessible betweeen apps." So it seems impossible to me to use the above solution to enable a user to scan a QR code and visit the site later and guarantee that a discount would be applied. I cannot think of any other solutions, but before I conclude that it simply cannot be done I wanted to see if there are any other solutions I am simply not thinking of (short of having the user create an account and store it server-side)
P.S. Obviously there are other devices besides iPhones but if I can't even get it to work for iPhones that would be enough of a deal breaker. In fact the variety of possibilities regarding mobile devices and QR apps makes me think there's a very good chance that it really can't be done.
There's no way to setup a website that will can automatically give the discount to returning visitors across different web clients on iOS. You'll need the end user's help.
You could have the QR code link to a special landing page that tells the enduser to bookmark the page to get the discount at a later date. If QR app can save a bookmark, the end user will come back through the QR app. If the QR app can not save a bookmark, the end user will view the page in Safari and bookmark it there.
You could have the end user register for the discount, and then send a discount code by e-mail. Merely asking for an e-mail address should be sufficient. When he returns to get the discount he will use the e-mail with the discount code.
The solution to this problem is not to tie discounts to browsers, but to humans. Humans tend to have the same address, and fairly often the same credit card number. These are things that are much more valuable to check than cookies. If a given billing address or credit card # has been used for a discount before, then deny the discount on the second usage. This will solve the problem 90% of the time (and nothing will beat about 90% of the time).
Cookies are a fine first step (low-hanging fruit and all that), and are fine to check if they happen to be there, but keep in mind your actual goal. You want a single discount per paying customer, not a single discount per app/device/blah-blah-blah. All the latter are proxies for the former. Focus on things that identify actual paying customers.
How do you get the total number of users in a Google Apps Domain? I'm aware of the "Retrieve All Users in Domain" call using the Google Provisioning API, but I'd rather not execute such an intensive call just to count up all the users. Is there a simpler way to do this?
I found a solution that isn't as resource-heavy as retrieving all users: The Google Reporting API can be used to get the total number of accounts in a Google Apps domain.
The Google Apps Admin Settings API allows you to retrieve both the current and maximum number of users in the domain:
https://developers.google.com/google-apps/admin-settings/#retrieving_the_current_number_of_users_in_a_domain
this would be preferable to the reports API as it's both lower in traffic and it's closer to real time (reports are only updated every 24 hours so it won't take into account users recently added).
You could try "Retrieve All Nicknames in Domain" which could save some bandwidth as it hopefully really only retrieves the nicknames, although I think this won't get you the exact count because "Retrieve All Nicknames for a User" seems to imply that a user can have multiple nicknames.
If you've got some test domain, also assure that retrieving all users really is too much overhead and keep in mind that depending on what you want to do, you can perhaps build some kind of cache around it that only does a full request after the cache is older than X.