Hello, We are working on integrating billing into our dating app, targeted at the Russian market. Our main requirement is to support subscriptions with automatic renewal and cancellation. We understand that, according to App Store Review Guideline, all digital subscriptions should use Apple In-App Purchase (IAP). However, we are unsure how this applies in Russia, where some local regulations may limit the use of non-Russian payment processors, and where not all Russian bank cards are accepted by Apple. Our question is: -For iOS apps in Russia, is it strictly required to use Apple IAP for subscriptions? -Are there any approved exceptions allowing integration with local processors such as Robokassa or YooKassa? -How are other developers currently handling subscriptions for the Russian market? We want to ensure full compliance and avoid any risk of rejection or removal. Thank you in advance for any clarification. Best regards, Dan

Hi, we are implementing ID&V and there is a requirement regarding the flow for Apple Pay. In order to clarify the case I will describe the use case scenario or steps to reproduce first: add a card to the iPhone wallet app (yellow path verification required). Do not complete the ID&V process. add a card to the Watch via the Wallet inside the iPhone Watch app (yellow path verification required). Same as before, do not complete the ID&V complete ID&V process using the Issuer App either from iPhone or Watch. the Issuer app receives the application:openURL:options: callback on its AppDelegate. In the options dictionary, we can not see the UIApplicationOpenURLOptionsSourceApplicationKey populated (it is nil). At this moment, for the card we are adding there are now two tokens, both to be verified via ID&V process. One is on the iPhone and one is on the Apple Watch associated with the same iPhone. The url received at step 4 contains the serial number which identifies the digitized card and matches with both the tokens in the iPhone and in the Apple Watch. We need something to detect programmatically if the digitization process started from the iPhone Wallet app or from the wallet inside the Watch app. Could you please help us to identify how we could discriminate if the ID&V process has been started for the iPhone token or for the Apple Watch token? Thanks

Hi , This is regarding the ApplePayRecurringPayment Request and Apple Pay on Web functionality. Does Apple Pay on web providing functionality that collects payments from the stored credit card issuer bank (or) it only provides secured wallet functionality that provides a token which then has to be utilized to send a seperate payment request through a third party payment gateway to collect the payments from the credit card issuer bank. thanks

On Applepay's docs it talks about the ability to do "flexible" payments and scheduling for future purchases. We need to be able to make only a single approval of an Apple payment for multiple submissions later on. Think, deferred payments at an arbitrary schedule without presenting the ApplePay dialog each and every time. The docs suggest that may be possible, but are maddeningly vague on how to do that. Is it possible or not? Can we store an approved merchant's token for example and leverage that for future transactions?

Hi, for iOS in-app push provisioning flow, and for a card that is in already in requiresActivation state, is it possible from our app UI to launch to the card's verification screen either as a in-app flow (like how in-app push provisioning flow is doing) or Apple Wallet? So far the current process is that it will prompt user to provision the card again (only to show This Card is Already in Wallet error), or to open the card in tap-to-pay mode, or adding a new card flow in Apple Wallet. Am I missing any PassKit SDK on this?

Hi. I am writing to request clarification regarding the renewal period of the merchant certificate. According to the documentation, Apple issues merchant certificates for 25 months, and this has been the case for several years. However, in the past six months, the issued certificates have been valid for only 3 months, which causes significant inconvenience. I have reviewed the documentation again and contacted support, but I was only referred back to the same information stating that the certificate should be valid for 25 months. Could you please clarify whether there have been any recent changes to the renewal policy? Additionally, is there a way to extend the certificate's validity to the expected 25-month period? I would greatly appreciate your assistance in resolving this issue.

I'm encountering an issue with Apple Pay on both Wallet and the Watch app where the app name is not showing up on the back of the payment card(Card details). The pass was successfully provisioned, and everything seems to be working, but the expected app name or brand isn't displayed, and instead, I see the generic "Something went wrong. Try again Later" message. Do we need to configure something to get this displayed in Wallet app?

Can i, personally, create .pkpass for other companies using my apple developer ID? In order to create .pkpass, I need to create passTypIdentifier and teamIdentifier using apple developer ID Is it okay to create those two identifiers and create coupons or membership cards for other companies? I just wonder if it is against the law or developer guide.

When accessing https://applepaydemo.apple.com/payment-request-api, the "Approve with Side Button" prompt is displayed, but it does not appear when using our test domain. I implemented the Payment Request API based on the sample source code from the following URL. On an iPhone device, the Apple Pay payment screen is displayed, but the "Approve with Side Button" icon below the amount does not appear, and instead a spinning loading icon is shown continuously. Could you please help identify the cause? ■ Reference URL: https://applepaydemo.apple.com/payment-request-api ■ Changed parameter: "merchantIdentifier": "〇〇.dev" ■ Accessed domain: 〇〇test.com ■ Test device: iPhone 13 iOS: 18.4.1

Our company sells insurance and we'd like to offer annual renewals via Apple Pay on the Web. Most of the docs seem to point towards using recurringpaymentrequest but this method required an amount value which would only be calculated at renewal time. It appears that Shopify is doing something akin to what we want where they do auto payments so my question is can we do annual payments with unknown renewal prices with Apple Pay for Web ? What we cannot do is show the renewal price like this as it being insurance is almost certain to change. This is our current code which works but won't get past the regulator. const applePayPaymentRequestAnnual = { countryCode: 'GB', currencyCode: 'GBP', supportedNetworks: ['visa', 'masterCard'], merchantCapabilities: ['supports3DS'], requiredBillingContactFields: ['postalAddress', 'email'], requiredShippingContactFields: ['phone'], recurringPaymentRequest: { paymentDescription: 'Annual Insurance Renewal', regularBilling: { label: 'Annual Renewal Premium', amount: price, paymentTiming: "recurring", recurringPaymentIntervalUnit: "year", recurringPaymentStartDate: year + "-" + month + "-" + day + "T00:00:00.000Z", type: 'final' }, managementURL: window.location.protocol + '//' + window.location.host + '/manage-policy', tokenNotificationURL: window.location.protocol + '//' + window.location.host + '/apple-pay-notifications' }, lineItems: [{ label: alabel, amount: price, }], total: { label: alabel, amount: price, type: "final" }, }

Hi, I'm developer in fintech company, we have setup process for onboarding merchants for our partner and processing payments with usage of Apple Pay API. Daily system is processing ca. 10k payments but every day ca. 100 of transactions are declined because of merchant validation error: request to https://apple-pay-gateway.apple.com/paymentservices/paymentSession (with all required parameters in body) is returning response with status code 417 "statusMessage": "Payment Services Exception merchantId={root merchant id} unauthorized to process transactions on behalf of merchantId={merchant id hash} reason={merchant id hash} is not a registered merchant in WWDR and isn't properly authorized via Mass Enablement, either." Issue impacts recurring merchants, most of their transactions are processed successfully but randomly some of them are failing with such reason. All prerequisites are met: merchant have deployed 'apple-developer-merchantid-domain-association' certificate, certificates are valid and not expired. Apple Support is not able to provide any information based on provided requests timestamps. We would to know what may be the reason just part of the requests are failing and what 417 error code means.

all mastercard cards expired in 2024

We have verified our domain but if the file is removed from the deployed site after verification will this impact using ApplePaySession.applePayCapabilities in real time? We use that method from the JS api in our React app to determine whether or not to show the apple pay button. When that function is called in the browser, do the apple servers ping the https://our.domain.com/.well-known/apple-developer-merchantid-domain-association URL at that time? Or do they check for it periodically? The reason for asking is that with our many environments we wonder if we can verify each environment's domain by adding the file once. The file will be wiped out by our CICD process as it goes up the environment stack through our development workflow. Or do we need to maintain that file for each environment and add something to our build process?

Body: Hello, We are currently implementing iOS order verification and have encountered an issue. Some of the receipts we verify return with an empty in_app array, which makes it impossible to determine whether there is a valid in-app purchase. Below is the code we’re using for verification and the result we receive: Code Example: public function iosVerifyReceipt($receipt, $password = '', $sandbox = false) { $url = $sandbox ? 'https://sandbox.itunes.apple.com/verifyReceipt' : 'https://buy.itunes.apple.com/verifyReceipt'; if (empty($password)) { $data = json_encode(['receipt-data' => $receipt]); } else { $data = json_encode(['receipt-data' => $receipt, 'password' => $password]); } $ch = curl_init($url); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); curl_setopt($ch, CURLOPT_POST, true); curl_setopt($ch, CURLOPT_POSTFIELDS, $data); $result = curl_exec($ch); curl_close($ch); $result = json_decode($result, true); $result = $result ?? []; $result['sandbox'] = $sandbox; if ($result['status'] != 0) { Log::warning('ios verify receipt failed', ['receipt' => $receipt, 'result' => $result, 'sandbox' => $sandbox]); if ($result['status'] == 21007) { return $this->iosVerifyReceipt($receipt, $password, true); } } return $result; } // Order validation check if (empty($result) || $result['status'] != 0) { throw new BadRequestHttpException("Ios Order Verify Error"); } $appItemId = $result['receipt']['app_item_id'] ?? ""; if ($appItemId != MY_APP_ID) { throw new BadRequestHttpException("Ios Order Verify Error"); } $inApp = array_filter($result['receipt']['in_app'] ?? [], function ($item) use ($transactionId, $order) { return $item['transaction_id'] == $transactionId && $item['product_id'] == $order->getProductId(); }); if (empty($inApp)) { throw new BadRequestHttpException("Ios Order Verify Error"); } Array ( [receipt] => Array ( [receipt_type] => Production [adam_id] => * [app_item_id] => * [bundle_id] => * [application_version] => * [download_id] => * [version_external_identifier] => * [receipt_creation_date] => 2025-02-11 04:06:47 Etc/GMT [receipt_creation_date_ms] => * [receipt_creation_date_pst] => 2025-02-10 20:06:47 America/Los_Angeles [request_date] => 2025-02-11 15:54:56 Etc/GMT [request_date_ms] => * [request_date_pst] => 2025-02-11 07:54:56 America/Los_Angeles [original_purchase_date] => 2025-02-11 04:02:41 Etc/GMT [original_purchase_date_ms] => * [original_purchase_date_pst] => 2025-02-10 20:02:41 America/Los_Angeles [original_application_version] => 5511 [preorder_date] => 2025-01-17 21:12:28 Etc/GMT [preorder_date_ms] => * [preorder_date_pst] => 2025-01-17 13:12:28 America/Los_Angeles [in_app] => Array ( ) ) [environment] => Production [status] => 0 [sandbox] => ) Problem Description: • We are noticing that in some orders, the in_app array is returned as empty. This causes difficulty in verifying the presence of in-app purchases. • Our validation logic assumes that if in_app is empty, the order is invalid, but we would like clarification on whether this is correct or if such a scenario is normal under certain conditions. Actions Taken: • We have reviewed Apple’s documentation and other related resources, but no clear explanation is given about when in_app might be empty. • Can we safely rely on an empty in_app array to consider the order invalid, or should we investigate further for potential issues like delays or errors during the verification process? We would appreciate your guidance on how to handle such cases. Thank you for your support!

Hi, We're experiencing an issue with verifying our domain for Apple Pay on the web. It's currently stuck in the "Pending" state despite meeting the listed requirements. The domain in question has been verified once successfully but one month later when we renewed the SSL, we were unable to verify the domain again. Please note that the new certificate's CA chain has been changed. A) The "apple-developer-merchantid-domain-association.txt" file is publicly accessible at the following location: /.well-known/apple-developer-merchantid-domain-association.txt B) We've also ensured that the following IP ranges are whitelisted: 17.32.139.128/27 17.32.139.160/27 17.140.126.0/27 17.140.126.32/27 17.179.144.128/27 17.179.144.160/27 17.179.144.192/27 17.179.144.224/27 17.253.0.0/16 17.23.4.96/27 17.132.108.64/26 17.23.24.32/27 17.23.19.0/27 17.157.40.128/27 17.157.44.128/27 17.157.32.0/27 C) Our servers support TLS 1.2 already. D) "ECDHE-RSA-AES128-GCM-SHA256" cipher suite has been used, so we believe all necessary criteria are satisfied. However, when we attempt to verify the domain, we receive the following error message: "Domain verification failed. Review your TLS Certificate configuration to confirm that the certificate is accessible and a supported TLS Cipher Suite is used." Could you please advise why the verification is failing, or let us know if there's anything we might have missed? Best regards, Mehdi

Hello! I have a requirement to read the ICC Public Key Certificate from an EMV credit card to implement a payment validation flow. Aa far as I understand, I can't use Core NFC for that task since it is not supposed to be used for reading sensitive credit card data and it might be rejected by Apple. I'm trying to use Tap To Pay as it seems to offer some general card details. Since Apple's documentation on this side is pretty limited, I'm struggling to understand what is a PaymentCardReader.Token and how can I create one? Can anyone please help me with setting up Tap to Pay?

I'm successfully using Apple subscriptions in my app, but I'm encountering SKErrorCodeDomain error 18 when trying to apply a subscription offer. I want apply offer code first time only for subscription. Below are details of what i set in appstore and what i have tested. Subscription Offer Details Offer Type: For the first month Customer Eligibility: New, Existing, and Expired Subscribers Code Status: Active Offer Code Creation Steps: App Store Connect → App → Subscription → Select Subscription Product → Offer Codes → Add → Add Custom Codes Signature Generation for Promotional Offers I'm following Apple's documentation to generate a signature: https://developer.apple.com/documentation/storekit/generating-a-signature-for-promotional-offers I’ve constructed the payload as instructed: appBundleId + '\u2063' + keyIdentifier + '\u2063' + productIdentifier + '\u2063' + offerIdentifier + '\u2063' + appAccountToken + '\u2063' + nonce + '\u2063' + timestamp Keys and Identifiers keyIdentifier, issuerId, and .p8 file are obtained from: App Store Connect → Users and Access → Integrations → In-App Purchase Test user created under: App Store Connect → Users and Access → Sandbox → Test Accounts Logged in with this account on the iPhone What I’ve Tried Verified all values used in the payload are correct Tried both seconds and milliseconds for the timestamp (as per documentation, it should be in milliseconds) Tried setting appAccountToken to: a valid UUID an empty string not setting it at all Used Apple’s sample code to generate a signature: https://developer.apple.com/documentation/storekit/generating-a-promotional-offer-signature-on-the-server Verified the generated signature locally, and it validated successfully: https://developer.apple.com/documentation/storekit/generating-a-signature-for-promotional-offers#Validate-locally-and-encode-the-signature Apple’s sample code to generate a signature Downloaded from const express = require('express'); const router = express.Router(); const crypto = require('crypto'); const ECKey = require('ec-key'); const secp256k1 = require('secp256k1'); const uuidv4 = require('uuid/v4'); const KeyEncoder = require('key-encoder'); const keyEncoder = new KeyEncoder('secp256k1'); const fs = require('fs'); function getKeyID() { return "KEYIDXXXXX"; } router.post('/offer', function(req, res) { const appBundleID = req.body.appBundleID; const productIdentifier = req.body.productIdentifier; const subscriptionOfferID = req.body.offerID; const applicationUsername = req.body.applicationUsername; const nonce = uuidv4(); const currentDate = new Date(); const timestamp = currentDate.getTime(); const keyID = getKeyID(); const payload = appBundleID + '\u2063' + keyID + '\u2063' + productIdentifier + '\u2063' + subscriptionOfferID + '\u2063' + applicationUsername + '\u2063'+ nonce + '\u2063' + timestamp; // Get the PEM-formatted private key string associated with the Key ID. // const keyString = getKeyStringForID(keyID); // Read the .p8 file const keyString = fs.readFileSync('./SubscriptionKey_47J5826J8W.p8', 'utf8'); // Create an Elliptic Curve Digital Signature Algorithm (ECDSA) object using the private key. const key = new ECKey(keyString, 'pem'); // Set up the cryptographic format used to sign the key with the SHA-256 hashing algorithm. const cryptoSign = key.createSign('SHA256'); // Add the payload string to sign. cryptoSign.update(payload); /* The Node.js crypto library creates a DER-formatted binary value signature, and then base-64 encodes it to create the string that you will use in StoreKit. */ const signature = cryptoSign.sign('base64'); /* Check that the signature passes verification by using the ec-key library. The verification process is similar to creating the signature, except it uses 'createVerify' instead of 'createSign', and after updating it with the payload, it uses `verify` to pass in the signature and encoding, instead of `sign` to get the signature. This step is not required, but it's useful to check when implementing your signature code. This helps debug issues with signing before sending transactions to Apple. If verification succeeds, the next recommended testing step is attempting a purchase in the Sandbox environment. */ const verificationResult = key.createVerify('SHA256').update(payload).verify(signature, 'base64'); console.log("Verification result: " + verificationResult) // Send the response. res.setHeader('Content-Type', 'application/json'); res.json({ 'keyID': keyID, 'nonce': nonce, 'timestamp': timestamp, 'signature': signature }); }); module.exports = router; Postman request and response Request URL: http://192.168.1.141:3004/offer Request JSON: { "appBundleID":"com.app.bundleid", "productIdentifier":"subscription.product.id", "offerID":"OFFERCODE1", "applicationUsername":"01234b43791ea309a1c3003412bcdaaa09d39a615c379cc246f5f479760629a1" } Response JSON: { "keyID": "KEYIDXXXXX", "nonce": "f98f2cda-c7a6-492f-9f92-e24a6122c0c9", "timestamp": 1753510571664, "signature": "MEYCIQCnA8UGWhTiCF+F6S55Zl6hpjnm7SC3aAgvmTBmQDnsAgIhAP6xIeRuREyxxx69Ve/qjnONq7pF1cK8TDn82fyePcqz" } Xcode Code func buy(_ product: SKProduct) { let discountOffer = SKPaymentDiscount( identifier: "OFFERCODE1", keyIdentifier: "KEYIDXXXXX", nonce: UUID(uuidString: "f98f2cda-c7a6-492f-9f92-e24a6122c0c9")!, signature: "MEYCIQCnA8UGWhTiCF+F6S55Zl6hpjnm7SC3aAgvmTBmQDnsAgIhAP6xIeRuREyxxx69Ve/qjnONq7pF1cK8TDn82fyePcqz", timestamp: 1753510571664) let payment = SKMutablePayment(product: product) payment.applicationUsername = "01234b43791ea309a1c3003412bcdaaa09d39a615c379cc246f5f479760629a1" payment.paymentDiscount = discountOffer SKPaymentQueue.default().add(payment) } Issue Even following instructions to the documentation and attempting various combinations, the offer keeps failing with SKErrorCodeDomain error 18. Has anyone else experienced this? Any suggestions as to what may be amiss or how it can be corrected?

Hi, I’ve been trying to integrate Apple Pay, but for some reason, the payment button is not showing up. The project is built with Laravel 11 and Vue. I imported the script as follows: <script crossorigin crossorigin src="https://applepay.cdn-apple.com/jsapi/1.latest/apple-pay-sdk.js" ></script> Then I added the following the steps: <style> apple-pay-button {{ --apple-pay-button-width: --apple-pay-button-width: 150px;; --apple-pay-button-height: --apple-pay-button-height: 30px;; --apple-pay-button-border-radius: --apple-pay-button-border-radius: 3px;; --apple-pay-button-padding: --apple-pay-button-padding: 0px 0px;; --apple-pay-button-box-sizing: border-box; } </style> <apple-pay-button buttonstyle="black" type="plain" locale="en-US"></apple-pay-button> I followed all the steps from the official Apple Pay demo: https://applepaydemo.apple.com/ I also configured the Content Security Policy (CSP) to allow all necessary resources. However, when I test my integration, the button doesn’t appear. I’ve checked the console, but there are no errors. At the same time, I have my certificate imported into the Keychain, and I’ve completed the entire process of creating both the certificate and the private key. However, when I try to validate the session using the certificate and key with Apple’s API, I get an error: 400 The SSL certificate error https://apple-pay-gateway-cert.apple.com/paymentservices/

We have an Apple Pay account and have successfully created and verified the payment processing certificate in our Apple Developer account. When initiating an Apple Pay payment, the Apple session is created successfully with the correct data return from api , but it is not accepted with the error: “Payment not completed.” The issue occurs even though the merchant validation step works without errors. Our websites where this is happening are: https://magicdeliver.com/ https://www.pulsarmodular.com/ Could you please help us identify the cause of the issue and guide us on resolving it?

I'm trying to create an Apple Pay session for my website. I'm starting with curl for now, just to get proof of concept. curl --cert cert.pem --pass {passphrase} --header "Content-Type: application/json" --request POST --data '{"merchantIdentifier":"{merchantIdentifier}","displayName":"testDisplayName", "initiative": "web", "initiativeContext": "{domain}"}' https://apple-pay-gateway.apple.com/paymentservices/paymentSession This is the response I get back { "statusMessage": "Payment Services Exception merchantId={VERY-LONG-ID} not registered for domain={domain}", "statusCode": "400" } I'm not sure why this is happening. {domain} is in the form of sub.site.tld with no protocol, such as https, which matches what I see in the list of the domains in the merchant identity dashboard. The {merchantIdentifier} also matches what I see in the top right, but the merchantId in the response is something I don't recognize. It's a long string of characters that appears to be hexadecimal. I added the apple-developer-merchantid-domain-association file to my .well-known directory and the dashboard does report that the domain is verified. I am making the request from the web server that the domain resolves to, if that matters. I can't think of any reason this would be happening. I'm not sure where the long merchantId in the response is coming from. Does it matter that it doesn't match what I supplied in the request? As far as I can tell, I am using the correct merchantIdentifier. It matches the dashboard and the CN field of the certificate. I found this other post that seems to have a similar error: https://forums.developer.apple.com/forums/thread/671227 The main difference is a 417 status code instead of the 400 I got. But the problem here was that there was no payment processing certificate and I do have one of those. I haven't checked with my processor to verify that the certificate is published, but I will do that soon. I wouldn't expect that to matter. Maybe it does? What other reason could I be getting this error? Could it be a problem with my merchant identity certificate? It took a lot of effort to make it work. But I suspect it's fine, otherwise I wouldn't be getting a response from Apple at all. I can't think of any other possible problems.