Welcome. This video discusses handling disputes
and refunds inside the Facebook Local Currency Payments system. For a number of reasons, there will be occasional
times where a user will wish to revoke a payment made in your app.
As a developer, you are responsible for efficiently responding to such requests, providing a trustworthy
and fair service to your customers. Facebook offers mechanisms to help you handle these
requests, from being alerted as soon as one occurs, to best practices around how to process
such disputes. Broadly speaking, Facebook’s philosophy regarding
payment disputes is that we will provide primary support for cases in which the user contends
a transaction directly with their funding provider (i.e. a credit card company or Paypal). However, when a user has an in-app purchasing
issue, or does not receive a purchased item or currency, they should be routed directly
to the developer. In the latter case, the developer is best equipped to satisfy the
dispute, typically by issuing more or replacement in-app items, refunding the payment, or providing
clarification on a delay to item delivery. Let’s walk through a typical dispute flow,
to see how this works: The user can initiate a transaction dispute
through Facebook.com in several ways, typically through this link on the bottom right of your
canvas game page, through user payment settings, via a receipt notification, or via a receipt
email. Regardless of how the Facebook Payments Support
flow is initiated, users are prompted to identify their issue by answering a series of multiple
choice questions. Depending on the user’s selections, they are directed to the appropriate
contact, either Facebook or the developer. Here, the user has selected an issue best
handled by the developer, which results in an additional free text input for the user
to specify the reason for the dispute. After the user has initiated a dispute, a
realtime update is sent to the developer. Realtime updates are fully explained in part
5 of this video series, but essentially, as a developer you subscribe to the ‘disputes’
action on the ‘payment’ object, and Facebook will contact your specified server callback
any time a dispute occurs. The realtime update will contain the payment_id
of the transaction. The developer can then use this payment_id to query the Graph API
to retrieve additional information regarding the transaction, including the user’s email
address, and their specified reason for initiating the dispute. It is then the developer’s responsibility
to use this information to communicate with the user and reach an agreed solution. Once a dispute has been created by the user,
Facebook will add additional information to the Graph API return data associated with
the disputed payment_id. These additional fields are combined under a disputes array
as follows: disputes/user_comment
The free text reason for the dispute entered by the user.
disputes/time_created The time in PST at which the user created
the dispute. disputes/user_email
The user’s preferred email address. These additional parameters give you the means
to review the dispute, and optionally contact the user in order to resolve their issue. After reviewing the dispute, you may choose
to refund the user any amount less than or equal to the refundable_amount returned by
the Graph API for a given payment_id. You can also issue additional refunds, as long
as the refundable_amount remains greater than zero.
Facebook does not offer the functionality to refund an amount greater than the purchase
amount. In order to issue a refund, make an HTTP POST
call to the Graph API endpoint /PAYMENT_ID/refunds with an app access token, and the following
parameters: currency – The three-letter ISO code of the
currency in which the refund amount is specified. This must be the same as the currency in which
the original purchase was denominated. amount – The amount to refund. reason – The reason for the refund being issued.
This will be communicated to the user. The response from Facebook will be true on
success, or an error code otherwise. The payment object is then updated, with its actions field
including details of the refund. For complete details on how the payment object
is changed after a refund is issued, please refer to the Payment Graph API reference doc,
at developers.facebook.com/docs/reference/api/payment/ In the previous examples, the developer has
been primarily responsible for handling a user dispute. There are however, circumstances
in which Facebook will assume the primary point of contact for the user. There are two broad definitions in which this
is likely to occur Non-fraud dispute: User request for monetary
refund related to mistaken purchase or misuse of a financial instrument by family or friend.
For these types of disputes, Facebook reviews a user’s refund request on a case-by-case
basis. Typically, these requests are as a result
of user confusion, where the purchase was made accidentally due to a misunderstanding
of the purchase flow. 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 the dispute is 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. Malicious fraud charge dispute. This is an
unauthorized purchase associated with a stolen financial instrument or compromised account. In these cases, Facebook will typically seek
to fully refund a user as quickly as possible. Doing so prevents a user having to resort
to a chargeback, and builds trust with honest users who may fall victim to fraud. If Facebook
determines that this dispute is valid and that the user should be refunded, we will
recover the cost of such a provision from the developer. Facebook does this by deducting
the refunded amount from the next payout made to the developer at the end of the payout
cycle. We will only do this for transactions disputed within 90 days of the the original
transaction date. As with disputes, you will be notified via
a realtime update when Facebook refunds an order. Also, as before, additional information
will be added to the Graph API return data for the payment. Rather than an additional
disputes array, there will be a refund field added to the actions array, signifying the
payment has been refunded. A chargeback occurs when a user of your app
contacts their payment provider directly (e.g., credit card company or PayPal) to dispute
a transaction. 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. If the payment provider issues a refund, Facebook
will recover the cost of the chargeback from the developer. Again, Facebook does this by
deducting the charged-back amount from the next payout made to the developer at the end
of the payout cycle. Facebook will only do this if the chargeback occurs within 90 days
of the original transaction. Beyond 90 days, Facebook will be responsible for the cost
of the chargeback apart from in some very infrequent edge cases. These are detailed
in the documentation listed here: developers.dev.facebook.com/docs/howtos/payments/disputesrefunds/ Facebook takes fraudulent activity seriously
and strives to minimize fraud with minimal impact to developer revenue. With high accuracy,
we employ proactive methods to block fraudulent transactions, manually review potentially
fraudulent cases and provide responsive, reactive support to users who have unauthorised charges
made on their account. Incurring chargebacks and refunds is a normal
part of operating any online business. Handling disputed transactions in an accurate, fair
and timely manner is a responsibility of the developer as part of providing good customer
service and maintaing user trust. If there is reason for concern, please reach out to
Facebook via our Help Center, at facebook.com/help and we will work with you to investigate your
individual app or use-case. For more information about disputes, refunds,
chargebacks and fraud, please see the URL listed here.