Создание платежного требования
Платежные требования являются экземплярами PKPaymentRequest класс. Платежное требование состоит из списка сводных элементов, описывающих пользователю, за что платят, список доступных способов доставки, описание того, какую информацию о поставке пользователь должен обеспечить, и информация о торговой и компании обслуживания платежей.
Решите, может ли пользователь произвести платежи
Прежде, чем создать платежное требование, определите, будет ли пользователь в состоянии произвести платежи с помощью сети, которую Вы поддерживаете путем вызова canMakePaymentsUsingNetworks: метод PKPaymentAuthorizationViewController класс. Чтобы проверить, поддерживается ли Оплата Apple аппаратными средствами этого устройства и родительским контролем, используйте canMakePayments метод.
Если пользователь не может произвести платежи, не показывайте кнопку Apple Pay. Вместо этого отступите к другому способу оплаты.
Платежные требования включают информацию о валюте и области
Все сводные суммы в платежном требовании используют ту же валюту, указанную с помощью currencyCode свойство PKPaymentRequest. Используйте код валюты ISO с тремя символами, такой как USD.
Код страны платежного требования указывает страну, где закупка имела место или будет обработана. Используйте код страны ISO с двумя символами, такой как US.
Торговый ID, который Вы устанавливаете в платежном требовании, должен соответствовать один из торгового IDs в праве Вашего приложения.
request.currencyCode = @"USD";request.countryCode = @"US";request.merchantIdentifier = @"merchant.com.example";
Платежные требования имеют список сводных элементов платежа
Сводные элементы платежа, представленные PKPaymentSummaryItem класс, опишите различные части платежного требования пользователю. Используйте небольшое количество сводных элементов — обычно промежуточный итог, любая скидка, поставка, налог и общий итог. Предоставьте гранулированную подробную информацию поштучных затрат в другом месте в Вашем приложении.
Каждый сводный элемент имеет метку и сумму, как показано в Перечислении 3-1. Метка является читаемым пользователем описанием того, что суммирует элемент. Сумма является соответствующей суммой платежа. Все суммы в платежном требовании используют валюту, указанную в платежном требовании. Для скидки или купона, набор сумма к отрицательному числу.
// 12.75 subtotalNSDecimalNumber *subtotalAmount = [NSDecimalNumber decimalNumberWithMantissa:1275 exponent:-2 isNegative:NO];self.subtotal = [PKPaymentSummaryItem summaryItemWithLabel:@"Subtotal" amount:subtotalAmount];// 2.00 discountNSDecimalNumber *discountAmount = [NSDecimalNumber decimalNumberWithMantissa:200 exponent:-2 isNegative:YES];self.discount = [PKPaymentSummaryItem summaryItemWithLabel:@"Discount" amount:discountAmount];
Последний сводный элемент платежа в списке является общим итогом. Вычислите итоговую сумму путем добавления сумм всех других сводных элементов. Общий итог выведен на экран по-другому, чем другие сводные элементы: Используйте имя своей компании в качестве его метки и используйте общее количество сумм всех других сводных элементов как его сумма. Добавьте сводные элементы платежа к платежному требованию с помощью paymentSummaryItems свойство.
// 10.75 grand totalNSDecimalNumber *totalAmount = [NSDecimalNumber zero];totalAmount = [totalAmount decimalNumberByAdding:subtotalAmount];totalAmount = [totalAmount decimalNumberByAdding:discountAmount];self.total = [PKPaymentSummaryItem summaryItemWithLabel:@"My Company Name" amount:totalAmount];self.summaryItems = @[self.subtotal, self.discount, self.total];request.paymentSummaryItems = self.summaryItems;
Способ доставки является специальным сводным элементом платежа
Создайте экземпляр PKShippingMethod для каждого доступного способа доставки. Точно так же, как другие сводные элементы платежа способы доставки имеют читаемую пользователем метку, такую как Стандартная Поставка или на следующий день Поставляя и сумма, которая является стоимостью доставки. В отличие от других сводных элементов, способы доставки также имеют a detail свойство — то, которое “Поступает к 29 июля” или, “Поставляет за 24 часа” — который объясняет различие между способами доставки.
Для различения способов доставки в методах делегата используйте identifier свойство. Это свойство используется только Вашим приложением — платформа обрабатывает его как непрозрачное значение, и это не появляется в UI. Присвойте уникальный идентификатор для каждого способа доставки при создании его. Для простоты отладки используйте краткую или сокращенную строку, такой как "discount", "standard", или "next-day".
Некоторые способы доставки не доступны во всех областях или имеют различные затраты для различных адресов. Когда пользователь выбирает адрес поставки или метод, как описано в Способах доставки Обновлений Делегата и Затратах, можно обновить эту информацию.
Указание поддерживаемых механизмов обработки платежей
Укажите, какие платежные системы Вы поддерживаете путем заполнения supportedNetworks свойство с массивом констант жала. Укажите, какие протоколы обработки платежей Вы поддерживаете путем установки значения для merchantCapabilities свойство. Необходимо поддерживать 3DS; поддержка EMV является дополнительной.
Торговые возможности являются битовыми масками и объединены следующим образом:
request.supportedNetworks = @[PKPaymentNetworkAmex, PKPaymentNetworkMasterCard, PKPaymentNetworkVisa];// Supports 3DS onlyrequest.merchantCapabilities = PKMerchantCapability3DS;// Supports both 3DS and EMVrequest.merchantCapabilities = PKMerchantCapability3DS | PKMerchantCapabilityEMV;
Указание, какая информация о поставке и расчетная информация необходимы
Заполните requiredBillingAddressFields и requiredShippingAddressFields свойства авторизации платежа просматривают контроллер для указания то, что необходима тарификация и информация о поставке. При представлении этого контроллера представления он предлагает пользователям предоставлять необходимую информацию. Полевые константы объединены следующим образом для установки значений для этих свойств:
request.requiredBillingAddressFields = PKAddressFieldEmail;request.requiredBillingAddressFields = PKAddressFieldEmail | PKAddressFieldPostalAddress;
Если Вы уже имеете тарификацию и поставку контактной информации, устанавливаете тех на платежном требовании. Несмотря на то, что Оплата Apple использует эту информацию по умолчанию, пользователь может выбрать другую контактную информацию в качестве части процесса авторизации платежа.
ABRecordRef record = ABPersonCreate();CFErrorRef error;BOOL success;success = ABRecordSetValue(record, kABPersonFirstNameProperty, @"John", &error);if (!success) { /* ... handle error ... */ }success = ABRecordSetValue(record, kABPersonLastNameProperty, @"Appleseed", &error);if (!success) { /* ... handle error ... */ }ABMultiValueRef shippingAddress = ABMultiValueCreateMutable(kABMultiDictionaryPropertyType);NSDictionary *addressDictionary = @{(NSString *) kABPersonAddressStreetKey: @"1234 Laurel Street",(NSString *) kABPersonAddressCityKey: @"Atlanta",(NSString *) kABPersonAddressStateKey: @"GA",(NSString *) kABPersonAddressZIPKey: @"30303"};ABMultiValueAddValueAndLabel(shippingAddress,(__bridge CFDictionaryRef) addressDictionary,kABOtherLabel,nil);success = ABRecordSetValue(record, kABPersonAddressProperty, shippingAddress, &error);if (!success) { /* ... handle error ... */ }request.shippingAddress = record;CFRelease(shippingAddress);CFRelease(record);
Хранить дополнительную информацию
Хранить информацию о платежном требовании, которое является определенным для Вашего приложения, таким как идентификатор покупательской корзины, использование applicationData свойство. Это свойство обрабатывается как непрозрачное значение системой. Хеш данных приложения появляется в маркере платежа после того, как пользователь авторизует платежное требование.