Repository navigation
Apple Pay: "Contact" section missing and fails with "update shipping contact" for authenticated cart with buyerIdentity #381
Copy link
Copy link
Closed
Shopify/checkout-sheet-kit-swift
#522Labels
Description
What area is the issue related to?
Checkout Sheet Kit
What platform does the issue affect?
iOS
What version of @shopify/checkout-sheet-kit are you using?
3.4.0
Do you have reproducible example code?
We don't have a minimal reproducible example, but the issue is behavior-dependent based on whether buyerIdentity is provided when creating the cart.
Here the provider's config:
{
"colorScheme": "web_default",
"colors": {
"ios": {
"backgroundColor": "#FFFFFF",
"tintColor": "#000000",
"closeButtonColor": "#333333"
},
"android": {
"backgroundColor": "#FFFFFF",
"progressIndicator": "#000000",
"headerBackgroundColor": "#FFFFFF",
"headerTextColor": "#000000"
}
},
"acceleratedCheckouts": {
"storefrontDomain": "xxx.myshopify.com",
"storefrontAccessToken": "xxx",
"wallets": {
"applePay": {
"contactFields": [
"email",
"phone"
],
"merchantIdentifier": "xxx"
}
}
},
"title": "My order"
}Steps to Reproduce
- Set up the ShopifyProvider and ShopifyCheckoutSheet.
- Ensure Apple Pay is configured for the store and the test device with required phone contact.
- Create a Shopify cart, passing a valid buyerIdentity with customerAccessToken.
- Add a physical product requiring shipping to this cart.
- Tap the "Apple Pay" accelerated checkout button on the cart screen.
- The native Apple Pay payment sheet slides up.
- Observe: The "Contact" section (which normally shows email/phone) is completely missing.
- Try to authenticate and confirm the payment (e.g., with Face ID or passcode).
- Observe: The payment fails, and an error related to "update shipping contact" is displayed on the sheet.
Expected Behavior
When the Apple Pay sheet is presented for an authenticated user (buyerIdentity present), it should either:
- Automatically use the contact information (especially the phone number) associated with the buyerIdentity to satisfy Apple Pay's requirements.
- Or, still display the "Contact" section, allowing the user to select their contact info from their Apple Wallet, just as it does for an anonymous cart.
The payment should be validatable without an error.
Actual Behavior
- When the cart is authenticated (Case 1):
- The Apple Pay sheet opens, but the "Contact" section is missing. (See Screenshot 1 description below).
- Because the phone number is missing and cannot be added (due to the missing section), the payment validation fails with an "update shipping contact" error.
- When the cart is anonymous (Case 2):
- The Apple Pay sheet opens, and the "Contact" section is visible. (See Screenshot 2 description below).
- The user can select their contact info, and the payment can be validated successfully.
Notes: We also tried conditionally passing the customer prop to the . This did not change the behavior; the issue seems directly tied to the buyerIdentity on the cart itself.
Storefront domain
easy-clothes-europe.myshopify.com
Screenshots/Videos/Log output
|
Screenshot 1: Authenticated Cart (Bug) The "Contact" section is missing.
|
Screenshot 2: Anonymous Cart (Working) The "Contact" section is visible.
|
Reactions are currently unavailable


Activity
kieran-osgood-shopify commentedon Nov 12, 2025
Hi @etabard!
I want to confirm some details to get to the bottom of this with you
x-request-idheader, you can find this in the response headers for the graphql requests that happen when you submit the paymentI haven't had a chance to debug this just yet, but I feel like theres the possibility of a configuration gotcha so it'd be good to determine the exact state of the customer account you're using
etabard commentedon Nov 12, 2025
Hi @kieran-osgood-shopify, thanks for getting back to us. Here are the details you requested:
Account Type & Settings:
Customer Account Details:
name@company.comformat, and the phone number is a valid E.164 format (e.g.,+33612345678). The customer account does have a valid phone number associated with it.Conditional
contactFields:contactFields(email and phone) as shown in the example.Network Logs (
x-request-id):ShopifyCheckout.present(cart.checkoutUrl)is called, nor when I tap the "Apple Pay" button. This suggests the payment sheet communication is happening purely on the native side.kieran-osgood-shopify commentedon Nov 13, 2025
+33612345678would I see the error?etabard commentedon Nov 13, 2025
Hi, thanks for the quick reply.
Legacy Accounts: Thanks for the context on Legacy vs. New Customer accounts. We understand the recommendation and will discuss the migration with our client. For now, we are hoping to resolve this issue on the current Legacy implementation.
Phone Number: Yes, I can confirm that the error is reproducible with a valid customer account that has a phone number in that E.164 format (e.g.,
+33612345678).Network Logs: Understood. I am actively working on setting up Proxyman to capture the native network traffic. I will post the relevant logs (
x-request-idor request/response bodies) here as soon as I successfully reproduce and capture the error.etabard commentedon Nov 14, 2025
Hi @kieran-osgood-shopify , I've run the tests with Proxyman.
Step 1: Create Cart
I created the cart via the API, specifying the
buyerIdentity(accessToken, email, phone).Step 2: Click Apple Pay
I clicked the accelerated checkout Apple Pay button.
Here is the sequence executed by the Shopify SDK:
GetCart
Response :
CartSelectedDeliveryOptionsUpdate
Response :
CartPrepareForCompletion
Response :
CartDeliveryAddressesAdd
The variables show it's resetting the address but it's incomplete:
The response shows nothing changed, the address is still incomplete:
CartPrepareForCompletion
No changes
Clicking the 'Pay' Button
It runs a sequence of requests again:
Here are the variables sent in this final CartDeliveryAddressesAdd mutation:
And here is the error response to that mutation. The deliveryAddress object was missing the phone number, which is required by our store settings.
Conclusion
Thanks to the Proxyman logs, it's clear the
buyerIdentity(with the correct email and phone) is present in the requests.The issue seems to stem from the
delivery.addressobject itself:Mysterious Partial Address: As soon as the Apple Pay sheet opens, the SDK populates the cart with a very incomplete address (as seen in
CartSelectedDeliveryOptionsUpdate), which hasphone: null. What's confusing is that this partial address doesn't exist in my Apple Pay wallet or my Shopify customer account, so I'm not sure where the SDK is pulling this data from.Final Address is Missing Phone: When I confirm the payment, the final
CartDeliveryAddressesAddmutation sends the complete address from my Apple Pay wallet (e.g., "16 street name", "Billy Bob"), but thedeliveryAddressobject is still missing thephonefield.This missing
phonefield is the direct cause of theADDRESS_FIELD_IS_REQUIREDerror, as our store requires a phone number for shipping.etabard commentedon Nov 14, 2025
Hi, I have a quick update on my debugging.
I wanted to test if the issue was caused by not having a default address in the cart.
I re-ran all the tests, but this time I set a complete, default shipping address on the cart (before hitting the Apple Pay button).
This did not change the outcome of the bug.
As soon as I click the "Apple Pay" accelerated checkout button inside the sheet, the Proxyman logs show that the Shopify SDK overwrites the default address I had set. It replaces it with a partial address (I can confirm I have a correct and complete address set up in my Apple Pay wallet).
The SDK is still populating the
delivery.addressesobject with this same incomplete data:This confirms that the SDK is setting up an incorrect and incomplete address in the cart. It's also not merging the phone from the buyerIdentity into the delivery.address object, which is what causes the validation to fail.
I wanted to clarify another important point. If I go to the checkout and click on the Apple Pay button, it works perfectly. So this doesn't seem to be an issue with Apple Pay itself, but rather an issue with the SDK or the configuration (but I don't see what we could have missed)
etabard commentedon Nov 21, 2025
Hi @kieran-osgood-shopify,
I hope you're doing well. Do you have any news on that issue? My client is eager to provide Apple Pay to customers :-)
Thanks for your help!
kieran-osgood-shopify commentedon Nov 21, 2025
Hey @etabard,
I appreciate the comprehensive debugging steps you've been able to provide and it should be useful when someone is able to look into this
This ticket has been triaged as a bug and will be looked into, but I can't provide a timeline as to when that will be complete
Leaving some notes here for future reference:
CartDeliveryAddressInputUnresolved question: Why is it that guests can checkout successfully, because the phone number still wouldn't be applied to the deliveryAddress
github-actions commentedon Dec 22, 2025
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs in 30 days. Thank you for your contributions.
etabard commentedon Dec 22, 2025
Hi @kieran-osgood-shopify, this issue is still relevant and not stale. Any news on a resolution? Thanks for your help.
kieran-osgood-shopify commentedon Jan 5, 2026
Hey @etabard
The stale tag has been removed and I've added the never-stale until we get a chance to look at it
I don't have any update on a time frame at the moment which I appreciate isn't ideal, but will report back on this thread when it has been looked into!
Thank you for your patience
kieran-osgood-shopify commentedon Jan 22, 2026
@etabard Just keeping you in the loop - I've been able to take a look and reproduce the issue
I've got a pretty straight forwards fix that I will aim to draft a PR for tomorrow
Again - appreciate the patience and all the information supplied it was useful
lustsazeus-lab commentedon Feb 24, 2026
Thanks for reporting — happy to help triage this.
A few quick clarifying questions that would let me narrow it down fast:
If this is still affecting production, I can put together a concrete fix plan (scope + test plan + ETA) and ship a fast-track PR/workaround within 48h once I have the above details.