Disputes & Chargebacks

This document discusses disputes, chargebacks and refunds with Facebook Payments.

User Dispute Process and Policy

Facebook User Dispute Philosophy

Facebook's philosophy around user support is that for issues where users are likely to request a refund back to their funding source, Facebook should provide primary support. When users have an in-game purchasing issue or do not receive the desired item or currency, they should be routed directly to the developer. In these cases, the developer is best equipped to satisfy these users by issuing more in-game items, refunding the Facebook Payments, or clarifying an item delivery delay.

How Users Dispute a Previous Purchase

The dispute resolution flows give the user and the developer an easy way to interact regarding a previous payment made using Facebook Payments.

There are currently two ways for a user to dispute a previous purchase directly with a developer:

I. Facebook Payments Support Center

From a dynamic contact form in our help center, users are able to identify their issue by selecting from a series of questions. Depending on the users' selections, they are directed to the appropriate contact, either Facebook or the developer.

Below is an example endpoint of what the Facebook Payments Support Center developer-side dispute looks like from a user's perspective:

II. In-App Dispute Flow

There is a link at the bottom of the application canvas page for apps that are using our payments: "Report/Contact this App". When users click the link they are prompted with choices, the third of which is "Dispute ...".

Below is an example flow of what the in-app dispute process looks like from a user's perspective:

In both the in-app and support center dispute flows, if a user selects an issue that is best handled by the developer, the end result is the following:

1. Brings up the order-selection dialog box where the user chooses the orders from the past 30-days that he wants to dispute. The follow-up form requires the user to input a free text reason for the dispute.
2. Upon completion, an e-mail is sent to the developer and the user setting expectations that the developer is responsible for responding and resolving the issue.

How Developers Resolve User Disputes

For both of these dispute flows, when a user disputes an order, a 'payments_status_update' notification with 'disputed' status is sent to the application's payments_callback_url.

This is consistent with other status-update notifications sent to the application on order-state transitions. The application can also query the disputed orders using the /payments API.

As a developer, you should review the user dispute and issue a refund if appropriate. The developer owns the interaction with the user at this point. You can resolve the dispute in two ways:

• To refund - By calling the /[order id] API to refund the order, you must provide the appropriate order_id, status=refunded, in addition to specifying the reason for your refund in the 'comment' param.
• To settle - If you are satisfied that the user understands the charge, you can resolve the dispute by calling the /[order id] API with the order-id, status=settled, and specify the reason as the comment in the params.

Note:

• Specifying the reason is required in this case to provide a record on why you chose to resolve the dispute without refunding the user.
• You can only move an order to status=refunded up to 60 days after the initial transaction is completed.

Sample Email from Dispute

From: developer <noreply@facebookmail.com>

I never received my hat!

***********************************
User Information:
User ID: 221159
User Name: Daniel Schultz
User Email: foo@bar.com
Browser: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20100101
Type of Message: Credits Dispute
***********************************

Example Disputed Order Object

After order was just placed:

{
   "id": "9006187786070",
   "from": 221159,
   "to": 221159,
   "amount": 1,
   "status": "settled",
   "application": {
      "name": "SampleApp",
      "canvas_name": "fbdschultzpayments",
      "namespace": "fbdschultzpayments",
      "id": "128163550571392"
   },
   "country": "US",
   "created_time": "2011-11-16T19:39:52+0000",
   "updated_time": "2011-11-16T19:39:55+0000"
}

After order was disputed by user:

{
   "id": "9006187786070",
   "from": 221159,
   "to": 221159,
   "amount": 1,
   "status": "disputed",
   "application": {
      "name": "SampleApp",
      "canvas_name": "fbdschultzpayments",
      "namespace": "fbdschultzpayments",
      "id": "128163550571392"
   },
   "country": "US",
   "created_time": "2011-11-16T19:39:52+0000",
   "updated_time": "2011-11-16T19:43:52+0000"
}

Graph API call used to refund order:

https://graph.facebook.com/ORDER_ID?access_token=TOKEN&
     status=refunded&message=refunding%20order&method=post

After order was refunded by developer:

{
   "id": "9006187786070",
   "from": 221159,
   "to": 221159,
   "amount": 1,
   "status": "refunded",
   "application": {
      "name": "SampleApp",
      "canvas_name": "fbdschultzpayments",
      "namespace": "fbdschultzpayments",
      "id": "128163550571392"
   },
   "country": "US",
   "created_time": "2011-11-16T19:39:52+0000",
   "updated_time": "2011-11-16T19:45:18+0000"
}

Refunds & Chargebacks

Facebook Initiated Refunds and Effect on Developer Revenue

Facebook handles all primary support related to disputes where users request a refund directly back to their credit card.

For all non-fraud disputes, Facebook reviews a user's refund request on a case-by-case basis. The two main types of non-fraud disputes are friendly fraud and user confusion. Our qualitative investigation examines factors including previous orders, spending frequency, and account level details. Facebook will refund the charges only if the user's reason for disputing are deemed appropriate to receive a full reversal. Facebook monitors refund rates to protect against users who might attempt to defraud developers or Facebook by abusing the dispute resolution process.

Facebook will always refund a user for fraudulent charges made with his funding instrument on our Platform. Doing so prevents chargebacks and builds trust with good users who may fall victim to fraud.

Below is how we simply classify refunds:

• Non-fraud dispute: User request for monetary refund related to mistaken purchase or misuse of financial instrument by family or friend.
• Malicious fraud charge dispute: Unauthorized purchase associated with a stolen financial instrument or compromised account.

Facebook will pass on the cost of refunds to you if they happen within 90 days of the original transaction.

Chargebacks Affect on Developer Revenue

A chargeback occurs when users of your app contact their bank directly (e.g., credit card company or PayPal) to dispute a charge. A chargeback can happen for a variety of reasons, including unauthorized use of a financial instrument, double billing, or non-receipt of a virtual good.

Facebook will pass on the cost of chargebacks to you if they happen within 90 days of the original transaction. Beyond 90 days, Facebook will be responsible for the chargebacks unless:

1. We determine you accepted that Facebook payment after breaching Facebook rules or policies.
2. Your chargeback rate for any one of the prior three months exceeds 5% of your total transaction volume for that month.

Tracking Chargebacks and Refunds

You can keep track of the number of chargebacks for which you are held liable through the daily reports we send you. To prevent chargebacks and refunds, we recommend that you log detailed information about each transaction so that you can easily investigate if a problem is reported.

By accessing the Order API for reversed transactions, you can query the reasons for the reversals. We encourage you to look for patterns among these transactions.

Refund Reason Codes

If you issue a HTTP GET request to /ORDER_ID?status=refunded to see the set of orders that have been refunded. If the order has been refunded by Facebook, we will ping your callback with a payments_status_update for the order in questions with a status of refunded. In addition, there will be an additional field returned called refund_reason_code with one of the following values:

In addition to these extended refund codes Facebook also issues an HTTP request to your callback with a payments_status_update method containing the order ID as well as the refunded status to notify you we have refunded this users order.

Sample callback issued when Facebook refunds an order:

    {
       "signed_request":"Fs88anlf3...",
       "order_details":"{
         "order_id":9006136047935,
         "buyer":221159,
         "app":128163550571392,
         "receiver":221159,
         "amount":1,
         "time_placed":1320966823,
         "update_time":1323714386,
         "data":"",
         "items":[
           {
              "item_id":"0",
              "title":"A Facebook Hat",
              "description":"The coolest hat you\\'ve ever seen.",
              "image_url":"http:\\/\\/www.facebook.com\\/images\\/gifts\\/740.png",
              "product_url":"http:\\/\\/www.facebook.com\\/images\\/gifts\\/740.png",
              "price":1,
              "data":""
           }
        ],
        "status":"refunded"
    }",
       "status":"refunded",
       "order_id":"9006136047935",
       "method":"payments_status_update"
    }

Call getOrder via graph API to get all info around an order ID:

https://graph.facebook.com/ORDER_ID?status=refunded&access_token=ACCESS_TOKEN

Example Output:

{
   "id": "9003976483685",
   "from": {
      "name": "Daniel Schultz",
      "id": "221159"
   },
   "to": {
      "name": "Daniel Schultz",
      "id": "221159"
   },
   "amount": 1,
   "status": "refunded",
   "refund_reason_code": "FB System Issue",
   "application": {
      "name": "credits_new_reg",
      "id": "128163550571392"
   },
   "country": "US",
   "created_time": "2011-02-04T20:23:17+0000",
   "updated_time": "2011-02-08T19:12:03+0000"
}

Incurring chargebacks and refunds is part of any successful online business. If there is reason for concern, we will work with you to investigate your application.

Fraud

Facebook takes fraudulent activity seriously and strives to minimize fraud without impacting your revenue. We employ proactive methods to block fraudulent transactions with very high precision, manually review potentially fraudulent cases, and provide reactive support to users who have unauthorized charges made on their accounts or funding sources.

We take actions to help good users regain access to their accounts and keep them playing by refunding purchases made on suspected stolen funding sources. We eliminate malicious users by disabling the payments functionality for users who abuse stolen funding sources or have excessive chargebacks.