title: In-app billing developer payload argument?
body: <p>I've Googled this concept six ways from Sunday and I feel like I can't find a straight answer on it. The <a href="https://developer.android.com/training/in-app-billing/purchase-iab-products.html" rel="nofollow noreferrer">official Google docs</a> say it isn't meant for security, but then a bunch of answers I find seem to imply otherwise, etc.</p>
  
  <p>From the docs:</p>
  
  <blockquote>
    <p>The fifth argument contains a 'developer payload' string that you can
    use to send supplemental information about an order (it can be an
    empty string). If you specify a string value, Google Play returns this
    string along with the purchase response. Subsequently, when you make
    queries about this purchase, Google Play returns this string together
    with the purchase details. </p>
    
    <p>Caution: Don't use the developerPayload field for security validation
    purposes. This field isn't always available when completing tasks
    related to In-app Billing. For more information about security best
    practices, see the In-app Billing Security and Design guide.</p>
  </blockquote>
  
  <p>From the official Google test project:</p>
  
  <pre><code>/** Verifies the developer payload of a purchase. */
  boolean verifyDeveloperPayload(Purchase p) {
      String payload = p.getDeveloperPayload();
  
      /*
       * TODO: verify that the developer payload of the purchase is correct. It will be
       * the same one that you sent when initiating the purchase.
       *
       * WARNING: Locally generating a random string when starting a purchase and
       * verifying it here might seem like a good approach, but this will fail in the
       * case where the user purchases an item on one device and then uses your app on
       * a different device, because on the other device you will not have access to the
       * random string you originally generated.
       *
       * So a good developer payload has these characteristics:
       *
       * 1. If two different users purchase an item, the payload is different between them,
       *    so that one user's purchase can't be replayed to another user.
       *
       * 2. The payload must be such that you can verify it even when the app wasn't the
       *    one who initiated the purchase flow (so that items purchased by the user on
       *    one device work on other devices owned by the user).
       *
       * Using your own server to store and verify developer payloads across app
       * installations is recommended.
       */
  
      return true;
  }
  </code></pre>
  
  <p>I have absolutely no idea what this means. If I don't have my own server, should I just be using a blank string? How am I supposed to differentiate users and purchases and devices?</p>
  
  <p>None of this is clear to me and this code / the official docs offer no real clarification, and most of the online answers are similarly sparse.</p>
  
  <p>Can anyone just lay it out: What should I be sending as my developer payload argument?</p>