~15s Delay in startSession

Hello,

We are experiencing a consistent delay when initiating Apple Pay sessions using the https://apple-pay-gateway.apple.com/paymentservices/startSession endpoint. Below is a detailed overview of our setup and the issue.

Setup

  • Our web service is hosted in AWS and there is a proxy server between our web service and Apple servers.
  • We are passing the correct domain in the initiativeContext field of the startSession request.
  • The .well-known/apple-developer-merchantid-domain-association file is hosted on a different domain, which is also correctly configured and associated with our merchant ID in the Apple Developer portal.

Observed Behavior

  • When the same request is made from a local development environment, Apple responds immediately (under 1 second).
  • When the request is made from our AWS-hosted service, Apple responds with a valid session, but only after a consistent ~15-second delay.
  • The content and response are otherwise identical — only the timing differs.

We would appreciate any insights or suggestions from others who have faced similar behavior or from the Apple Pay team.

Thank you in advance!

Answered by DTS Engineer in 893987022

Hi @nikos_lapokonstantakis, @hughdog,

You wrote:

[...] When the request is made from our AWS-hosted service, Apple responds with a valid session, but only after a consistent ~15-second delay. [...]

15 seconds is a very common timeout/fallback threshold in web development. I'd suggest investigating the following:

  1. IPv6 Black-Hole. Your proxy tries iPv6 first, but AWS has no IPv6 egress route. The packet is silently dropped, and you app waits the full 15-second timeout before falling back to IPv4, which works instantly. Fix this by disabling IPv6 on the proxy or forcing iPv4 in your app.
  2. Stale Proxy Connection Pool. Your proxy reuses a "kept-alive" connection to Apple Pay that Apple already silently closed. Your app writes into a dead socket, TCP retransmits for exactly 1+2+4+8 = 15 seconds, then gives up and opens a fresh connection that succeeds immediately. Fix this by setting the proxy's connection pool TTL below Apple's idle timeout.
  3. OSCP Certificate Validation Timeout. During the TLS handshake, your app tries to verify Apple's certificate by fetching http://ocsp.apple.com over port 80. That port is typically blocked by AWS, so the request silently hangs for 15 seconds before giving up. Fix this by allowing outbound port 80 to OCSP endpoints, or disabling OCSP revocation checking.
  4. Proxy SSL Inspection Stripping the Client Certificate. If your proxy performs SSL inspection, it intercepts the TLS connection and re-originates it without forwarding your Apple Pay merchant certificate. Apple waits for it, times out after ~15 seconds, then falls back. Fix this by exempting apple-pay-gateway.apple.com from SSL inspection entirely.

Note: The quickest way to pinpoint which issue is the underlying cause is to run curl --write-out with timing fields from your AWS host and look at which phase gap (DNS, TCP connect, TLS handshake, or TTFB) accounts for the 15 seconds.

Cheers,

Paris X Pinkney |  WWDR | DTS Engineer

@nikos_lapokonstantakis

Did you ever figure out a solution?

Having the same problem calling https://apple-pay-gateway-cert.apple.com/paymentservices/merchant using mTLS in my AWS environment.

I'm just using a simple httpclient..

builder.Services.AddHttpClient("ApplePayClient")
    .ConfigurePrimaryHttpMessageHandler(() =>
{
    var handler = new HttpClientHandler
    {
        ClientCertificateOptions = ClientCertificateOption.Manual,
        ClientCertificates = { applePayCertificate }
    };
    return handler;
});

Have no issues on local and struggling to find a solution.

Feel like there's a setting in AWS which is causing an issue but any suggestions would be great.

Hello @hughdog ,

I have not found a solution yet. Do you also face a 15-sec delay? As you said, maybe something is not properly configured in the AWS environment. Have you checked the time duration regarding the communication between Apple and your AWS environment (TLS handshake, server response time)?

Hi @nikos_lapokonstantakis, @hughdog,

You wrote:

[...] When the request is made from our AWS-hosted service, Apple responds with a valid session, but only after a consistent ~15-second delay. [...]

15 seconds is a very common timeout/fallback threshold in web development. I'd suggest investigating the following:

  1. IPv6 Black-Hole. Your proxy tries iPv6 first, but AWS has no IPv6 egress route. The packet is silently dropped, and you app waits the full 15-second timeout before falling back to IPv4, which works instantly. Fix this by disabling IPv6 on the proxy or forcing iPv4 in your app.
  2. Stale Proxy Connection Pool. Your proxy reuses a "kept-alive" connection to Apple Pay that Apple already silently closed. Your app writes into a dead socket, TCP retransmits for exactly 1+2+4+8 = 15 seconds, then gives up and opens a fresh connection that succeeds immediately. Fix this by setting the proxy's connection pool TTL below Apple's idle timeout.
  3. OSCP Certificate Validation Timeout. During the TLS handshake, your app tries to verify Apple's certificate by fetching http://ocsp.apple.com over port 80. That port is typically blocked by AWS, so the request silently hangs for 15 seconds before giving up. Fix this by allowing outbound port 80 to OCSP endpoints, or disabling OCSP revocation checking.
  4. Proxy SSL Inspection Stripping the Client Certificate. If your proxy performs SSL inspection, it intercepts the TLS connection and re-originates it without forwarding your Apple Pay merchant certificate. Apple waits for it, times out after ~15 seconds, then falls back. Fix this by exempting apple-pay-gateway.apple.com from SSL inspection entirely.

Note: The quickest way to pinpoint which issue is the underlying cause is to run curl --write-out with timing fields from your AWS host and look at which phase gap (DNS, TCP connect, TLS handshake, or TTFB) accounts for the 15 seconds.

Cheers,

Paris X Pinkney |  WWDR | DTS Engineer

~15s Delay in startSession
 
 
Q