For signed-in customers, checkout remembers the payment method used on their previous purchase and shows it pre-selected on subsequent orders. This applies to D2C and B2B checkout flows where saved payment methods are enabled.
Only customers who are signed in. The announcement says nothing about guest checkout.
Limited to flows where saved payment methods are enabled.
Both checkout flows are explicitly stated as in scope.
"signed-in customers" is the premise. There is no mention of the purchase experience without an account.
Explicitly stated as "only in checkout flows where saved payment methods are enabled". If this is off, there is nothing to remember in the first place.
| Item | Before | After this change |
|---|---|---|
| Payment method shown initially | Nothing selected / default order The customer picks every time | The method used last time is already selected |
| Customer action | Pick from saved cards each time | Just continue and pay with the same method as last time |
| Customers covered | — | Signed-in customers |
| Flows covered | — | D2C / B2B with saved payment methods enabled |
| Merchant setup | — | Not stated No setup steps are described in the original |
The original is a short release note. The following are not written in it, so treat them as items to verify rather than assume.
There is no mention of whether merchants can disable it, or whether an admin setting exists.
Nothing is said about whether customers can choose "don't remember this".
No plan requirements, regions, or rollout timeline are stated.
There is no description of how this surfaces in the Admin API or Checkout Extensibility.
The fallback behavior when the previously used card has expired is unknown.
Whether it affects the payment method on subscription contracts is not stated.
On stores where this is OFF, the feature won't apply at all. Start by confirming the current state.
Verify hands-on whether the method chosen on the first order comes pre-selected on the second.
A different default selection shifts the mix of methods used. Compare before and after the release.
The article gives no setup steps or code changes. This is the kind of change that simply lands as a checkout behavior improvement. The work is "verification", not "implementation".
It's limited to flows where saved payment methods are enabled. Depending on store settings, "this never happens for us" is entirely plausible, so align expectations about the feature before discussing it.
B2B checkout is explicitly in scope. Behavior in setups involving company accounts and multiple buyers is worth verifying hands-on in a development store.
If the default selection changes, so does the distribution of methods customers pick. On stores where fees differ by method, this can ripple into cost-side metrics too.
If you've built Checkout UI Extensions or your own payment-steering logic, the implicit assumption that "the customer starts with nothing selected" may no longer hold. That said, the original post says nothing about interaction with extensionsso you need to verify on your own store whether it has any impact.