• InApp PurchaseMaking a Purchase(4)


    Making a Purchase

    When the user is ready to purchase an item, your application asks the App Store to collect payment. When your application asks for payment, the App Store creates a persistent(持久) transaction(交易) and continues to process the payment, even if the user quits and relaunches your application. The App Store synchronizes the list of pending transactions with your application and delivers updates to your application when the status of any of these transactions changes.

     

    Collecting Payments

    To collect payment, your application creates a payment object and queues(队列) it on the payment queue, as shown in Figure 3-1.

    Figure 3-1  Adding a payment request to the queue

    When the payment is added to the payment queue, a persistent transaction is created to hold it. After the payment is processed, the transaction is updated with information about the payment collection. Your application implements an observer that receives messages when transactions are updated. The observer should provide purchased items to the user and then remove the transaction from the payment queue.

    SKPayment

    Collecting payment starts with a payment object. The payment object includes a product identifier and optionally includes the quantity(数量) of that product to be purchased. You can queue the same payment object more than once; each time a payment object is queued results in a separate request for payment.

    Users can disable the ability to make purchases in the Settings application. Before attempting to queue a purchase, your application should first confirm that payment can be processed. You do this by calling the payment queue’s canMakePayments method.

    SKPaymentQueue

    The payment queue is used to communicate with the App Store. When payments are added to the queue, Store Kit transmits the request to the App Store. Store Kit presents(呈现、礼物) dialogs to ask the user to authorize payment. The completed transaction is returned to your application’s observer.

     

    SKPaymentTransaction

    A transaction(交易) is created for every payment added to the queue. Each transaction has properties that allow your application to determine the status of the transaction. When payment is collected, the transaction includes additional details about the successful transaction.

    Although your application can ask the payment queue for a list of pending transactions, it is more common for an application to wait until the payment queue notifies the payment queue’s observer with a list of updated transactions.

    SKPaymentTransactionObserver

    Your application implements the SKPaymentTransactionObserver protocol on an object and adds it as an observer to the payment queue. The observer’s primary responsibility is to examine completed transactions, deliver items that were successfully purchased, and remove those transactions from the payment queue.

    Your application should associate an observer with the payment queue when it launches, rather than wait until the user attempts to purchase an item. Transactions are not lost when an application terminates(终止). The next time the application launches, Store Kit resumes processing transactions. Adding the observer during your application’s initialization ensures that all transactions are returned to your application.

    Restoring Transactions

    Once a transaction has been processed and removed from the queue, your application normally never sees it again. However, if your application supports product types that must be restorable, you must include an interface that allows users to restore these purchases. This interface allows a user to add the product to other devices or, if the original device was wiped(抹去), to restore the transaction on the original device.

    Store Kit provides built-in functionality to restore transactions for non-consumable products, auto-renewable subscriptions and free subscriptions. To restore transactions, your application calls the payment queue’s restoreCompletedTransactions method. The payment queue sends a request to the App Store to restore the transactions. In return(回报), the App Store generates a new restore transaction for each transaction that was previously completed. The restore transaction object’s originalTransaction property holds a copy of the original transaction. Your application processes a restore transaction by retrieving the original transaction and using it to unlock the purchased content. After Store Kit restores all the previous transactions, it notifies the payment queue observers by calling their paymentQueueRestoreCompletedTransactionsFinished: method.

    If the user attempts to purchase a restorable product (instead of using the restore interface you implemented), the application receives a regular transaction for that item, not a restore transaction. However, the user is not charged again for that product. Your application should treat these transactions identically to those of the original transaction.

    Non-renewing subscriptions and consumable products are not automatically restored by Store Kit. Non-renewing subscriptions must be restorable, however. To restore these products, you must record transactions on your own server when they are purchased and provide your own mechanism to restore those transactions to the user’s devices.

     

    THE END !

  • 相关阅读:
    thinkphp6查询表达式使用between问题
    机器学习纸质作业1
    磁盘挂载
    SQL Server开启READ_COMMITTED_SNAPSHOT
    视觉开发-相机镜头选型
    使用logstash出现报错com.mysql.jdbc.Driver not loaded. Are you sure you've included the correct jdbc driver in :jdbc_driver_library
    linux安装tomcat(转自https://blog.csdn.net/fukai8350/article/details/80467224)
    linux 安装java(转自https://www.cnblogs.com/wjup/p/11041274.html)
    如何统计自动化测试用例的ROI 【投入产出比/投资回报率】
    老男孩老师的博客地址
  • 原文地址:https://www.cnblogs.com/xingchen/p/2406555.html
Copyright © 2020-2023  润新知