In-App Purchase Programming Guide----（四) ----Requesting Payment

Requesting Payment

In the second part of the purchase process, after the user has chosen to purchase a particular product, your app submits a payment request to the App Store, as shown in Figure 3-1.

購買過程的第二步是，在使用者已經選擇好要購買的産品後，你的應用程式向應用商店送出一個支付請求，如下圖：

Figure 3-1  Stages of the purchase process—requesting payment

Creating a Payment Request

一、建立一個支付請求

When the user selects a product to buy, create a payment request using a product object, and set the quantity if needed, as shown in Listing 3-1. The product object comes from the array of products returned by your app’s products request, as discussed in “Retrieving Product Information.”

當使用者選擇了一個要買的産品後，使用一個産品對象建立一個支付請求，并根據需要設定好購買數量，如下清單。 正如In-App Purchase----（三) ----Retrieving Product Information 中所述，産品對象來自應用的products requst 傳回的數組。

Listing 3-1  Creating a payment request

SKProduct *product = <# Product returned by a products request #>;

SKMutablePayment *payment = [SKMutablePayment paymentWithProduct:product];

payment.quantity = 2;

Detecting Irregular Activity

二、檢測不規則活動

The App Store uses an irregular activity detection engine to help combat fraud. Some apps can provide additional information to improve the engine’s ability to detect unusual transactions. If your users have an account with you, in addition to their App Store accounts, provide this additional piece of information when requesting payment.

應用商店使用一個不規則活動檢測引擎來幫助打擊欺騙行為。 一個應用程式可以提供額外的資訊來提高引擎的性能以便檢測不正常的交易。 如果你的使用者除了有自己的應用商店賬号外，還有一個你的賬号，就可以在請求支付時提供該額外的資訊片段。

By way of illustration, consider the following two examples. In the normal case, many different users on your server each buy coins to use in your game, and each user pays for the purchase from a different App Store account. In contrast, it would be very unusual for a single user on your server to buy coins multiple times, paying for each purchase from a different App Store account. The App Store can’t detect this kind of irregular activity on its own—it needs information from your app about which account on your server is associated with the transaction.

通過示範的方法，考慮以下兩個例子。 在正常情況下，你的伺服器上的很多不同的使用者購買遊戲中金币(coins)，并且每個使用者都從一個不同的應用商店賬号購買。相反，如果同一個使用者在你的伺服器上多次購買金币，但是每次購買都從不同的應用商店賬号上支付就非常不尋常。應用商店自己不能檢測到該類型的不規則活動--它需要從你的應用程式中知道你伺服器上的哪個賬号跟該筆交易有關聯。

To provide this information, populate the 

applicationUsername

 property of the payment object with a one-way hash of the user’s account name on your server, such as in the example shown in Listing 3-2.

要想提供該資訊，用你伺服器中的使用者賬号名稱，以單向散列方式填寫applicationUsername特性，如下：

Listing 3-2  Providing an application username

#import <CommonCrypto/CommonCrypto.h>

// Custom method to calculate the SHA-256 hash using Common Crypto

- (NSString *)hashedValueForAccountName:(NSString*)userAccountName

{

const int HASH_SIZE = 32;

unsigned char hashedChars[HASH_SIZE];

const char *accountName = [userAccountName UTF8String];

size_t accountNameLen = strlen(accountName);

// Confirm that the length of the user name is small enough

// to be recast when calling the hash function.

if (accountNameLen > UINT32_MAX) {

NSLog(@"Account name too long to hash: %@", userAccountName);

return nil;

}

CC_SHA256(accountName, (CC_LONG)accountNameLen, hashedChars);

// Convert the array of bytes into a string showing its hex representation.

NSMutableString *userAccountHash = [[NSMutableString alloc] init];

for (int i = 0; i < HASH_SIZE; i++) {

// Add a dash every four bytes, for readability.

if (i != 0 && i%4 == 0) {

[userAccountHash appendString:@"-"];

}

[userAccountHash appendFormat:@"%02x", hashedChars[i]];

}

return userAccountHash;

}

If you use another approach to populate this property, ensure that the value you provide is an opaque identifier uniquely associated with the user’s account on your server. Don’t use the Apple ID for your developer account, the user’s Apple ID, or the user’s unhashed account name on your server.

如果你使用另一種方法填寫該特性，請確定你提供的值是一個不透明的識别碼，它隻跟你伺服器上的使用者賬号有關。 不要使用蘋果ID作為你的開發者賬号，使用者的蘋果ID，或使用者在你的伺服器的非散列賬戶名。

Submitting a Payment Request

三、遞交一個支付請求

Adding a payment request to the transaction queue submits it the App Store. If you add a payment object to the queue multiple times, it’s submitted multiple times—the user is charged multiple times and your app is expected to deliver the product multiple times.

向要遞交給應用商店的交易隊列添加一個支付請求。 如果你多次把一個支付對象添加到隊列，它就會被送出多次---使用者就會被多次要求支付并且應用程式就回多次傳遞産品。

[[SKPaymentQueue defaultQueue] addPayment:payment];

For every payment request your app submits, it gets back a corresponding transaction that it must process. Transactions and the transaction queue are discussed in “Waiting for the App Store to Process Transactions.”

對于你的應用程式遞交的每個支付請求，都會傳回一個相應地交易，它必須處理它。 交易和交易隊列在“Waiting for the App Store to Process Transactions.”中讨論。

下一頁     前一頁

轉載于:https://www.cnblogs.com/patientAndPersist/p/3707436.html