Testing Payments

Once you have your payments system in place, follow these steps to thoroughly test your implementation.

Payment testers

In order to test your payment implementation, you can assign specific users of your application to be payment testers. If a user is assigned as a payment tester they can make transactions as normal within your app, however their payment instrument will not be charged and the transaction will not appear in the payments reporting API.
Payment testers can be defined in your Payments section of your developer app settings.
Whenever a payment tester user invokes the payment dialog in your application, they will be presented with a test flow instead of the regular payment flow. Payment test users have the option to invoke a number of different scenarios:
  • A transaction which succeeds immediately.
  • A transaction which fails immediately.
  • An asynchronous transaction which will succeed after 30 seconds.
  • An asynchronous transaction which will fail after 30 seconds.
By using the different options, you can test if the different payments flows in your application work as expected.
In terms of order fulfillment, test payments behave in exactly the same way as non-test payments. TheJavaScript callbackRealtime Updates and Payment Graph API perform consistently, irrespective of if the payment is made by a test user or otherwise.
The only differences seperating real payments from test payments, are that test payments will not appear in the user's Purchase History, and will not appear in any payment reporting.
Payment Info
When querying the Graph API for payment info on a test transaction with a payment_id, an additionaltest field will be added to the Graph API return data and set to 1, signaling it was a test transaction which you will not be paid out for. You will also notice that the refundable amount for this transaction will always be 0.00.
{
  "id": "370408446422594", 
  "user": {
    "name": "Marco Alvarez", 
    "id": "500535225"
  }, 
  "application": {
    "name": "Friend Smash!", 
    "namespace": "friendsmash", 
    "id": "24143148..."
  }, 
  "actions": [
    {
      "type": "charge", 
      "status": "completed", 
      "currency": "USD", 
      "amount": "0.90", 
      "time_created": "2013-10-23T22:24:41+0000", 
      "time_updated": "2013-10-23T22:25:18+0000"
    }
  ], 
  "refundable_amount": {
    "currency": "USD", 
    "amount": "0.00"
  }, 
  "items": [
    {
      "type": "IN_APP_PURCHASE", 
      "product": "https://friendsmash.com/og/coin.html", 
      "quantity": 9
    }
  ], 
  "country": "US", 
  "request_id": "5D81tgIWTBrfYG36ohftTci3KVU8M6dAg2NPmJwXcpk65ABVlkp5vtE2y43YYpWI", 
  "created_time": "2013-10-23T22:24:41+0000", 
  "test": 1, 
  "payout_foreign_exchange_rate": 1
}

Testing mobile shortcutting and asynchronous payment methods

In addition to the normal payment testing options, we have also included a new dialog designed specifically to test mobile shortcutting and asynchronous payments. This dialog can be invoked in one of two ways:
  • By selecting the 'Asynchronous Payment Method' option on the regular payment testing dialog,illustrated above.
  • By altering the call to the FB.ui pay method of the JavaScript SDK with a non-empty testpricepoint_id. This is illustrated by the code sample below.
FB.ui({
    method: "pay",
    action: "purchaseitem",
    product: "http://www.friendsmash.com/og/coins.html",
    quantity: 20,
    pricepoint_id: "this_is_a_test_pricepoint"
  },
  function(result){}
);
Regardless of which method you use to invoke the dialog, a payment test user will be presented with four different payment options. These options are designed to exercise potential scenarios that may occur when a user elects to pay with their mobile phone or selects an asynchronous payment method.
The four different options are discussed below:
Immediately settle the payment This method is useful for simulating a payment made via a mobile payment provider, and will generate a completed test payment immediately after the user clicks on the 'Confirm' button. The JavaScript function you defined as a callback when invoking the Pay Dialog will be triggered with status=completed, and Facebook will immediately issue a Realtime Update to your server. If you query the Graph API, you will notice that the payment has a completed status.
Immediately fail the payment This option will immediately create a test payment with a status offailed. The Pay Dialog will behave in the same way as a non-test payment and will prompt the user to try another payment method. In this case, because the user is a payment tester, it will present the normal payment tester flow with the two original options. Facebook will also immediately issue a Realtime Update to your server, notifying you of the failure.
Settle the payment in 30 seconds This method is useful for simulating a payment made via an asynchronous payment method. In this case, the JavaScript callback function will be called immediately after the 'Confirm' button is clicked, with the payment in an status=initiated state (Note: Facebook will not issue a Realtime Update for payments with this status). If you query the Graph API for details of the payment at this time, you will see that the payment status will be set to initiated. After 30 seconds, the payment status will automatically be set to completed. At this time, Facebook will issue a Realtime Update to your server, notifying you of the change. You will also be able to confirm this by querying the Graph API.
Fail the payment in 30 seconds The final option works in much the same way as the previous option. A test payment will be created with an initial status of initiated. This status will then automatically change to failed after 30 seconds. This is designed to simulate the scenario of a mobile or asynchronous payment failing to complete. Facebook will issue a Realtime Update to your server after the status changes to notify you of the failure. You can again check the status of this payment via the Graph API.

Testing multiple currencies

We have added the functionality for developers of an app to test purchases in multiple currencies without having to change their preferred currency in their payments settings. This will only work for admins, developers and testers listed on an app to avoid potential abuse from users through JavaScript injection.
We have added an optional parameter when invoking the Pay Dialog called test_currency. When calling the Pay Dialog, if you set this parameter to the three character code for a supported currency, it will temporarily override the currency which you are charged in. An example of how to use this can be seen below.
Note: this only overrides the user's default currency and does not mean that every transaction will be a 'test' transaction, transactions will be charged unless you are listed as a payment tester.
FB.ui({
      method: 'pay',
      action: 'purchaseitem',
      product: 'www.mydomain.com/payment_product.html',
      quantity: 1,                   // optional, defaults to 1
      request_id: 'YOUR_REQUEST_ID', // optional, must be unique for each payment
      test_currency: 'EUR'           // optional, overrides currency for testing  
    },
    callback
);

A/B testing API

In an effort to make it easy for developers to A/B test their Facebook payments implementation, we have created a simple API that segments users into 1 of 10 groups. This allows you to easily try different pricing strategies, product offerings or promotions in a controlled environment.
When you query the API, we will return a test_group value between 1 and 10 for a given user. This test group value will remain stable for a given user.
It is important to note that Facebook has taken steps to ensure this segmentation is truly random, and will generate reliable results with no payment bias across the base of the ecosystem.
To check which test_group a user is in, you can query the graph API with the following query.
GET https://graph.facebook.com/USER_ID?fields=test_group&access_token=ACCESS_TOKEN
Response An integer value between 1 and 10.
If you were using the older payment_test_group, that will still work. However, we are planning on deprecating it eventually so you should move to test_group at your earliest convenience
Was this document helpful?