Signed-in customers can now set a default address during checkout. This replaces the previous "last used address" logic. The default address can be updated at any time, either from checkout or from the account profile.
The most recently used address was selected as-is. When the "address you usually ship to" differed from the "address you happened to use last," you had to re-select every time.
The address the customer designates as "my default" is selected preferentially. It can be changed at any time, either from checkout or from the account profile.
The article explicitly lists two conditions for automatic setup. The default address is set automatically when the customer registers their first address, or when they place their first order.
When a customer registers their first address, that address is automatically set as the default.
When a customer places their first order, that address is automatically set as the default.
| Item | Previous: last used address | New: default address |
|---|---|---|
| Address selected | Most recent Last used address | Default The default address set by the customer |
| Customer control | No explicit specification (depends on history) | Customer can set and manage it |
| Initial setup | — | Automatically set on first address added / first order placed |
| Where it can be updated | Not specified (depends on history) | Checkout + account profile |
| Target | During checkout,logged inCustomers | |
During checkout,logged-incustomers are the target. The article does not document the behavior for guest checkout.
Supported regions, eligible plans, the timing of the gradual rollout, handling of billing addresses, and behavior in the Admin API / Webhooks are not documented in this article.
The "last used address" logic is being replaced with "default address." Because the address auto-selection behavior is changing, you should check any existing flows that assume address selection (especially how reorders and subscription renewals appear).
The default address can be updated frombothcheckout and the account profile. Updating from either side updates the same default address — it's natural to think of it as a single value tied to the customer account.
Because the default is set automatically on the first address added / first order, a state where "the default is unset and empty" basically shouldn't happen. There's little need to prompt new customers to configure this during onboarding.
The target is "customers who are logged in during checkout." The value of flows that encourage account login (login CVR) goes up another notch in the form of reduced address-entry effort.
The Changelog body only describes customer-facing behavior. How to read and write a Customer's default address via the Admin GraphQL or Webhooks, and how to reference it from themes / Checkout Extensions, arenot mentioned in this article. If you need automation or integrations, verify separately in the official API documentation (don't infer).