Shipping Address Validation - Suggest Alternate Address

[ktmitton]

The scenario I'm trying to address is when a customer enters a shipping address, which fails validation with a shipping service such as FedEx or UPS, but we are able to present the user with a suggested address based on what was provided.

Looking over the API, I only see a way to output an error message to the user explaining that the address was invalid, is there some way we can prompt the user to check whether our alternative address is acceptable to the customer?

[marcoscaceres]

No. You would need to either .abort(), or .complete() but then show them an option to ship to a different address.

Both are fairly terrible options, because it will be totally confusing to .complete() but then for the user to be asked to select a different address (and possibly incur additional charges). Or, in the case of .abort(), annoying to the user that they now have to enter their credit card details manually.

We might need to add an alternativeAddresses member to PaymentDetailsUpdate in V2.

To get a better understanding of the use case: how are Fedex or UPS (or even the site) able to suggest alternative addresses? Is that via some kind of reverse lookup for malformed addresses? I've seen sites here in Australia use such a system, where they normalize the addresses by using a Google address lookup/autopcomplete service - but just wondering if it's the same thing.

[ktmitton]

Yeah, a reverse lookup is what is happening, and the response we get contains alternatives ranked by how close fedex thinks they are to the provided address.

[marcoscaceres]

Noting that both Amazon and eBay provide this service. It's definitely something we will need to consider in a v2 spec (don't let "v2" throw you - we should start modelling this problem sooner rather than later).

[ktmitton]

Sounds good to me, thanks for looking into this!

[ktmitton]

Is there anything else I can do to help?

[marcoscaceres]

@ktmitton, if the current API design still allows you to deploy your app, then it would be great to see how you overcome this current limitation (screenshots help!).

However, if this is a show stopper for you, and you can't use the API because of this, then we would definitely like to hear about that too.

[ianbjacobs]

Hi all, looking back at this...can retry() be used for this use case?

[ktmitton]

I'm a little new to the retry function, can you help me understand it a little better? It looks like you can output error messages explaining what's wrong with a shipping address?

I think that's something that's a reasonable quick fix for this issue, but my concern is it's still not as smooth a user experience, at least for the way we've traditionally handled this validation. In the case where something like FedEx gives us a suggested address, we present the user with what they selected and what we suggest. Then it's just one click for them to select what they want.

If I'm reading retry correctly, it sounds like it would be more steps for them to switch which address they want. I suspect we'd get instances of customers either not bothering to change, or leaving because it's more work.

This is definitely an interesting idea I'll see if I can pitch at work.

[ianbjacobs]

Thanks @ktmitton; I've added this topic to our upcoming agenda item about future features.

[ktmitton]

No, thank you @ianbjacobs!

Sorry I haven't been able to contribute more, I moved more backend since I originally posted this, but I'd love to be able to push this more at work. I think it would simplify things for everybody if we could implement this api.

[ianbjacobs]

This issue was raised in Payment Request, but closed once we removed addresses from that API. We anticipate adding addresses back to the specification and so are re-opening this issue proactively.

[ianbjacobs]

We added addresses back to the specification in the 7 August 2024 CRD