Introduction Why am I writing this article? The reason is simple: a while ago, a new project at my company required us to integrate Google Pay and Apple Pay. The service had already completed its credit card payment flow. However, management later requested support for Google Pay and Apple Pay as well. Since none of our previous company projects had integrated Apple Pay, I became the first person in the company to take on this task. With the help of AI, the payment integration itself was completed in about one day. However, a new problem came up: The code was finished, but how were we supposed to test it in the UAT environment? This is basically a record of my experience and the problems I encountered while testing Apple Pay in the Sandbox environment. I hope it helps other engineers who are stuck in a similar testing environment. Problem 1: How to Configure the CER and Private Key At the moment, I only have a .p12 file. The payment integration side has already configured the Apple Pay certificate and generated the corresponding CSR. The only remaining step is to configure the environment variables on the application side. The contents of a .p12 file are generally as follows: .p12 ├── Certificate ├── Private Key └── Certificate Chain (may be included) The overall process is: .p12 ├── Extract the Certificate / PEM ├── Extract the Private Key └── Verify that the CSR, Certificate, and Private Key belong to the same key pair The following process uses OpenSSL: # Inspect the p12 contents without outputting the private key openssl pkcs12 -info -in apple-pay.p12 -noout # Extract the certificate openssl pkcs12 \ -in apple-pay.p12 \ -clcerts \ -nokeys \ | openssl x509 -out cert.pem # Extract the private key openssl pkcs12 \ -in apple-pay.p12 \ -nocerts \ -nodes \ | openssl pkey -out private-key.pem -nodes means that the exported private key will not be encrypted again. Therefore, the generated private-key.pem must be stored securely. It should never be committed to Git or printed in logs. Verifying That the Certificate and Private Key Match The simplest way is to extract the public key from the certificate and the private key, then compare their hash values. # Public key from the certificate openssl x509 -in cert.pem -pubkey -noout \ | openssl pkey -pubin -outform DER \ | shasum -a 256 # Public key corresponding to the private key openssl pkey -in private-key.pem -pubout \ | openssl pkey -pubin -outform DER \ | shasum -a 256 If the hash values produced by the two commands are identical, the certificate and private key belong to the same key pair. If you also need to verify the CSR, run the following command: # Public key corresponding to the CSR openssl req -in request.csr -pubkey -noout \ | openssl pkey -pubin -outform DER \ | shasum -a 256 If the hash values of the CSR, certificate, and Private Key are all identical, it means that all three use the same key pair. Architecture Terminology p12 .p12 is a PKCS#12 container file. It can usually contain: Certificate Private Key Certificate Chain Password protecting the private key Therefore, under normal circumstances, the .p12 file already contains the certificate and private key required by the payment service. However, you still need to confirm the purpose of the .p12 file. Common Apple Pay certificates include: Merchant Identity Certificate: Used to authenticate Merchant Sessions for Apple Pay on the Web. Payment Processing Certificate: Used to encrypt payment data. Decryption is usually handled by the merchant or the PSP (Payment Service Provider). These two certificates have different purposes. You cannot assume that every .p12 file can be used as every type of Apple Pay certificate. PEM PEM stands for Privacy-Enhanced Mail. It is a text-based encoding format. Certificates, private keys, and CSRs may all be stored in PEM format. Example of a certificate PEM: -----BEGIN CERTIFICATE----- ... ... ... -----END CERTIFICATE----- Private Key A private key is also usually stored in PEM format. -----BEGIN PRIVATE KEY----- ... ... ... -----END PRIVATE KEY----- CSR CSR stands for Certificate Signing Request. The usual process is to generate a CSR first, then upload it to Apple Developer to obtain a CER. A CSR contains the public key, application information, and a signature generated using the corresponding Private Key. However, it does not contain the Private Key itself. -----BEGIN CERTIFICATE REQUEST----- ... ... ... -----END CERTIFICATE REQUEST----- CER A CER is a certificate file issued by Apple. Its file extension is usually .cer. Problem 2: The Apple Pay Screen Works, but the Card Cannot Be Added Situation The Apple Pay configuration for the website was complete, and the Apple Pay button was displayed correctly. Clicking the button also opened the Apple Pay payment screen. I then opened the Apple Pay Sandbox Testing page and tried to add Visa, Mastercard, and JCB test cards to Wallet. Many iOS testing guides mention enabling Developer Mode and adding the newly created Sandbox Account to the Sandbox settings. However, none of the cards could be added. Many guides introduce the following steps: Enable Developer Mode. Create a Sandbox Account. Add the Sandbox Account to the test settings. In reality, these steps are not enough. What Is Developer Mode? Developer Mode allows the device to run apps that are still under development. Enabling Developer Mode does not automatically switch the device to Apple Pay Sandbox mode, nor does it mean that test cards can be added directly to Wallet. What Is a Sandbox Account? A Sandbox Account is a test account created in App Store Connect. It is used to test Apple Pay, In-App Purchases, and other sandbox features. It can usually be created here: App Store Connect → Users and Access → Sandbox → Testers When creating the account, make sure that the Email address has not already been registered as a regular Apple Account. Using an existing Email address may cause login or verification problems.Official Apple Sandbox Account documentation The Correct Apple Pay Testing Process The general Apple Pay Sandbox testing process is as follows: Create a Sandbox Tester Account in App Store Connect. Confirm that the test device supports Apple Pay. Set the device region to an Apple Pay-supported region, such as Taiwan. Sign out of the Apple Account or iCloud account previously used on the test device. Sign in to the test device using the Sandbox Account. Open Wallet. Select the option to add a credit or debit card. Manually enter the test card information provided on Apple’s official page. Apple’s test card page mainly provides test FPANs, CVVs, CVCs, and expiration dates. It is not a page that directly adds cards to Wallet. It is also recommended to use a physical device for Apple Pay testing. Make sure the device has a passcode, Face ID, or Touch ID configured. Apple’s official process is to sign out of the existing iCloud account, sign in to the device using the Sandbox Tester Account, and then manually add the test card from Wallet.Apple Pay Sandbox Testing Problem 3: iCloud 34608 Appears After Signing In to the Sandbox Account Situation Some people may have already signed out of their original Apple Account and attempted to sign in with a Sandbox Account. However, after entering the account and password, the iPhone may remain stuck on the account setup animation and eventually display the iCloud 34608 error. This error message is not very informative. Apple has not published a complete official explanation for error 34608, and the information available online is scattered. Therefore, the following is the approach I used to troubleshoot the problem. First, make sure that the registered Email address is new and has never been registered as a regular Apple Account. If you have made it this far, I believe most readers are probably not stuck at this step. After confirming that the Email address is new, log in to the Apple Account management page using a browser. If the system asks you to complete any of the following verification steps, make sure to complete them: Phone number verification Two-factor authentication Account security settings Acceptance of the terms and conditions This is a common problem in corporate testing environments. A company may use a test device that has not completed phone verification or multi-factor authentication. This can cause an iCloud error during account login and prevent the Apple Account from being added to the iPhone. After completing the verification steps above, return to the test device and sign in to the Sandbox Account again. If it still fails, restart the device, confirm that the original Apple Account has been signed out, and try again. Final Testing Checklist If you are testing Apple Pay Sandbox from scratch, I recommend checking the following items in order: The Merchant ID has been created. The purpose of the Apple Pay certificate has been confirmed. The CSR, certificate, and Private Key have been verified to belong to the same key pair. A Sandbox Tester Account has been created in App Store Connect. The Email address used by the Sandbox Account has never been registered as a regular Apple Account. The test device supports Apple Pay. Developer Mode is enabled on the test device. The test device region is set to an Apple Pay-supported region. The original Apple Account or iCloud account has been signed out. The test device is signed in with the Sandbox Account. The official Apple test card has been manually added to Wallet. The Apple Pay Web Merchant Domain has been verified. The website uses HTTPS and the server’s TLS configuration has been checked. Sandbox and Production payment environments are not mixed. Payment tokens and Private Keys are not printed in logs. Conclusion This article mainly covered the following three points: A .p12 file is a container, not simply a certificate. You need to extract the certificate and Private Key from it and verify that they belong to the same key pair. Apple Pay Sandbox is not just about enabling Developer Mode. You also need to create a Sandbox Account correctly, sign in to the test device, and manually add a test card through Wallet. If iCloud 34608 appears, the problem may not be in the Apple Pay code. It may be caused by incomplete Sandbox Account verification or an incomplete device login process. The most misleading part of Apple Pay testing is assuming that “the payment screen appears” means the entire payment flow is working correctly. Certificates, accounts, Wallet, Apple Pay Sessions, and the final decryption of payment data all have their own testing requirements. By checking each stage separately, you can usually identify the actual source of the problem much faster. The original article was written in Traditional Chinese, and the Japanese and English versions were translated using ChatGPT.