PayPal Express "Sandbox" checkout: Error #10730. Shipping Address Postal Code Empty. The field Shipping Address Postal Code is required

#1

This error started all of a sudden today when I performed a test transaction with a dev server through the PayPal Sandbox. Anytime s2member is upgraded, I perform test transactions.

Note: This error does not occur on live transactions. It only just started to occur for non-live, sandbox transactions. I performed a $1 live transaction that went through fine.

When I’m redirected to the pay in PayPal to place the order, it shows a “Review Order” button and when I click it, I’m redirected to the original checkout page with the following error displayed:

Error #10730. Shipping Address Postal Code Empty. The field Shipping Address Postal Code is required.

I’m not redirected to the URL set in the “success” attribute.

I last performed a successful PayPal sandbox test transactions about one week ago. No site or shortcode changes. I have ns=“1” (do not prompt for shipping address) in the shortcode, same as before. dg=“0” is also unchanged (I tried changing it to “1” but it made no difference).

Something new I noticed in PayPal interface is that multiple options are now shown as a group of horizontal radio buttons:

  1. Pay in full (default)
  2. Pay in 4 interest-free payments
  3. Pay monthly (available for eligible purchases of $49.00-$10,000.00)

This interface wasn’t like this a week ago, but that just may be a redesign quirk of Sandbox vs Live mode.

So it appears that something changed on PayPal’s end. I’m glad it’s not affecting live mode, but I’m no longer able to perform test transactions in Sandbox mode.

#2

After additional testing, I discovered that s2Member does map address fields from hidden input fields (e.g., s2member_pro_paypal_checkout[street], [city], etc.) into the PayPal Express Checkout request.

For instance, here’s what I had in the PayPal form’s hidden input values going back a long time:

<input type="hidden" name="s2member_pro_paypal_checkout[street]" value="">
<input type="hidden" name="s2member_pro_paypal_checkout[city]" value="">
<input type="hidden" name="s2member_pro_paypal_checkout[state]" value="">
<input type="hidden" name="s2member_pro_paypal_checkout[zip]" value="">
<input type="hidden" name="s2member_pro_paypal_checkout[country]" value="US">

and then I filled in all the values with dummy data:

<input type="hidden" name="s2member_pro_paypal_checkout[street]" value="123 Main St">
<input type="hidden" name="s2member_pro_paypal_checkout[city]" value="Anytown">
<input type="hidden" name="s2member_pro_paypal_checkout[state]" value="NY">
<input type="hidden" name="s2member_pro_paypal_checkout[zip]" value="10001">
<input type="hidden" name="s2member_pro_paypal_checkout[country]" value="US">

And then the Sandbox transaction succeeded.

I tried this one-by-one, first just setting the “zip” field value to “10001” and leaving the other inputs blank, but PayPal errored and redirected to the checkout form complaining about the “City” field instead of the “Zip” field:

So, it started with:
Error #10730. Shipping Address Postal Code Empty. The field Shipping Address Postal Code is required.

Then shifted to:
Error #10728. Shipping Address City Empty. The field Shipping Address City is required.

In sandbox mode, PayPal required all address fields, even for digital goods with ns=“1”.

Adding dummy values to these hidden fields allowed the sandbox transaction to succeed. This requirement does not exist in live mode, where transactions work as expected without the address fields (or blank address fields). This appears to be a PayPal sandbox-specific behavior.

So “live” PayPal is respecting the ns=“1” attribute (do not prompt for a shipping address), while “test” Sandbox does not.

So while adding dummy address fields can work around the issue in the Sandbox, I realize this is not an actual solution for live, production transactions (which don’t appear to be affected now).

Since digital goods don’t require address data, this appears to be a configuration or integration issue between s2Member and PayPal, or possibly a change on PayPal’s end.

I’m concerned that if live mode ever begins to mimic Sandbox’s behavior, this problem could cause silent failures and lost sales.

Thanks.

#3

Thanks for all the details!

I see, that’s not the first time I’ve seen the Sandbox cause trouble and want troubleshooting that isn’t needed for live transactions. In the end, the live ones are what matters, so any Sandbox behavior that doesn’t match it can be ignored.

I’ve wasted countless hours troubleshooting a problem in the Sandbox, to find out later that it wasn’t needed because live payments weren’t having that issue. This is why I stopped using the PayPal Sandbox over a decade ago and only test with live transactions since.

I’m reviewing the Paypal integration, so maybe I can change something that makes the Sandbox behave again for you. Not sure, and maybe not worth troubleshooting the Sandbox when the Live is what matters. Honestly, it’s always been silly that their Sandbox doesn’t match the Live environment exactly (other than not really processing charges).

Your live payments are fine, so that’s good.

:slight_smile: