facebook充值實時更新接口文檔翻譯 但願對作facebook充值的小夥伴有幫助

 

Realtime Updates for Payments are an essential method by which you are informed of changes to orders made through Facebook Payments within your app. Facebook has built Realtime Updates for Payments with a focus on reliability, allowing your app to depend on them for accurate and timely updates representing the latest state of payments within your app.

充值及時更新是一個基本的通知你facebook的應用支付的訂單改變的方法，facebook內置了專一的穩定的可依賴的充值及時更新接口，容許你更精確和及時的更新表明着應用訂單的最新狀態；

Realtime Updates are a subscription based system between Facebook and your server. Your app subscribes to receive updates from Facebook via a specified HTTP endpoint. When an order made within your app is updated, Facebook will issue an HTTP POST request to that endpoint, notifying your server of the change.

及時更新是基於facebook和你的服務器的訂閱系統，你的應用訂閱接收facebook的更新經過一個特定的http端點，當你的應用的一個訂單發生發生改變時，facebook就發起一個http的post請求到這個http端點，通知你的服務器作出更改。

As part of Facebook’s commitment to providing people with the best possible payment experiences, as of May 2014, the subscription and processing of Realtime Updates for the payments object will be a mandatory requirement of accepting payments on Canvas.

做爲facebook承諾提供給人民多是最好的支付體驗的一部分，從2014年5月份開始，做爲cavas應用的充值，訂閱和處理充值及時更新這個對象是一個強制的要求。

There are three primary scenarios in which Realtime Updates are sent to your developer server:

• Payment Fulfillment
• Refunds, Chargebacks, Chargeback Reversals and Declines
• Disputes

充值及時更新有三種基本的場景推送到你的開發服務器上的時候
完成付款
退款，拒付，拒付逆轉和拒付下降
糾紛

When a person attempts to make a purchase in your app, there are two methods through which you are notified of the outcome, a JavaScript callback and a Realtime Update. You must handle both of these methods to fully support the range of payment options provided by Facebook.

當一個顧客嘗試在你的應用裏面進行購買，有兩種方法能夠通知你購買的結果，一種是js的回調，另一種是及時更新接口，你必須處理這兩種方法的通知來支持facebook提供的一些列支付選擇。

After the person has finished entering their payment details in the purchase flow, Facebook will return details of the order via the JavaScript callback specified when initiating the Pay Dialog - see Order Fulfillment for more information. This callback is invoked as the purchase flow ends, without necessarily waiting for the transaction to fully complete. Such transactions may complete asynchronously at a later time. As an example, there are payment methods supported by Facebook where the consumer is required to print out an order completion form and physically deposit it at their bank. These methods can take hours or even days to complete.

顧客在購物流程中輸入完支付明細以後，當初始化支付對話框的時候，facebook就會經過javascript的回調返回訂單的明細-查看完成訂單的更多信息，這個回調被調用當購買流程結束的時候，而沒有必要等着事物徹底結束。這個事物可能會異步的完成在稍後的時刻，舉個例子，有一個支付的方法支持facebook當一個顧客須要打印出訂單的完成表單和銀行的實際儲蓄支出，這些方法可能會須要幾個小時或者幾天才能完成。

Given this scenario therefore, it is impossible to exclusively satisfy the fulfillment of orders from within the JavaScript callback because some orders will be in an incompleteinitiated state when the JavaScript callback is invoked.

之因此給出這些場景，這使得專門的知足完成的訂單經過js回調成爲可能，由於當js回調的時候，某些訂單就會處於未完成的初始化狀態

Additionally, there are other circumstances in which the JavaScript callback method of order fulfillment cannot be exclusively relied upon. For example, when a person's connectivity to your app is unreliable, the callback may never be triggered. This may occur if the consumer loses connection to the internet mid-flow, or closes their browser.

除此以外，也有些別的狀況，訂單完成的js回調方法不能專門的信任，例如：當一個顧客到你的應用的鏈接是不可信任的，這個回調歷來不會觸發，這個也許會發生當一個顧客在購物流程當中丟失網絡鏈接或者關閉他們的瀏覽器的時候。

Facebook accounts for these scenarios by sending a Realtime Update to your server every time a payment is completed (either synchronously or asynchronously). This allows you to fulfill orders that complete asynchronously and robustly handle the range of circumstances that may interrupt the client side payment flow.

facebook賬號對這些場景發送實時更新當你的服務器 ，當每次支付完成的時候（同步或者異步），這容許你 異步完成或者費力的處理一些列可能打斷客戶端的支付流程的場景完成訂單。

If you do not support order fulfillment via a Realtime Update, you risk creating a significantly negative user experience where your consumers will never receive the virtual-item they successfully purchased. This will ultimately lead to an increase in refunded purchases, impacting your revenue and reputation.

若是你不支持經過實時更新來完成訂單，你冒着風險去建立一個你的顧客將不會收到虛擬物品當他們成功支付的明顯消極的用戶體驗 。這最終會致使退款的增長，影響你的收入和聲譽。

Refunds, Chargebacks, Chargeback Reversals and Declines

There are times when you may wish to issue a refund to a consumer for a payment made within your app. It is also important to be aware that there are some circumstances in which Facebook can and will issue refunds directly. In both cases, when the refund is issued, Facebook will send a Realtime Update to your server. Subscribing and responding to Realtime Updates is the only way to keep your records up to date and in sync with Facebook.

退款，拒付，拒付逆轉和拒絕
有這個當你但願發起退款給一個在你的應用中完成支付顧客的時間，意識到有一些場景 facebook能夠就會發起直接的退款一樣很重要，在這些場景當中，當退款發起的時候，facebook就會發送一條試試更新信息到你的服務器，訂閱和迴應實時更新是惟一的方法來保持你的記錄最新和同步facebook

A chargeback occurs when a consumer in you contacts their payment provider 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.

A chargeback reversal will occur in the rare circumstance where the consumer invokes a chargeback via their bank, then later the bank determines the chargeback was not warranted. In this scenario the developer is paid for the transaction as normal.

當一個拒付發生的時候，顧客直接聯繫支付提供方（例如信用卡公司或者貝寶公司）來爭議支付，一個拒付發生可能由於多種緣由，包括非受權的使用財政設備，多重帳單，或者沒收到虛擬物品。
一個拒付的逆轉會發生在這些罕見的場景，顧客經過銀行發起了一個拒付，稍後銀行決定拒付是否須要，這種情境下，開發者被看成正常的事物支付了。

Additionally, in certain cases Facebook will try to bundle small payments into one single transaction. For these transactions, the bundle is processed when the consumer reaches a certain dollar threshold or after a set period of time. At that time, if the payment source doesn't have enough funds to complete the transaction, we will mark all of the payments in the bundle as decline.

As with refunds, you will also be notified via a Realtime Update when a chargeback, chargeback reversal or decline have been issued.

還有，在這些案例中，facebook就會嘗試綁定小的支付到一個單獨的事物中，對這些事物，這種綁定被處理，當顧客收到所謂的美圓門檻或者以後一段時間，這這種時候，若是支付方沒有足夠的資金來完成這個事物，就在這個束中全部的支付會標記爲拒絕。
對退款來講，你就會別通知經過一個實時更新當拒付，拒付逆轉或者拒絕拒付被髮起的時候。

For more information about the dispute and refund process, please see Payments How-To: Handling Disputes and Refunds.

If you do not subscribe to refund notifications via Realtime Updates, you will be unaware (before payout) of any refunds issued directly from Facebook and will therefore be unable to respond to the associated consumer issue or concern.

更多關於爭議和退款的流程信息，請看支付如何處理爭議和退款。
若是你沒有訂閱一個經過實時更新接口的退款的通知，你不會意識到（支出以前）被直接從facebook發起了的任何退款，所以不能響應客戶相關的問題和擔心。

Disputes

There are occasionally times when a consumer will wish to dispute a payment made in your app. They can do this via various methods on Facebook which are fully detailed in Payments How-To: Handling Disputes and Refunds.

Facebook will notify you by issuing a Realtime update when a dispute is initiated. This is the only method in which you are notified of the existence of a dispute. Handling and responding to disputes are an important part of providing a trustworthy service to your customers, so it is essential that you subscribe to dispute Realtime Updates.

If you do not subscribe to dispute notifications via Realtime Updates, you will create a negative user experience for your customers by ignoring their payment disputes. Facebook considers the handling of consumer disputes a mandatory requirement of Facebook Payments.

爭議
有這種場景的時候，當顧客想要爭議一個在你的應用中的支付，他們能夠經過各類facebook的方法，在這裏有詳細的說明 支付如何處理爭議和退款
facebook就會通知經過一個試試更新當爭議被初始化的時候，這是惟一的方法你被通知有爭議的存在，處理和迴應爭議是對你的顧客提供一個可值得信耐的服務的一個重要的部分 ，因此你必須訂閱爭議試試更新接口。
若是你沒有訂閱爭議通知經過實時更新接口，你會創造一個對你的用戶經過忽略他們的支付爭議的消極的用戶體驗，facebook考慮把處理用戶的爭議做爲對facebook的支付的一個基本的要求

Subscribing to Realtime Updates

To subscribe to Realtime Updates, first create a public endpoint URL that receives both HTTP GET(for subscription verification) and POST (for actual change data) requests from Facebook. The structure of both of these types of requests is described below. Next, set up subscriptions to thepayment object of your app. There are two ways to do this:

• Subscribing to Realtime Updates via the App Dashboard
• Subscribing via the Graph API

In either case, your endpoint will receive the same data in the same manner. See Your Callback Server for more information on what your server should expect to receive.

訂閱實時更新
爲了訂閱實時更新，首先你須要建立一個url端點來接收facebook發起的htt的get（爲了訂閱的校驗）和post（爲了實際的數據更改）請求，這個結構對兩種類型的請求描述以下，以後，安裝訂閱到你應用的支付條目中，這裏有兩種方法去作這件事情。
訂閱實時更新經過應用的控制面板
經過圖形api訂閱
在這兩種案例中，你的網絡端點就會接收相同的數據經過相同的方法，看你的回調服務器來了解更多對你的服務器期待接收到的信息 

Subscribing to Realtime Updates via the App Dashboard

The easiest way to set up your app to receive Realtime Updates is to use the App Dashboard'sPayments panel. Find your app in the dashboard and then click on the Payments tab. The Realtime Updates will be just below your company's Settings section.

訂閱實時更新接口經過應用的控制面板
最容易的方法來安裝你的應用來接收實時更新是使用應用控制面板的支付面板，找到你的應用的面板，而後點擊支付標籤，實時更新接口就會在你公司設置區域上面。

This screen will then list your app's subscription status, whether it has been added through this panel or the API. From here, it's possible to change the subscription callback URL and test it.

In the 'Callback' field, you must provide a valid publicly-accessible server endpoint. This is the address that Facebook will use to both verify the subscription, and send the updates, and needs to respond as described in Your Callback Server.

Finally, provide a 'Verify token'. This can be an arbitrary string, which will be sent to your endpoint when the subscription is verified so that you can be sure the verification process is taking place because of this particular new subscription

這個屏幕就會列出你的應用訂閱的狀態，不管你是否已經 經過這個面板或者api添加 ，在這裏，你能夠改變你的訂閱回調url，並測試它。
這回調字段域，你必須提供一個合法的公共權限的服務器端點，這個地址facebook的校驗和訂閱將會使用，發送更新，須要返回信息 如同你的回調服務器中描述的。
最後，提供一個校驗的令牌，這能夠是一個 隨意的字符串，你能夠發送到你的端點當訂閱被校驗，由於這個特殊的新訂閱你能夠確認校驗的過程發生  

Testing your settings

You should test the callback settings prior to saving the subscription. This will issue a verification GET request to your endpoint, containing the hub.mode, hub.challenge andhub.verify_token parameters, and will ensure that you handle them correctly. For example, you must be sure your endpoint echoes hub.challenge back to Facebook:

測試你的設置
你應該測試回調的設置在保存訂閱以前，這會發起一個get的請求到你的服務器的校驗，包含hub.mode ,hub.challenge和hub.verify_token參數，你必須確保正確的處理他們，例如，你必須確認你的端點回顯hub.challenge到facebook.

Once you’ve entered your subscription details, be sure to click the ‘Save Changes’ button at the bottom of the page.

Editing a subscription is a simple matter of altering the contents of the fields, re-testing, and then saving the form again.

Only subscriptions on the page that have been edited will cause a new verification to be sent to your server when the form is submitted.

Note that if you leave this page and return, the verification code (which has served its purpose) will have been removed from the form. So if you need to then update an existing subscription, you'll need to enter it again if your endpoint is sensitive to its presence.

一旦你輸入了你訂閱的詳情，要保證點擊 頁面底部的 保存修改按鈕
改改訂閱是一件簡單的事情 更改字段的內容，重複測試 ，最後又保存表單。
止嘔在這個頁面的訂閱被修改纔會發起一個新的校驗到你的服務器，當表單提交的時候
注意若是你不理會這個頁面並返回，你的檢驗碼（已經解釋過它的目的了）就會從這個表單中被移除。因此若是你須要更新已存在的訂閱，你須要再次輸入它若是你的端點敏感  對它的出現。

Subscribing via the Graph API

It is also possible to set up and list subscriptions programmatically, through the Graph API. You will need your app's access token, which is available from the access token Tool or by using the Graph API's /oauth endpoint.

The Subscription API is available on thehttps://graph.facebook.com/[APP_ID]/subscriptions endpoint (with your app's ID substituted). There are three tasks you can perform with it:

• Add or modify a subscription (by sending an HTTP POST request)
• List each of your existing subscriptions (by sending an HTTP GET request)

In all cases, you must send your app's access_token as a query string parameter.

經過圖形pai訂閱
也能夠經過程序化的方式安裝和列出訂閱，經過圖形化的api，你須要你應用的經過令牌工具或者經過圖形api的oauth端點來獲取access token （權限令牌）
訂閱api是可用的 在https://graph.facebook.com/[APP_ID]/subscriptions 端點（替換你的應用id），有三個任務你能夠處理。
增長或者修改訂閱（經過發送一個http的post請求）
列出每個存在的訂閱（經過發送一個htt的get請求）
在全部的案例中，你須要發送你應用的權限令牌所謂一個查詢字符參數

Adding and modifying subscriptions

To set up a subscription, send a POST with the following parameters. Note that these correspond to the fields in the form described above:

• object - As above, the type of the object you want to receive updates about. Specify payments.
• fields - A comma-separated list the properties of the object type that you would like to be updated about changes to. Specify 'actions' and 'disputes'.
• callback_url - A valid, and publicly accessible, server endpoint.
• verify_token - An arbitrary string, sent to your endpoint when the subscription is verified.

When Facebook receives this POST this request, as with the form configuration above, Facebook will perform a GET to your callback to ensure it is valid and ready to receive realtime updates. In particular, you must be sure your endpoint echoes hub.challenge back to Facebook.

Note that, because an app can only have one subscription for each object type, if a subscription already exists for this object type, then the newly-posted data replaces any existing data.

增長和修改訂閱
爲了安裝訂閱，發送一個post請求帶上下面的參數，注意 對上面描述的表單中的字段的一致性
object 如同上面的，object的類型你想接收更新，指定爲payments
fields  一個對隊形類型的分割標記的屬性列表 你須要更新相關的 注意actions 和diputes
callback_url  一個合法的功能權限的服務器端點
verify_token 一個隨便的字符，當訂閱確認的時候發送到端點
當facebook接收到這個post請求，如同上面表單配置，facebook將會差生一個get請求到你的回調url中來確認它是合法的並準備接收實時更新消息，實際狀況，你必須保證你的端點返回hub.challenge到facebook.
注意：由於一個應用只能有一個訂閱對每一個對象類型，若是訂閱已經存在了對應的對象類型，以後一個新的推送數據會替換已經存在的數據

Listing your subscriptions

Issuing an HTTP GET to the Subscription API returns JSON-encoded content that lists your subscriptions. For example:

[
  {
    "object": "payments",
    "callback_url": "http://www.friendsmash.com/rtu.php",
    "fields": ["actions", "disputes"],
    "active": true
  }]

You can use the Graph Explorer to experiment with this API directly, remembering to use your app'saccess token.

列舉出你的訂閱
發起一個http的get請求到訂閱的api，返回一個json編碼的內容列舉出你的訂閱，例如：
省略
你可使用圖形瀏覽器來直接實驗這些api，記住使用你的權限令牌

Your Callback Server

Your callback server must handle two types of requests. Ensure it is on a public URL so that Facebook can make these requests successfully.

你的回調服務器
你的回調服務器必須處理兩種類型的請求，確保爲一個公共的url，facebook能夠成功的發送這些請求

Subscription Verification

Firstly, Facebook servers will make a single HTTP GET to your callback URL when you try to add or modify a subscription. A query string will be appended to your callback URL with the following parameters:

• hub.mode - The string "subscribe" is passed in this parameter
• hub.challenge - A random string
• hub.verify_token - The verify_token value you specified when you created the subscription

The endpoint should first verify the hub.verify_token. This ensures that your server knows the request is being made by Facebook and relates to the subscription you just configured.

It should then echo just the hub.challenge value back, which confirms to Facebook that this server is configured to accept callbacks, and prevents denial-of-service (DDoS) vulnerabilities.

Note for PHP developers: In PHP, dots and spaces in query parameter names are converted to underscores automatically. Therefore, you should access these parameters using$_GET['hub_mode'], $_GET['hub_challenge'] and $_GET['hub_verify_token'] if you are writing your callback endpoint in PHP. See this note in the PHP language manual for more details.

訂閱驗證
首先facebook的服務器會產生一個單獨的http的get方法到你的回調url中，當你嘗試增長揮着更改訂閱，一個查詢字符串會添加到你的回調url，含有以下的參數
hub.mode 字符串subscribe被傳遞到這個參數
hub.challenge 一個隨機字符串
hub.verify_token  確認令牌值會指定當你常見訂閱的時候
端點必須首先確認hub.verify_token ,這回確保服務器知道這個請求唄facebook發送了，並聯繫到你以前配置過的訂閱
你必須回顯以前hub.challenge的值，確認facebook服務器被配置來接收回調，來避免ddos漏洞攻擊
php開發者的注意事項 :php中 嗲好和空格在查詢字符串的名稱中自動轉換爲突出，因此，你必須獲取這些參數經過$_GET['hub_mode'], $_GET['hub_challenge'] and $_GET['hub_verify_token']，若是你使用php寫你的回調url端點,請關注php語言的手冊來了解更多詳情

Receiving Updates

Following a successful subscription, Facebook will proceed to issue an HTTP POST to your server endpoint every time that there are changes (to the chosen fields or connections). You must respond to this request with HTTP code 200.

Note - Facebook considers any HTTP response other than 200 to be an error. In these circumstances Facebook will continue to retry sending the Realtime Update. If you do not respond correctly therefore, you may receive the same update multiple times.

The request will have content type of application/json and the body will comprise a JSON-encoded string containing one or more changes.

Note for PHP developers: In PHP, to get the encoded data you would use the following code:

$data = file_get_contents("php://input");
$json = json_decode($data);

Note that the hub.mode, hub.challenge and hub.verify_token parameters are not sent again once the subscription has been confirmed.

接收更新
按照一個成功的訂閱，facebook會處理髮起一個http的post請求到你的服務器端點，每次當有改變發生的時候（對所選的字段或者鏈接），你必須響應這個請求，使用http的代碼200
注意，facebook把別的htpp響應只要不是200的當成錯誤，這這些場景中，facebook就會繼續嘗試發送實時更新，若是你沒有返回正確的相應，因此，你也許會接收到相同的更新不少次。
這個請求含有內容類型爲application/json，而且身體將會包括json編碼的字符串包含一個或者更多的改變。
php開發者注意：在php中，給了得到編碼的數據，你須要使用下面的代碼

$data = file_get_contents("php://input");
$json = json_decode($data);

注意hub.mode,hub.challenge和hub.verify_token參數沒有再次發送，若是訂閱必定被確認過了

Here is a typical example of a callback made for a payments object subscription:

{
  "object": "payments",
  "entry": [
    {
      "id": "296989303750203",
      "time": 1347996346,
      "changed_fields": [
        "actions"
      ]
    }
  ]}

It is important to note that the Realtime Update only informs you that a particular payment, identified by the id field has been changed. After receiving the update, you are then required to query the Graph API for details of the transaction, in order to handle the change appropriately.

Note - While Realtime Updates for other object types can be batched, payment updates arenever batched.

You are guaranteed to receive a new update every time a transaction is updated, either by user action, developer action, or by Facebook.

這裏有一個典型的例子對發送對一個支付對象的訂閱一個回調

{
  "object": "payments",
  "entry": [
    {
      "id": "296989303750203",
      "time": 1347996346,
      "changed_fields": [
        "actions"
      ]
    }
  ]}

很重要，使用id字段來標識改變，接收更新以後，你須要查詢圖形api來獲得信息的事物，爲了適當的處理改變。注意實時更新值通知你特定的支付

注意：別的對象類型的實時更新能夠鼻樑處理，支付的更新曆來不是批量的，你必須保證接收到用戶，開發者或者facebook的動做一個新的更新每次事物發生更新的時候，

If a Realtime Update to your server fails, Facebook will retry again immediately, and then a few times more, with decreasing frequency, over the subsequent 24 hours.

With every request, Facebook sends a X-Hub-Signature HTTP header which contains the SHA1 signature of the request payload, using the app secret as the key, and prefixed with sha1=. Your callback endpoint can verify this signature to validate the integrity and origin of the payload.

若是一個到你服務器的實時更新失敗，facebook將會當即從新嘗試，稍後幾回，24小時候會下降嘗試
對每個請求，facebook發送x中心簽名的http的頭包含sha1簽名 請求的有效荷載 使用應用的密鑰做爲一個key，前綴使用sha1=,你的回調端點會驗證這個簽名來來檢驗 有效載荷的完整性和來源。

Responding to Updates

After your server receives a Realtime Update, you should query the Graph API using the the id field included in the Realtime Update for details on the new status of the transaction. You should then take action depending on the status.

The following sections enumerate all of the potential state changes that trigger a Realtime Update to be sent. These are broadly divided into:

• Changes to the actions array, which occur when a payment completes asynchronously, a refund is issued (by either you or by Facebook) or when a chargeback occurs.

• Changes to the disputes array, which occur when an order dispute is initiated by the consumer.

迴應更新
服務器接收到實時更新以後，你必須使用id字段查詢圖形api，包括對事物的新狀態的實時更新的詳情，你必須對這些依賴的狀態採起措施，以下區域列舉了全部潛在的狀態改變，觸發一個實時更新被髮送，他們被普遍的分解。
對actions數組的改變，發生在一個支付同步完成，一個退款發起（經過或者不經過facebook）或者一個拒付發生
對disputes數組的改變，發生在一個被一個顧客初始化訂單糾紛

Actions

Each payment object contains an array titled actions, containing the collection of state changes the transaction has progressed through. Each entry in the actions array has a property namedtype which describes the type of action that has taken place. type can have the following values:charge, refund, chargeback, chargeback_reversal and decline, which are fully explained here.

A sample response from the Graph API for a payment object with associated actions is below:

{
   "id": "3603105474213890",
   "user": {
      "name": "Daniel Schultz",
      "id": "221159"
   },
   "application": {
      "name": "Friend Smash",
      "namespace": "friendsmashsample",
      "id": "241431489326925"
   },
   "actions": [
      {
         "type": "charge",
         "status": "completed",
         "currency": "USD",
         "amount": "0.99",
         "time_created": "2013-03-22T21:18:54+0000",
         "time_updated": "2013-03-22T21:18:55+0000"
      },
      {
         "type": "refund",
         "status": "completed",
         "currency": "USD",
         "amount": "0.99",
         "time_created": "2013-03-23T21:18:54+0000",
         "time_updated": "2013-03-23T21:18:55+0000"
      }
   ],
   "refundable_amount": {
      "currency": "USD",
      "amount": "0.00"
   },
   "items": [
      {
         "type": "IN_APP_PURCHASE",
         "product": "http://www.friendsmash.com/og/friend_smash_bomb.html",
         "quantity": 1
      }
   ],
   "country": "US",
   "created_time": "2013-03-22T21:18:54+0000",
   "payout_foreign_exchange_rate": 1,}

As you subscribed to the actions field when registering for Realtime Updates, Facebook will issue a Realtime Update when the array changes as follows:

動做
每個支付條目包含一個名字叫actions數組,包含狀態改變的事物發生過程集合，每個actions的條目有一個屬性名叫type,描述了action發生的的類型，類型有以下的值：
充值，退款，拒付，拒付逆轉，拒付拒絕，下面是完整的解釋。
一個簡單的響應從圖形支付api項目跟以下的actions關聯

Charge

Initially, all orders contain a charge entry with "status": "initiated". An initiated payment designates the payment was only initiated and has not yet fully completed. You will commonly see this initiated state for certain payment methods which require long time to settle, as described above.

Note: Facebook will not send Realtime Updates for payments in an initiated state.

When a payment completes successfully, "status": "initiated" will be changed to"status": "completed" and Facebook will issue a Realtime Update. Upon seeing this change you should check your payment records to verify if this is a new or existing transaction and respond as follows:

支付
最初，全部的訂單包含一個擁有「status」:"initiated"的支付條目，一個初始化的支付指出了支付是惟一初始化的並無徹底完成，你將一般看到這個初始化狀態對所謂的支付方法，須要很長時間頭設置 如同上面描述的。
注意 facebook就不會發送初始化狀態的支付實時更新。
當一個支付完成，status:initiated將會編程status:completed,facebook將會發起一個實時更新，基於你看到的改變你須要檢查你的支付記錄來確認若是有一條如同下面的新的或者已經存在的事物或者響應

• If the order is already known to you, and has been fulfilled by the JavaScript callback (preferable as a first-choice), then you can either safely ignore the Realtime Update, or use it as an additional confirmation.

• If the order is known to you, but exists in an initiated state, then you can proceed to fulfill the order, issuing the associated virtual item or currency to the consumer. This payment can then safely be marked as complete.

• If the order is unknown, it indicates that the client-side flow did not complete, most likely due to a connectivity issue or the consumer closing their browser mid-checkout. You can still safely fulfill and complete this order, because Facebook remains the ultimate source of truth with regard to user billing.

You will also receive Realtime Updates for payments with "status": "failed". These should not be fulfilled.

For more information about the payment object and its potential states, please see the Payment API reference.

若是訂單已經被你所知，或者已經經過js回調（看成第一選擇更好）完成 ，你能夠安全的忽略掉實時更新，並用它做爲額外的確認
若是訂單被你所知，可是存在初始化的狀態，你須要處理來完成這個訂單，發送關聯的虛擬條目或者貨幣給客戶，這個支付能夠被安全的標記爲完成
若是訂單未知，這表名客戶端的流程沒有完成，最可能的是由於鏈接問題或者顧客關掉了瀏覽器在充值過程當中，你仍然能夠完成訂單，由於facebook保持了最後的源和真相對用戶的帳單
你就會收到對充值含有status:failed實時更新 這些訂單將不會完成
更多的關於支付項目和基本的狀態，請看支付api參考

Refund

Whenever you issue a refund via the Graph API, you will receive a Realtime Update. As with"type": "charge", a refund can also have a varying status of which you must be aware. Most notably, it is possible for a refund to fail, typically due to a processing or connectivity error - in which case you should retry to issue the refund.

For more information about the dispute and refund process, please see Payments How-To: Handling Disputes and Refunds.

Chargeback, Chargeback Reversal and Declines

As with refunds, you will also be notified via a Realtime Update when a chargeback, chargeback reversal or decline has been issued. A chargeback, chargeback reversal or decline object will be added to the actions array of the Graph API return data for the payment.

For more information about the dispute and refund process, please see Payments How-To: Handling Disputes and Refunds.

退款
任什麼時候候你經過圖形api發起一個退款，你就會收到一個實時更新，含有type:charge,一個退款含有你必須意識到不一樣的狀態，最現煮的，若是一個退款失敗，通常是由於處理過程或者鏈接錯誤，你須要重試來發起退款。
更多關於糾紛和退款的過程請看支付如何處理糾紛和退款
拒付，拒付逆轉和拒付拒絕
對退款來講，你也須要通知經過實時更新當一個拒付，拒付逆轉或者拒付拒絕發生的時候，一個拒付，逆轉，拒絕項目會增長到圖形api返回的支付數據的actions的數組中
更多關於糾紛和退款的過程請看支付如何處理糾紛和退款

Disputes

Facebook will notify you by issuing a Realtime update when a dispute is initiated. In this case, you will see a new "disputes" array appear as part of the payment object. The array will contain the time the dispute was initiated, the user's reason for initiated the response, and the user's email address, which you can use to contact them directly in order to resolve the dispute.

A full sample response from the Graph API for a disputed transaction is below:

{
   "id": "3603105474213890",
   "user": {
      "name": "Daniel Schultz",
      "id": "221159"
   },
   "application": {
      "name": "Friend Smash",
      "namespace": "friendsmashsample",
      "id": "241431489326925"
   },
   "actions": [
      {
         "type": "charge",
         "status": "completed",
         "currency": "USD",
         "amount": "0.99",
         "time_created": "2013-03-22T21:18:54+0000",
         "time_updated": "2013-03-22T21:18:55+0000"
      }
   ],
   "refundable_amount": {
      "currency": "USD",
      "amount": "0.99"
   },
   "items": [
      {
         "type": "IN_APP_PURCHASE",
         "product": "http://www.friendsmash.com/og/friend_smash_bomb.html",
         "quantity": 1
      }
   ],
   "country": "US",
   "created_time": "2013-03-22T21:18:54+0000",
   "payout_foreign_exchange_rate": 1,
   "disputes": [
      {
         "user_comment": "I didn't receive my item! I want a refund, please!",
         "time_created": "2013-03-24T18:21:02+0000",
         "user_email": "email\u0040domain.com",
         "status": "resolved", 
         "reason": "refunded_in_cash"
      }
   ]}

For more information on how to respond to disputes and issue refunds, please see Payments How-To: Handling Disputes and Refunds.

For more information about the payment object, please see the Payment API reference.

糾紛
facebook將會通知你經過發起一個實時更新，當糾紛產生的時候，這個狀況下，你能夠看到一個新的糾紛數組查uxianzuowei一個支付項目的一部分，這個數組含有時間和糾紛初始化的時間，用戶的緣由對初始化的響應，用戶的郵件地址，你能夠直接聯繫到他們爲了解決糾紛。
一個完整一個糾紛事物圖形api響應的例子 以下

更多關於糾紛和退款的過程請看支付如何處理糾紛和退款