If you have had the challenge of getting Apple Pay to work when using TLS decryption, you’ll more than likely find that it is a royal pain to figure out how it works.

The challenge with TLS decryption is when a TLS client (in this case Apple Pay) doesn’t return any useful error messages to help pin-point what needs to be excluded from TLS decryption.

Some steps that I thought would help understand the TLS decryption process for Apple Pay:

• Packet captures – too many to think of!
• My network is IPv6 enabled, maybe the Apple Pay connection was happening over IPv6?
• Downgrade TLSv1.3 to TLSv1.2 (in case there was encrypted SNI taking place)

This naturally took an age figure out and still I came up with nothing!

Given that my original troubleshooting was requiring me to find a valid amount to pay a merchant, I would typically go through these steps:

1. Begin with a mighty sense of determination to finally get this fixed.
2. Proceed to setup all the packet captures possible on the device performing the TLS decryption.
3. Attempt to make a payment through my iPhone.
4. Review packet captures until the 1’s and 0’s just became a garbled mess.
5. Resign to the fact that today was not the day I would fix it.

That is until I stumbled upon an interesting website called Apple Pay Demo – https://applepaydemo.apple.com/

This allowed me simulate “fake payments” and more importantly, I could run this in Safari on a macbook as well as run packet captures on the endpoint to see what hosts it was talking to.

Low and behold, Apple Pay was communicating with this host smp-paymentservices.apple.com.

I created a TLS decryption exclusion and voila! It finally started working. If you need a list of hostnames that do not like TLS decryption, feel free to look at this post Crowdsourcing Pinned Certificate Information

Having said that, Apple makes it exceptionally difficult (!) to find the right content to troubleshoot any advanced issue. Please Apple, make our troubleshooting lives simple again!