Hello -- We're preparing to roll out Apple Pay on website in the next week but encountered some issues during testing.
While we successfully processed transactions using a VISA card, we ran into errors when testing with other card brands. Has anyone come across this issue before?
Apple Pay
RSS for tagDiscuss how to integrate Apple Pay into your app for secure and convenient payments.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
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.
We are looking for sample payload for merchant registration API.
We have tried to test the api and getting an error.
Request:
curl --location 'https://apple-pay-gateway-cert.apple.com/paymentservices/registerMerchant'
--header 'Content-Type: application/json'
--data '{
"domainNames": "https://checkout.dev.sandbox-netvalve.com",
"encryptTo": "platformintegrator.com.netvalve.uat",
"partnerInternalMerchantIdentifier": "merchant.test.netvalve",
"partnerMerchantName": "Test"
}'
Response:
{
"statusMessage": "Payment Services Exception invalid or Malformed Json Received",
"statusCode": "400" }
Topic:
App & System Services
SubTopic:
Apple Pay
When running the test app with test flight before actually opening the app, the execution region is Korea and the country code is Korea, but the currency code on the payment screen is displayed as dollars or euros instead of won. In the payment settings, the currency code is set to won for Korea and dollars for the United States, and the European region is not set at all, but in some phones it is displayed as euros, and in some phones it is not like this, and in some cases it is displayed as won normally.
Hi there,
is there a way, or a list of test cards, to simulate error on payment in an Apple Pay sandbox environment ?
I tried different cards mentioned here but every try was successful : https://developer.apple.com/apple-pay/sandbox-testing/
Topic:
App & System Services
SubTopic:
Apple Pay
We received a request directly from /apple/notifications. This subscription is not a renewal, but a first-time purchase. We associate the originalTransactionId with the user's ID to identify the subscribed user. However, since we do not have access to the user's ID on our server through this direct request, we are unable to properly process the subscription.
How should we handle this type of subscription request?
What is the source of this subscription, and why are some users able to bypass in-app purchases for first-time subscriptions and make the purchase directly?
Topic:
App & System Services
SubTopic:
Apple Pay
We request your support in enabling the extended entitlement feature for our team when creating provisioning profiles. This is because we need to include the ApplePay In-App Provisioning Development extended entitlement in our Bancoagricola app.
Currently, when creating new provisioning profiles, the screen to configure Additional Entitlements is not displayed for our team. However, we have verified with our provider HST (https://hst.com.br/) that this screen does appear in their Apple account.
Thank you very much for your support.
Hello Everyone,
I am trying to integrate apple pay on my website and have followed the following steps.
Created a merchant identifier in my apple developer account.
Generated a payment processing certificate using Certificate signing Request generated through keychain.
Downloaded the certificate and converted that to pem file using the following command
openssl x509 -inform DER -in apple_pay.cer -out apple_pay.pem
Imported the cer file into keychain and exported .p12 file and generated private key using the following command.
openssl pkcs12 -in Certificates.p12 -out private_key.pem -nocerts
Utilizing apple_pay.pem and private_key.pem files for merchant verification call and getting the following response.
cURL Error: OpenSSL SSL_read: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca, errno 0
Trying 17.141.128.7:443...\n* TCP_NODELAY set\n* Connected to apple-pay-gateway.apple.com (17.141.128.7) port 443 (#0)\n* ALPN, offering h2\n* ALPN, offering http/1.1\n* successfully set certificate verify locations:\n* CAfile: /etc/ssl/certs/ca-certificates.crt\n CApath: /etc/ssl/certs\n* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256\n* ALPN, server accepted to use http/1.1\n* Server certificate:\n* subject: businessCategory=Private Organization; jurisdictionC=US; jurisdictionST=California; serialNumber=C0806592; C=US; ST=California; L=Cupertino; O=Apple Inc.; CN=apple-pay-gateway.apple.com\n* start date: Dec 19 00:22:44 2024 GMT\n* expire date: Mar 12 19:42:00 2025 GMT\n* issuer: C=US; O=Apple Inc.; CN=Apple Public EV Server RSA CA 1 - G1\n* SSL certificate verify ok.\n> POST /paymentservices/startSession HTTP/1.1\r\nHost: apple-pay-gateway.apple.com\r\nAccept: /\r\nContent-Type: application/json\r\nContent-Length: 143\r\n\r\n* upload completely sent off: 143 out of 143 bytes\n* OpenSSL SSL_read: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca, errno 0\n* Closing connection
I also tried to include AppleWWDRCAG2 and AppleRootCA-G2 certificated but same response every time.
We have a checkout page on which clients can configure the providers we've integrated with for each currency.
One such provider is Stripe, with which we have already integrated ApplePay and host a merchant domain association file.
Now, we're getting requests to support ApplePay with other providers.
The issue is that we can't tell Apple to use a different path to domain association file for domain verification.
And, replacing the existing domain association file seems like a hack, since I believe it's needed for domain re-verification.
We're thinking of using subdomains for serving the domain association files for different providers.
But, we have some questions on how ApplePay domain verification works to understand how we can solve our problem.
Firstly, can we use subdomains for individual domain verification? If we already have example.com verified with Stripe, can we serve the domain association file for the other provider with provider.example.com and have the verification work?
Secondly, let's say our domain is example.com, and we can use provider.example.com to serve the domain association file and verify the domain. Then on example.com/checkout, will using an iframe with provider.example.com/applepay to host the ApplePay button work?
This thread suggests otherwise, but we want to confirm.
Lastly, is the only way to make an ApplePay payment for provider.example.com to use that subdomain? So redirecting to provider.example.com/applepay would work?
Thanks for your help!
Hi,
We’re a franchise business with over 100 franchisees, and each franchisee has their own unique Merchant ID. We're building a single app that allows customers to place orders, and based on the selected franchisee, the payment needs to be processed through that specific franchisee’s merchant account.
However, when we integrate Apple Pay and publish the app, it asks us to provide a payment gateways' Merchant ID, but we don’t use just one – we have many.
How can we handle this situation? Is there a way to dynamically use multiple Merchant IDs in one app, depending on which franchisee the customer is ordering from?
We have recently begun testing in our production environment and have been unable to push provision any cards, receiving a 500 error:
default 11:15:59.136742-0300 PassbookUIService Response:
https://pr-pod9-smp-device.apple.com:443/broker/v4/devices/SEID_NUMBER/cards 500 Time profile: 0.486102 seconds
{
x-conversation-id = "52463d9f488e428f829633a1518ea72d"
Vary = "accept-language"
Content-Type = "application/json"
x-pod = "pr-pod9"
x-keystone-correlationid = "058F11DE-839F-47AC-A623-741BF32CEA80"
Date = "Thu, 16 Jan 2025 14:15:58 GMT"
x-apay-service-response-details = "via_upstream"
Content-Length = "81"
x-envoy-upstream-service-time = "172"
x-pod-region = "paymentpass.com.apple"
}
{
statusCode = 500;
statusMessage = "Broker Service Response exception";
}
In 05/2024 we received an e-mail from applepayentitlementsapple.com confirming the granting of in-app provisioning entitlements for our production apps.
We've already sent a feedback on Feedback Assistant. Here is the code to track: FB16344669.
Also, we sent another e-mail to applepayentitlementsapple.com, Case-ID: 11317916, but we haven't received a reply yet.
Can you help us? We are concerned, since our pre-certification starts on January 27th.
Thanks in advance.
My Raiffeisen ELBA-App doesnt work anymorw since i downloaded ios 26 beta 3 i cant open the app pls fix it because its my only banking app
Topic:
App & System Services
SubTopic:
Apple Pay
When apple pay on the web does a onshippingcontactselected it appears to truncate the zip code.
If I enter:
11111
or
11111-1111
I always get 11111. Is there any way to get the plus 4?
Is there a way to make a subscription's auto-renewal fail in sandbox environment?
Currently, I see no such options (screenshot)
Topic:
App & System Services
SubTopic:
Apple Pay
We have an app and we want to add tap to pay for Apple Pay. We'd also like to become a certified Payment Service Provider. What is the process to become a certified PSP?
Topic:
App & System Services
SubTopic:
Apple Pay
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
We are trying to develop a coupon/offer code module where our app users can avail a free trail offer for 2 months period after applying the code. We already had a subscription module with monthly & yearly subscriptions with 7 day free trial period. Now, we want to implement a offer/coupon module, where, a user can either select monthly or yearly subscription, and upon entering the offer/coupon code, they will get 2 months free trial (or) a discount on the chosen subscription. (this will overwrite the existing 7 day free trial).
We are confused on choosing the type of “offer/coupon” from AppStore connect. In App Store connect, we have introductory offers, promotional offer & Offer codes. Based on our requirements, we have done research and found that we cannot implement the offer code & promotional codes in the develop environment as there is no possibility to test in Sandbox environment. We observed that we need to push the app to App store and upon approval, we need to implement “offer/coupon” module.
Can some one please suggest or guide us on choosing the best solution for our requirement?
Thanks in advance.
Topic:
App & System Services
SubTopic:
Apple Pay
Tags:
Subscriptions
App Store Connect
In-App Purchase
I have the HCE entitlements, but it's not clear from the documentation I have, how to configure my app as the default app for the double tap of the power button.
Nor can i see where this is in iOS 18.2 settings. The closest I can find is 'Settings > Default Apps > Contactless App', which still shows only Wallet after I install my app with all the new entitlements and provisioning profile. I have these entitlement successfully provisioning my app:
<key>com.apple.developer.nfc.hce</key>
<true/>
<key>com.apple.developer.nfc.hce.iso7816.select-identifier-prefixes</key>
<array>
<string>A0000000031010</string>
<string>A00000002501</string>
<string>A0000000049999</string>
<string>A0000000041010</string>
</array>
<key>com.apple.developer.nfc.hce.default-contactless-app</key>
<true/>
The documentation here: https://developer.apple.com/support/hce-transactions-in-apps/ also references a link to changes in Info.plist, but the url takes me to storekit-external-entitlement documentation about dating apps in the netherlands ???!!!???
Any help would be appreciated to at least get started by allowing me to change the double tap action to my app.
Thanks
Topic:
App & System Services
SubTopic:
Apple Pay
Hi support,
I'm getting the following error when I tried to re-verify my domain:
Domain verification failed. Review your TLS Certificate configuration to confirm that the certificate is accessible and a supported TLS Cipher Suite is used.
I have uploaded the required apple-developer-merchantid-domain-association.txt file and it is reachable from the Internet in the proper location https://www..com/.well-known/apple-developer-merchantid-domain-association.txt.
The SSL certificate has been renewed and it offers at least one of required cipher suites based on the Apple document https://developer.apple.com/documentation/applepayontheweb/setting-up-your-server.
The current verification will expire soon. Need your help urgently.
Thanks,
YaoF
Topic:
App & System Services
SubTopic:
Apple Pay
We are attempting to integrate the Apple Pay service into our website and have successfully verified our domain with Apple manually. However, we consistently receive an 'ApplePay reverify failed' email a month before the expiration time. Upon checking, we updated the SSL certificate for the domain before receiving the email, and the link still works fine in the browser. We would greatly appreciate any feedback from someone who can help us with this issue.