title: IAP backend best practice
body: <p>I've just made iOS app with IAP to purchase virtual coins(Consumable). And the backend is Ruby on Rails. I have some concerns for now about the whole solution.</p>
  
  <p>My current IAP process describes as following:</p>
  
  <ul>
  <li>STEP 1 - iOS Client sends request to our backend and get product ids.</li>
  <li>STEP 2 - Client retrieve product list through Store Kit with ids from step1</li>
  <li>STEP 3 - User click buy and client sends a payment request to Store Kit</li>
  <li>STEP 4 - When finish transaction the client send the receipt token to our backend</li>
  <li>STEP 5 - Server verifies the receipt first to make sure it's a valid verification</li>
  <li>STEP 6 - Server calls App Store to verify the receipt and deal with the exchange(Recharge account in DB)</li>
  <li>STEP 7 - Client gets the response back and displays account balance</li>
  </ul>
  
  <p>I worked on e-commerce/payment solutions before, and IAP takes the other way, though usually the payment gateway will send the receipt server-to-server for verification. And we always have message queue sort of solutions to make sure all transactions are stable and maintainable. </p>
  
  <p>My questions are:</p>
  
  <ol>
  <li><p>What's the best practice to verify IAP receipt? How to avoid the interruption of verification from our server? (e.g., User spend money and finish the transaction on the client, but fails when verify the receipt on server. No IAP restore transaction support.)</p></li>
  <li><p>Apple IAP more likely a perfect client solution. Especially in my case, after user's payment, he wants to receives the coins immediately, and not the case we tell him the transaction is processing and his account will be fulfilled soon. To have responsive UX on mobile device is prioritized. Do you still use message queue stuff on server? </p></li>
  </ol>
  
  <p>Thanks for your time.</p>